Как настроить ssh-вход без пароля

Замена стандартного порта SSH

Эффективность: ️ ️

Один из самых простых способов защититься от неумелых атакующих и тупых ботов – это изменение дефолтного порта подключения по SSH. Большинство ботов сканируют только дефолтный порт, сменив его вы защититесь от ботов работающих на дурака.

Перед сменой порта разберитесь, какой firewall стоит на вашей системе. Например на CentOS 8 это скорее всего firewalld.

Вам необходимо открыть новый порт для ssh, и закрыть старый. Например, если у вас установлен firewalld, а порт вы выбрали 58291, то команды для открытия порта будут такие:

Для изменения порта нужно отредактировать файл . В этой статье мы будем часто этим заниматься. Всякий раз, когда вам нужно отредактировать этот файл, используйте следующую команду:

В открывшемся файле найдите следующую строку: #Port 22 Удалите решетку и измените номер порта, например на 58291. Номер не должен превышать 65535. Рекомендую выбрать пятизначное значение.

Также удостоверьтесь, что выбранное вами значение не конфликтует с другими сервисами в системе, например mysqld использует порт 3306, httpd — 80, ftpd — 21.

После этого необходимо перезапустить службу ssh:

Для входа с использованием нового порта используйте следующий флаг:

Config SSH

Чтобы не запоминать порты ко всем своим серверам, можно воспользоваться файлом . Создайте этот файл, если его нет на вашей локальной машине.

Пример .ssh/config

1: Установка PAM

Сначала нужно установить PAM, Pluggable Authentication Module – это инфраструктура для аутентификации пользователей, используемая в системах Linux. Поскольку Google разработал приложение OATH-TOTP, необходимо было создать и PAM для генерации одноразовых паролей, полностью совместимый с любым TOTP-приложением (таким как Google Authenticator или Authy).

Для начала обновите индекс пакетов Ubuntu:

Установите PAM:

После установки PAM можно использовать вспомогательное приложение, установленное вместе с модулем, и сгенерировать TOTP-ключ для аккаунта, который в дальнейшем будет защищён двухфакторной аутентификацией

Обратите внимание: ключ генерируется индивидуально для каждого пользователя, а не общесистемно; то есть, чтобы настроить двухфакторную аутентификацию для нескольких аккаунтов, нужно на каждом из них запустить вспомогательное приложение и сгенерировать индивидуальный TOTP-ключ

Запустите инициализацию:

После этого программа задаст несколько вопросов. Сначала нужно указать, нужно ли синхронизировать токены авторизации по времени.

PAM позволяет создавать токены, синхронизированные по времени, и токены на основе математического алгоритма.

Токены на основе математического алгоритма создаются сериями на основе секретного ключа; ни один из таких токенов невозможно угадать, даже если предыдущие токены известны. Синхронизированные по времени токены постоянно меняются в установленный интервал времени (например, раз в 30 секунд). В данном руководстве будут использоваться синхронизированные по времени токены, поскольку такие обычно используются в приложениях типа Google Authenticator. Выберите y.

После этого на экране появится большой вывод, содержащий QR-код. Используйте приложение на смартфоне, чтобы просканировать QR-код, или введите секретный ключ вручную. Если код слишком большой для сканирования, откройте уменьшенную его версию по URL-адресу, предоставленному тут же. После этого вы получите шестизначный код, который будет обновляться каждые 30 секунд.

Примечание: Сохраните секретный ключ, проверочный код и аварийные скретч-коды в надежном месте (например, в менеджере паролей). Эти коды – единственный способ восстановить доступ к TOTP-приложению.

Остальные вопросы настраивают работу PAM. Рассмотрим их по очереди.

После этого ключи и опции в файле .google_authenticator обновятся. Если ответить no, программа завершит работу и ничего не запишет в файл, и потому аутентификация не будет работать.

Это предотвратит атаки повторного воспроизведения (replay), так как каждый код будет недействителен после использования. Таким образом, злоумышленник не сможет перехватить использованный код.

Эта опция будет создавать до 8 валидных кодов в течение 4 минут в скользящем окне. Если выбрать no, количество действительных кодов будет ограничено до 3 за полторы минуты. Это гораздо более безопасный вариант.

Ограничение скорости позволяет ограничить количество попыток злоумышленника угадать код, после чего он блокируется.

Примечание: После настройки можно создать резервную копию секретного ключа. Для этого скопируйте файл ~/.google-authenticator. Теперь вы сможете развернуть его в других системах или использовать как резервную копию.

Создание ключей SSH

Создайте SSH-ключи на локальном компьютере.

Для этого используется утилита ssh-keygen. Она по умолчанию создаёт 2048-битный RSA-ключ, такой ключ подойдёт в большинстве случаев.

Введите в терминал:

Вы можете принять место хранения ключей по умолчанию или указать свой путь к ключам. По умолчанию ключи находятся в каталоге .ssh в домашнем каталоге пользователя. Файл закрытого ключа называется id_rsa, а открытый ключ находится в id_rsa.pub.

Если вы только начинаете знакомство с SSH, лучше принять путь к ключам по умолчанию. В таком случае клиент SSH сможет автоматически найти ключи при попытке пройти аутентификацию. Если вы хотели бы выбрать нестандартный путь, введите его сейчас; оставьте поле пустым и нажмите RETURN, чтобы принять значение по умолчанию.

Если вы создавали SSH-ключи раньше, на экране может появиться запрос:

Если вы замените существующие ключи новыми, они будут утеряны навсегда и вы не сможете использовать их для аутентификации. Не переписывайте старые ключи, если вы не уверены в том, что они больше не используются.

Далее будет запрошена парольная фраза.

Это опционально. Такая парольная фраза защищает закрытый ключ. Она запрашивается всегда, когда нужно использовать закрытый ключ. Таким образом, при аутентификации будет запрашиваться и закрытый ключ, и его пароль. В некоторых случаях применить парольную фразу полезно. Если вы оставите это поле пустым, вы сможете проходить аутентификацию без пароля, только с помощью ключей.

После этого на экране появится следующий вывод, который предоставит вам подробности о ключах:

Ключи готовы. Теперь нужно добавить открытый ключ на сервер, к которому вы хотите подключаться с помощью этих ключей.

Настройка входа (на сервере)[править]

Для того, чтобы пользователь мог авторизоваться в системе через ssh-ключ, нужно в файл ~/.ssh/authorized_keys добавить содержимое файла id_ed25519.pub. Если пользователь будет один входить под этой учётной записью, файл id_ed25519.pub можно просто скопировать, назвав authorized_keys.
Также можно воспользоваться утилитой ssh-copy-id, если копировать вручную не хочется: ssh-copy-id user@host

Данные изменения проводятся в каталоге пользователя на сервере.

Обратите внимание на права файлов:

-rw------- authorized_keys
-rw-r--r-- config

и на каталог

drwx------ .ssh

принадлежать файлы должны пользователю и его группе.

$ xfconf-query -c xfce4-session -p /startup/ssh-agent/type -s "ssh-agent" -t string -n

Изменение вступит в силу после перелогина.

Проверка того, что ключ работает:

$ ssh-add
$ ssh другая_машина

При подключении не должен запрашиваться пароль.

Как ограничить подключение по паролю

Если ограничить подключение по паролю, то использование утилиты OpenSSH будет более безопасным, потому что даже если украдут ваш пароль, то он будет практически бесполезным, потому что зайти на сервер по SSH, используя его, будет уже невозможным.

Для выставления ограничений необходимо иметь права администратора, вы должны быть авторизованным под root или использовать перед каждой командой. В примерах будет использоваться вариант без , чтобы не было расхождений с предыдущими примерами.

Для начала зайдем на сервер по ключу:

Используя консольный текстовый редактор nano, откроем под root файл настроек OpenSSH:

:~# nano /etc/ssh/sshd_config 

После чего мы увидим содержимое файла настроек. Нам нужно найти строчку:

...

#PasswordAuthentication yes

...

Убрать в начале и заменить на . То есть ее надо преобразить вот в такой вид:

...

PasswordAuthentication no

...

Далее нажимаем сначала Ctrl + O , затем Enter, чтобы сохранить. И Ctrl + X, чтобы выйти.

Теперь, чтобы эти настройки вступили в силу, нужно перезапустить службу SSH. Для этого необходимо ввести следующую команду.

Теперь выйдем с сервера и вернемся туда, откуда подключались.

:~# systemctl restart sshd
:~# exit
logout
Connection to 80.90.255.255 closed.
:~$ 

И попробуем обратно подключиться к северу по паролю.

:~$ ssh 
Permission denied (publickey).

И видим, что сервер нас больше таким способом пускать не намерен. А теперь попробуем с помощью ключа.

:~$ ssh  -i ~/.ssh/server-key
Enter passphrase for key '/home/uxumax/.ssh/server-key': 
Linux debian9 5.4.40-04224-g891a6cce2d44 #1 SMP PREEMPT Tue Jun 23 20:21:29 PDT 2020 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
:~# 

На этом настройка завершена, ключ не теряйте, а если потеряете, то пишите хостинг-провайдеру, чтобы он дал вам доступ по VNC, с помощью которого вы сможете включить вход по паролю обратно.

Чтобы сервер был в безопасности, советую настроить на нем фаервол и добавить порт SSH в список доверенных.

5: Восстановление доступа к Google MFA (опционально)

Занимаясь настройкой защиты любой системы, вы берёте на себя ответственность за управление безопасностью этой системы. Под этим подразумевается, что вы должны сохранить в надежном свой SSH-ключ, секретный ключ TOTP или же доступ к TOTP-приложению. К сожалению, в некоторых ситуациях ключи или доступ к приложению всё же теряются, и тогда их необходимо восстановить.

Восстановление секретного ключа TOTP

Если вы потеряли свой ключ TOTP, рекомендуем вам такой процесс восстановления, его можно разделить на два этапа:

1. Вход без кода подтверждения;
2. Поиск старого или создание нового ключа для восстановления MFA.

Обычно доступ теряется, если у вас появился новый смартфон, на который вы не перенесли свои данные.

Чтобы попасть на сервер, когда секретный ключ утрачен, используйте консоль хостинг-провайдера (это работает, потому что, как правило, с помощью MFA провайдеры защищают только соединения SSH; соединения, не связанные с SSH, не используют модуль PAM Google Authenticator).

Если доступа к консоли нет, у вас есть два варианта восстановления доступа:

1. Консольный (локальный, не SSH) доступ к системе (то есть физический доступ или через приложение типа iDrac)
2. Пользователь с доступом к sudo, для которого не была активирована MFA.

Второй вариант является менее безопасным, поскольку цель MFA – усилить защиту всех SSH-соединений, но это один из самых надежных способов восстановить доступ к приложению.

Войдя в систему, вы можете получить секретный ключ:

• Восстановить утерянный ключ;
• Сгенерировать новый ключ.

В домашнем каталоге каждого пользователя есть файл ~/.google-authenticator, где хранятся секретный ключ и настройки Google Authenticator. Первая строка этого файла содержит необходимый нам ключ. Чтобы получить его, выполните следующую команду, она выведет первую строку файла google-authenticator. Полученный ключ можно ввести в TOTP-приложение.

Восстановив текущий ключ, вы можете либо вручную ввести его в приложение аутентификации, либо ввести соответствующие данные в приведенный ниже URL-адрес и попросить Google сгенерировать QR-код, который вы сможете просканировать. Вам нужно будет указать в адресе свое имя пользователя, имя хоста, секретный ключ из файла .google-Authenticator, а затем любое имя для ‘entry-name-in-auth-app’, чтобы легко отличить этот ключ от других токенов TOTP:

Если же по какой-либо причине вы не может воспользоваться текущим ключом (к примеру, если у вас нет возможности безопасно передать его), вы можете временно переместить файл ~/.google-authenticator в другое место. Это позволит вам получить доступ к серверу по одному фактору (если только вы не сделали многофакторную аутентификацию обязательной, удалив опцию nullok) и запустить google-authenticator, чтобы сгенерировать новый ключ.

Восстановление доступа к TOTP-приложению

Если вы утратили доступ к своему TOTP-приложению и не можете создать код подтверждения, используйте коды для восстановления, которые были выданы вам во время создания первого секретного ключа. Это последние пять строк файла .google-authenticator.

Важно! Эти коды восстановления одноразовые

Генерация пары ключей RSA

Механизм авторизации по ключу прост. На то место куда мы подключаемся нам надо повесить замок (публичный ключ название.pub) а сам ключик с помощью которого мы сможем подключится (приватный ключ название) держать у себя и с помощью его открывать замочек. Мало того, замок вешается не на всю систему а именно на конкретного пользователя под которым мы будем авторизовываться.

Можно не указывать путь куда мы будем устанавливать ключи и тогда они создадутся в папке по умолчанию с базовым названием. Я не буду менять путь по умолчанию для ключей а лишь буду создавать их со своим удобным мне названием.

Создадим связку ключей указав тип -t rsa, длину ключа -b 2048 и место с необходимым нам названием:

ssh-keygen -t rsa -b 2048 -f /home/user/.ssh/rsa_sevo44
= вывод команды =
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/rsa_sevo44.
Your public key has been saved in /home/user/.ssh/rsa_sevo44.pub.
The key fingerprint is:
SHA256:A9d+2cz6M1GK482oOxf/zweqt9B18WPox04m+Deczgc user@H4530
The key's randomart image is:
+-------+
| |
| . |
| . . . . |
| o . =. +|
| S . oo==o|
| . o*oE..|
| .oo@.O.|
| ..B.&*o|
| +B.o+BO|
+---------+

По результату видим что создалась пара ключей с названием rsa_sevo44.

Надежно сохраните эту пару ключей чтобы в случае краха системы и потери жесткого диска вы могли подключится к необходимому ресурсу к которому открыт доступ для подключения только по ключу.

Пример использование ssh-keygen для беспарольной аутентификации

Вместо использования паролей, с помощью ssh-keygen можно создать ключи DSA или RSA, которыми пользователи могут аутентифицироваться. Ключи RSA являются наиболее широко используемыми и создаются по умолчанию. Но я для примера использую ключу для создания DSA, если запустить ssh-keygen будет создан RSA.

Немножко терминов:

• RSA (Rivest-Shamir-Adleman) является одним из первых криптосистемы с открытым ключом и широко используется для безопасной передачи данных. Безопасность основана на целочисленной факторизации, поэтому безопасный RNG никогда не нужен. По сравнению с DSA RSA быстрее проверяет подпись, но медленнее для генерации.

• DSA (Digital Signature Algorithm — алгоритм цифровой подписи) является федеральным стандартом обработки информации для цифровых подписей. Безопасность зависит от дискретной логарифмической проблемы. По сравнению с RSA DSA быстрее генерирует подпись, но медленнее для проверки.

Введите нижеприведённую команду и сгенерируйте ключ, на все вопросы просто жмите Enter. Если при генерации ключей был использован пароль (вы что-то написали на вопрос Enter passphrase (empty for no passphrase)), каждый раз для при использовании приватного ключа он будет запрашиваться у пользователя.

% ssh-keygen -t dsa
Generating publicprivate dsa key pair.
Enter file in which to save the key (homeuser.sshid_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in homeuser.sshid_dsa.
Your public key has been saved in homeuser.sshid_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com

ssh-keygen создаст пару публичного и приватного ключей, используемых для аутентификации. Приватный ключ сохраняется в ~/.ssh/id_dsa или ~/.ssh/id_rsa, а публичный в ~/.ssh/id_dsa.pub или ~/.ssh/id_rsa.pub (для ключей DSA и RSA соответственно).

Для включения аутентификации по ключам, публичный ключ должен быть помещен в файл ~/.ssh/authorized_keys на удаленном компьютере, например так:

cat ~.sshid_rsa.pub | ssh root@ip-адрес-сервера 'cat >> ~/.ssh/authorized_keys'

Это позволяет соединяться с удаленным компьютером с помощью SSH-ключей вместо паролей.

Создаст ключи с паролем fgdfgytyityirioyroryoyuouiy:

$ ssh-keygen -N fgdfgytyityirioyroryoyuouiy -t rsa -C test4@test4 -f test4 -q

Создаст ключи без пароля (пароль пустой):

$ ssh-keygen -t rsa -N "" -C test4@test4 -f test4 -q

ssh-copy-id

Я предпочитаю использовать с флагом -i и задавать путь до нужного ключа

sudo ssh-copy-id -i ~/.ssh/andrei-key.pub andrei@192.168.0.2

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: «/home/andrei/.ssh/andrei-key.pub»
The authenticity of host ‘192.168.0.2 (192.168.0.2)’ can’t be established.
ECDSA key fingerprint is SHA256:abcdefgh1234567890abcdefgh1234567890abc+def.
Are you sure you want to continue connecting (yes/no/)?

Введите yes

Are you sure you want to continue connecting (yes/no/)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed — if you are prompted now it is to install the new keys
andrei@192.168.0.2’s password:

Введите пароль

Number of key(s) added: 1

Now try logging into the machine, with: «ssh ‘andrei@192.168.0.2′»
and check to make sure that only the key(s) you wanted were added.

Теперь на хосте 192.168.0.2 в файле
/home/andrei/.ssh/authorized_keys
появилась новая запись вида

ssh-rsa AAAAB3NzaC1y … lseP/jXcq … Uydr/2CwQ &hellip ++TpY19pHqD/AnhL … Az62T/Ipyx … 8U2T andrei@host.andrei.com

Знак … заменяет длинные последовательности случайных символов для экономии места.

Проверить ключ можно командой

ssh -i ~/.ssh/mykey user@host

В нашем случае

ssh -i ~/.ssh/andrei-key andrei@192.168.0.2

Если вы не задавали пароль для ключа, то попадёте на удалённый хост без лишних движений

Last login: Sun Jan 10 16:48:27 2021 from 192.168.0.1

Конвертация сертификатов

Рассмотрим простой пример: вы достали из

базы данных

сертификат
MIIC4jCCAc … A7A6Rpt8V9Q==
, но он не отформатирован и не проходит валидацию

Сертификат, конечно, длиннее, я поставил троеточие для экономии места и вашего времени.

Выполните

echo ‘MIIC4jC … 7A6Rpt8V9Q==’ | base64 -d | openssl x509 -inform der

Либо, если вам нужно работать с файлами — сохраните исходный сертифика в фай

raw_cert

echo MIIC4jC … 7A6Rpt8V9Q== > raw_cert

cat raw_cert | base64 -d | openssl x509 -inform der > cert

cat cert

——BEGIN CERTIFICATE——
MIIC4jC … 7A6Rpt8V9Q==
——END CERTIFICATE——

Такого же результата можно было добиться аккуратно добавив ——BEGIN CERTIFICATE—— в начало
и ——END CERTIFICATE—— в конец файла, но не всегда всё так просто.

Создание ключей SSH

Первый шаг для настройки аутентификации ключей SSH на сервере заключается в том, чтобы сгенерировать пару ключей SSH на локальном компьютере.

Для этого мы можем использовать специальную утилиту , которая входит в стандартный набор инструментов OpenSSH. По умолчанию она создает пару 2048-битных ключей RSA, что подходит для большинства сценариев использования.

Сгенерируйте на локальном компьютере пару ключей SSH, введя следующую команду:

Утилита предложит вам выбрать место размещения генерируемых ключей. По умолчанию ключи хранятся в каталоге внутри домашнего каталога вашего пользователя. Закрытый ключ будет иметь имя , а соответствующий открытый ключ будет иметь имя .

На этом этапе лучше всего использовать каталог по умолчанию. Это позволит вашему клиенту SSH автоматически находить ключи SSH при попытке аутентификации. Если вы хотите выбрать нестандартный каталог, введите его сейчас, а в ином случае нажмите ENTER, чтобы принять значения по умолчанию.

Если ранее вы сгенерировали пару ключей SSH, вы можете увидеть следующий диалог:

Если вы решите перезаписать ключ на диске, вы больше не сможете выполнять аутентификацию с помощью предыдущего ключа. Будьте осторожны при выборе варианта yes, поскольку этот процесс уничтожает ключи, и его нельзя отменить.

Далее вам будет предложено ввести парольную фразу для ключа. Это опциональная парольная фраза, которую можно использовать для шифрования файла закрытого ключа на диске.

Возможно вам будет интересно, в чем заключаются преимущества ключа SSH, если вам все равно нужна парольная фраза. Вот некоторые его преимущества:

• Закрытый ключ SSH (защищенная паролем часть) никогда не доступен через сеть. Парольная фраза используется только для расшифровки ключа на локальном компьютере. Это означает, что парольную фразу нельзя взломать через сеть методом прямого подбора.
• Закрытый ключ хранится в каталоге с ограниченным доступом. Клиент SSH не принимает закрытые ключи, хранящиеся в каталогах, доступ к которым не ограничен. У самого ключа могут быть ограниченные разрешения (чтение и запись доступны только владельцу). Это означает, что другие пользователи системы не смогут создать уязвимость.
• Для попытки взлома защищенного парольной фразой закрытого ключа SSH злоумышленнику уже необходим доступ к системе. Это означает, что у него уже должен быть доступ к учетной записи пользователя или учетной записи root. Если вы окажетесь в такой ситуации, парольная фраза может помешать злоумышленнику сразу же попасть на ваши другие серверы. Это может дать вам достаточно времени, чтобы создать и внедрить новую пару ключей SSH и запретить доступ с взломанным ключом.

Поскольку закрытый ключ недоступен через сеть и защищен системой разрешений, доступ к этому файлу будет только у вас (и у пользователя root). Парольная фраза служит дополнительным уровнем защиты на случай взлома одной из этих учетных записей.

Парольная фраза представляет собой необязательное дополнение. Если вы решите ее использовать, вам нужно будет вводить ее при каждом использовании соответствующего ключа (если вы не используете программный агент SSH, хранящий зашифрованный ключ). Мы рекомендуем использовать парольную фразу, но если вы не хотите ее задавать, вы можете просто нажать ENTER, чтобы пропустить этот диалог.

Теперь у вас есть открытый и закрытый ключи, которые вы можете использовать для аутентификации. Следующим шагом будет размещение открытого ключа на сервере, что позволит использовать аутентификацию SSH для входа в систему.

Логирование ssh подключений по сертификату

Мне необходимо знать, когда и какой сертификат подключался к серверу. По-умолчанию такой информации чаще всего в логах не остается. Исключение я заметил только в CentOS 7. Там с дефолтными настройками ssh и уровнем логирования INFO отображается отпечаток ключа в логе:

# cat /var/log/secure

Dec 4 21:32:40 server sshd: Accepted publickey for root from 10.1.3.221 port 56929 ssh2: RSA fa:7c:c6:6b:31:98:43:9f:ef:41:c5:49:80:c2:a8:16
Dec 4 21:32:41 server sshd: pam_unix(sshd:session): session opened for user root by (uid=0)

По отпечатку становится понятно, какой сертификат подключился. Для каждого сертификата отпечаток можно посмотреть в puttygen. В CentOS более ранних версий, в Ubuntu 12 и 14 в логах будет только такая информация:

# cat /var/log/auth.log

Dec 5 11:44:14 server sshd: Accepted publickey for root from 10.1.3.221 port 60170 ssh2
Dec 5 11:44:14 server sshd: pam_unix(sshd:session): session opened for user root by (uid=0)

Информации о самом ключе нет. Я так думаю, это зависит от версии OpenSSH. В первом случае 6-я версия, во втором 5-я. Специально я не проверял. Если у вас нет информации о ключе в лог файле, исправить это очень просто. В файле /etc/ssh/sshd_config меняем параметр:

LogLevel VERBOSE

и перезапускаем службу:

# service ssh restart

Пробуем снова подключиться по ssh, используя сертификат, и проверяем лог:

Dec 5 11:43:17 server sshd: Connection from 10.1.3.221 port 60162
Dec 5 11:43:19 server sshd: Found matching RSA key: fa:7c:c6:6b:31:98:43:9f:ef:41:c5:49:80:c2:a8:16
Dec 5 11:43:19 server sshd: Postponed publickey for root from 10.1.3.221 port 60162 ssh2 
Dec 5 11:43:19 server sshd: Found matching RSA key: fa:7c:c6:6b:31:98:43:9f:ef:41:c5:49:80:c2:a8:16
Dec 5 11:43:19 server sshd: Accepted publickey for root from 10.1.3.221 port 60162 ssh2
Dec 5 11:43:19 server sshd: pam_unix(sshd:session): session opened for user root by (uid=0)

Теперь в логе будет отображаться отпечаток подключившегося сертификата и мы сможем идентифицировать пользователя.

Онлайн курс по Linux

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Administrator Linux. Professional» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Что даст вам этот курс:

• Знание архитектуры Linux.
• Освоение современных методов и инструментов анализа и обработки данных.
• Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
• Владение основными рабочими инструментами системного администратора.
• Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
• Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.

Проверьте себя на вступительном тесте и смотрите подробнее программу по .

SSH-доступ по Ключу в Ubuntu и CentOS:

Чтобы сгенерировать открытый и закрытый SSH-ключ в Ubuntu или CentOS, используйте команду:

ssh-keygen -t rsa

Параметр -t означает тип, а RSA — протокол, используемый для генерации ключей. RSA является типом по умолчанию, поэтому вы также можете использовать упрощённую версию команды — ssh-keygen.

Длина ключа по умолчанию — 2048 бит. Однако, если вы хотите усилить защиту, измените значение на 4096 бит. В этом случае команда будет выглядеть так:

ssh-keygen -t rsa -b 4096

Это интерактивный процесс генерации ключей, и вас попросят выполнить несколько действий, таких как:

• Enter file in which to save the key (/home/.ssh.id_rsa), или «Ввести файл для сохранения ключа (/home/.ssh.id_rsa)»
• Enter passphrase (empty for no passphrase), или «Ввести кодовую фразу (оставьте пустым для отключения кодовой фразы)»

Если вы хотите, чтобы были заданы значения по умолчанию, просто нажмите Enter в ответ на каждый из этих запросов. Кодовая фраза используется для шифрования закрытого ключа; однако она не является обязательной и может быть пропущена. Закрытый ключ будет сохранён в папке по умолчанию — .ssh/id_rsa.

Открытый ключ будет сохранён в файле .ssh/id_rsa.pub. На этом генерация ключа будет завершена. Вы можете проверить файлы с помощью любого редактора.

Старые версии Windows (без OpenSSH)

Создание SSH-ключей

Запустите программу, в открывшемся окне выберите «Type of key — SSH-2 RSA и нажмите «Generate».

Пока создается ключ, водите мышью в хаотичном порядке в пространстве под строкой загрузки для генерации случайных значений.
После того, как ключ будет создан, в окне программы вы сможете задать «Key passphrase» (кодовую фразу) для ключа. Это необязательно, вы можете оставить строку пустой

Если вы решите задать кодовую фразу, обратите внимание, что ее потребуется вводить при каждой авторизации по ключу.
Далее сохраните созданные ключи, нажав на кнопки «Save public key» и «Save private key», например, под именами id_rsa.pub и mykey.ppk. Также скопируйте и сохраните в любом текстовом файле содержимое окна «Public key for pasting…» — оно потребуется при копировании созданного ключа на сервер.

На этом процедура создания ключей завершена.

Копирование ключей на сервер

1. Подключитесь к серверу по SSH и выполните команду для создания на сервере директории и файла для хранения ключей:

   mkdir ~/.ssh
   
   chmod 0700 ~/.ssh
   
   touch ~/.ssh/authorized_keys
   
   chmod 0644 ~/.ssh/authorized_keys

2. Откройте созданный файл с помощью текстового редактора:

   nano ~/.ssh/authorized_keys

3. Вставьте в него скопированный на предыдущем шаге текст public key из окна PuTTYgen и сохраните файл.
4. Запустите pageant — его иконка появится в трее. Щелкните по ней правой кнопкой мыши и выберите Add Key.
5. В открывшемся окне укажите путь к приватному ключу mykey.ppk, сохраненному ранее, и нажмите Open. Если при создании ключа вы указывали кодовую фразу, pageant запросит ее на данном этапе.

6. Для проверки работы авторизации по ключу снова запустите утилиту PuTTY, подключитесь к вашему серверу и введите свой логин. Если все настроено корректно, вы увидите подобный вывод в окне консоли:

   Authenticating with public key "rsa-key-20151220" from agent

Совет 5: Обязательная MFA

Вы также можете сделать многофакторную аутентификацию обязательной для всех и запретить пользователям самостоятельно генерировать ключи. Для этого нужно просто использовать один и тот же файл .google-authenticator для всех пользователей (в этом файле нет индивидуальных данных).

После начальной настройки скопируйте этот файл в root каждого домашнего каталога и измените права на файл (для этой операции необходимы привилегии root). Также можно скопировать файл в /etc/skel/, откуда он будет автоматически скопирован в домашний каталог нового пользователя.

Важно! Такая настройка представляет угрозу безопасности, поскольку все используют один и тот же второй фактор. Это означает, что в случае утечки информации сразу все пользователи потеряют один из факторов аутентификации

Примите это во внимание, если решите использовать этот подход

Также можно сделать MFA обязательной с помощью сценария bash, который:

• Создаст TOTP-токен;
• Загрузит приложение Google Authenticator и просканирует QR-код;
• Запустит google-authenticator и проверит, существует ли файл .google-authenticator.

Чтобы сценарий запускался при входе пользователя, назовите его .bash_login и поместите его в root домашнего каталога пользователей.

Настройка SSH сервера

Настройка сервера на всех системах Linux сводится к редактированию конфигурационного файла ssh сервера. Данный пример файла от системы CentOS 7 но и у других тоже самое:

mcedit /etc/ssh/sshd_config
= необходимые параметры с пояснениями =
RSAAuthentication yes
PubkeyAuthentication yes
PubkeyAcceptedKeyTypes ssh-dss
#Путь к файлу с публичными ключами
AuthorizedKeysFile %h/.ssh/authorized_keys
#Отключение возможности авторизации по паролю
PasswordAuthentication no
#Вид публичного ключа для авторизации
PubkeyAcceptedKeyTypes ssh-rsa

Не советую сразу отключать подключение по паролю. Отключите его только после проверки авторизации по ключу!

Перезагрузим сервер SSH:

systemctl restart ssh

Настройка ssh на сервере для авторизации по сертификатам

Здесь все просто. Во всех известных мне дистрибутивах авторизация по сертификатам уже настроена, нужно просто добавить этот сертификат на сервер. Сделаем это.

# mkdir ~/.ssh
# chmod 0700 ~/.ssh
# touch ~/.ssh/authorized_keys
# chmod 0644 ~/.ssh/authorized_keys

В файл authorized_keys вставляйте скопированный ключ из окна puttygen. Сохраняйте и подключайтесь с помощью сертификата. В putty сертификат нужно указать в разделе Connection -> SSH -> Auth.

Выбрать нужно приватный ключ, у которого расширение .ppk. Напоминаю, что на сервер мы отправили публичный ключ. Этот ключ можно использовать на множестве серверов, так что нет необходимости для каждого сервера генерировать новую пару ключей. Везде можно использовать один и тот же.

Теперь можно подключаться, необходимости перезапускать службу ssh нет.

Шаг 4: Защита демона sshd

После установки сервера SSH, первым делом исправить файл sshd_config. В нем запретить удалённый доступ пользователя root и разрешить доступ только для доверенных пользователей. Настраиваем от непривилегированного пользователя, используя sudo.

Первое действие перед правкой любого файла — это бекап этого файла, делаем:

remuserbak@vps:~$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig
 password for remuserbak:

Посмотреть текущее настройки демона ssh

sudo sshd -T

Отключение SSH-логин для пользователя root, используя параметр PermitRootLogin no.

remuserbak@vps:~$ sudo nano etcsshsshd_config
 
# Authentication:
PermitRootLogin no # запретить удалённый доступ для root
AllowUsers user1 user2 # список пользователей, которым разрешён доступ по SSH

После внесения изменений в sshd_config — перегружаем демона SSH.

$ sudo systemctl restart ssh.service
или
$ sudo service sshd restart

При таком способе перезагрузки демона SSH текущее соединение не прерывается.
Теперь при попытке залогинеться с пользователем root, в логах вы увидите запись:

User root from 222.187.238.57 not allowed because not listed in AllowUsers

Всё, у вас демон SSH минимально защищен!

Дополнительные параметры sshd_config, которые можно менять, под ваши задачи и условия, но не делайте это без нужды и предварительно изучите руководство man 5 sshd_config

LoginGraceTime 120: Сервер отключается по истечении этого времени, если пользователю не удалась регистрация в системе. Если стоит значение 0, то время ожидания не ограничено. Значение по умолчанию — 120 секунд.

StrictModes yes: Проверять наборы прав доступа и принадлежность конфигурационных файлов и домашнего каталога пользователя перед разрешением регистрации в системе. Это рекомендуется выполнять потому, что новички иногда оставляют свои каталоги или файлы доступными для записи всем. Значение по умолчанию — yes.

AddressFamily inet: Семейство адресов которое должна использовать служба sshd, допустимые значения: any, inet (только IPv4) и inet6 (только IPv6). Значение по умолчанию — any.

Port 22: Порт, на котором следует ожидать запросы на ssh соединение. Значение по умолчанию — 22, рекомендуется ставить значение нового порта выше 1024 так как значение ниже уже зарезервированы (например 2007)

Внимание! При подключение к нестандартному порту используйте ключ -p для задания порта.

PubkeyAuthentication yes — включение авторизации по ssh-ключам.

PermitEmptyPasswords no — запрет использования пустых паролей.

PasswordAuthentication no — запрет авторизации по паролю в принципе. (не меняйте, пока не убедитесь, что авторизация по SSH-ключам работает)

ListenAddress XXX.XXX.XXX.XXX — указываем конкретный IP, на котором будет располагаться служба

По умолчанию на всех.