Авторизация по ключу SSH

SSH (Secure Shell) чаще всего используется для удаленного управления серверами Linux, хотя также может успешно применяться для создания SOCKS, для организации тоннеля при копировании файлов с помощью rsync. По-умолчанию, при создании сервера Linux настроен доступ по SSH по логину/паролю (как правило изначально вы получаете доступ пользователя root по паролю). Пароль можно подобрать. Но если настроить доступ по ключам, то тогда попытки подбора пароля в принципе будут невозможны.

Виды авторизации SSH

Авторизоваться на SSH сервере можно используя:

1. логин/пароль
   Не обязательно ведет к взлому. Стойкий пароль, использование fail2ban помогут защитить сервер.
    
2. ключ без пароля
   Безопасно и удобно, вводить пароль не нужно вообще, но надо защищать файлы ключей от копирования - если кто-то скопирует файл ключа, то сможет подключаться к серверу с другого компьютера.
    
3. ключ с паролем
   "Двухфаторная аутентификация". Мало того, что надо иметь файл ключа, но надо знать также и пароль ключа. Максимальный уровень безопасности.

Как работает SSH по ключам

На сервере SSH (по-умолчанию, в файле ~/.ssh/authorized_keys) находится публичный ключ.

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

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

 

Постановка задачи

Задача: разрешить логин на сервер по SSH только конкретному пользователю vasya.

Считаем, что у Васи домашняя директория на сервере: /home/vasya/.

Важно: настраивая sshd на сервере, надо заранее подумать, что вы будете делать, если вдруг сессия прекратится (неверные настройки, сбой интернет и др.). Это похоже на настройку iptables. Я предполагаю, что хотя бы часть из вас, хотя бы в локальной сети, нарывались на грабли, когда после изменения конфигурации зайти на сервер можно было только локально.

 

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

Ключи желательно создавать на своем компьюетере, отправляя на сервер (компьютер, к которому будем подключаться по ssh) только публичный ключ.

Вариант 1) Создаем ключ в Windows (на клиенте Putty) ...

Готовим ключ в Putty. Для этого на клиенте Windows запускаем puttygen.exe.
Жмем Generate, водим мышкой до полной победы.

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

Сохраняем открытый ключ (например, myServer_rsa.pub) и приватный (например, myServer_rsa.ppk). И тот и другой файлы храним, но приватный храним как зеницу ока! К тому же, приватный ключ (точнее, путь к нему) надо прописать в настройках Putty (это если вы с Windows работаете).

Копируем текст из поля Public key for pasting into OpenSSH authorized_keys file вида"ssh-rsa AAA......." в блокнот (для архива) либо сразу в файл ~/.ssh/authorized_keys (про файл см. ниже) на сервер Linux. Обратите внимание, текст должен быть вставлен в одну строку!

 

Вариант 2) создаем ключ в Linux

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

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

$ ssh-keygen

Создаст два ключа (если запускать без параметров и соглашаться с default):

1) приватный .ssh/id_rsa
2) публичный .ssh/id_rsa.pub

Содержимое файла .ssh/id_rsa.pub копируется на удаленный сервер (к которому мы будем подключаться), в файл .ssh/authorized_keys того пользователя, от имени которого убдем подключаться.

Полезные колючи ssh-keygen:

-t rsa
-b 4096 (размер ключа)
-f /home/admin/.ssh/id_rsa_1

Последняя опция создаст приватный ключ /home/admin/.ssh/id_rsa_1 и публичный /home/admin/.ssh/id_rsa_1.pub

Это необходимо, если вы собираетесь администрировать несколько серверов:

$ ssh-keygen -t rsa -b 4096 -f /home/admin/.ssh/id_rsa_1
$ ssh-keygen -t rsa -b 4096 -f /home/admin/.ssh/id_rsa_2

И создадим файл /home/admin/.ssh/config

Host host1
    HostName host1_address
    User user1
    Port 22
    IdentityFile /home/admin/.ssh/id_rsa_1
Host host2
    HostName host2_address
    User user2
    Port 22
    IdentityFile /home/admin/.ssh/id_rsa_2

После чего команда

$ ssh host2

будет использовать соответствующий приватный ключ.

Содержимое публичных ключей необходимо скопировать в файлы .ssh/authorized_keys  на серверы, которые планируем в дальнейшем администрировать (id_rsa_1.pub на host1, id_rsa_2.pub на host2).

 

Настраиваем сервер SSH

На сервере (к которому будем подключаться)

На сервер надо поместить открытый (публичный) ключ (id_rsa_1.pub из примера выше), а не приватный!

mkdir /home/vasya/.ssh
touch /home/vasya/.ssh/authorized_keys

Примечание 1: если файл authorized_keys уже есть и он к вашему удивлению не пустой, значит, кто-то когда-то пользовался подключением по ключу. Это важно, надо обязательно выяснить, кто еще заходил на сервер.

Примечание 2: если вы под рутом зашли и папки-файлы создаете, то потом надо права на папку дать юзеру, иначе vasya в папку .ssh не попадет:

# chown -R vasya:vasya /home/vasya/.ssh
# chmod 600 /home/vasya/.ssh/authorized_keys
# chmod 700 /home/vasya/.ssh

 

Изменяем настройку сервера sshd

Отключаем аутентификацию по паролю, запрещаем логиниться пользователем root.

# nano /etc/ssh/sshd_config

...
PermitRootLogin no
MaxAuthTries 3
MaxSessions 3
AllowUsers vasya

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

PermitEmptyPasswords no
PasswordAuthentication no
...

Перезапуск сервера sshd:

Стойте!!! Фуф, успел )) Перед тем, как копипастить команду ниже, подумайте, что будет, если сессия разорвется, а залогиниться вы вдруг не сможете ))

# service sshd restart

Вот и все? Еще немного внимания!

Грабли

Не спешите закрывать окно консоли, чтобы радостно войти с ключом! Если что-то пойдет не так (например, сервер не примет ваш клиентский сертификат), то вы не сможете войти на сервер с удаленной консоли. Конечно, можно подойти к серверу и на нем работать, но это совсем не так удобно, а порой (например, если это удаленный хостинг) невозможно. Поэтому попробуйте сначала открыть новое окно (например, putty) и войти на сервер с ключом.

Например, если не выполнить chmod 700 на папку и chmod 600 на файл из п.2.1, вам может быть отказано в авторизации. В /var/log/secure могут быть записи такого рода:

su: pam_unix(su-l:session): session opened for user root by vasya(uid=500)
su: pam_unix(su-l:session): session closed for user root
sshd[785]: Authentication refused: bad ownership or modes for file /home/vasya/.ssh/authorized_keys
sshd[786]: Connection closed by 192.168.1.2
sshd[1451]: Authentication refused: bad ownership or modes for directory /home/vasya/.ssh
sshd[1452]: Connection closed by 192.168.1.2
sshd[1557]: User root from 192.168.1.123 not allowed because not listed in AllowUsers
sshd[1558]: input_userauth_request: invalid user root
sshd[1558]: Connection closed by 192.168.1.2

где
192.168.1.2 - сервер;
192.168.1.123 - клиент.

Надо скорректировать права доступа:

# chmod 600 /home/vasya/.ssh/authorized_keys
# chmod 700 /home/vasya/.ssh

И только после того, как убедитесь, что можете заходить на сервер с ключом, выходите из первоначальной сессии ssh.

Вот и все.