Настройка аутентификации по SSH-ключам.

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

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

scp ~/.ssh/название_ключа.pub пользователь@адрес:

Дальнейшие действия будут происходить в удалённой машине, подключитесь к ней по SSH под пользователем, для которого настраивается подключение:

ssh пользователь@адрес

Первым делом создайте каталог для хранения открытого SSH-ключа и установите на него права на чтение, запись и доступ к содержимому только для владельца, введя команды:

$ mkdir ~/.ssh
$ chmod 700 ~/.ssh

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

cat ~/название_ключа.pub >> ~/.ssh/authorized_keys

Если для данного пользователя Вы не имеете ключей:

cat ~/название_ключа.pub > ~/.ssh/authorized_keys

После добавления открытого ключа в «authorized_keys», необходимо установить права на чтение и запись только для владельца:

chmod 600 ~/.ssh/authorized_keys

Файл открытого ключа больше не нужен, его можно удалить:

rm ~/название_ключа.pub

Вредоносная программа или сценарий, запущенная от имени пользователя может добавить ключ, или заменить каталог «~/.ssh» с «authorized_keys», что даст злоумышленнику возможность аутентифицироваться в системе. Чтобы исключить подобную ситуацию, стоит запретить изменение файла и каталога, но chmod не подойдёт, т. к. программа тоже может изменять права. Безопаснее установить защитный бит:

sudo chattr +i ~/.ssh/authorized_keys && sudo chattr +i ~/.ssh

Пока установлен защитный бит, невозможно внести изменения, ни в файл, ни в каталог. Чтобы добавить или удалить ключ, необходимо снять защитный бит введя команду:

sudo chattr -i файл_или_каталог

Далее нужно включить аутентификацию по SSH-ключам в OpenSSH-сервере. Откройте его конфигурационный файл в консольном текстовом редакторе (возможно, Вам понадобиться краткая инструкция по использованию vi):

sudo vi /etc/ssh/sshd_config

Найдите в нём директиву «PubkeyAuthentication» и приведите её к виду:

PubkeyAuthentication yes

Сохраните изменения и перезагрузите ssh-сервер командой:

sudo systemctl restart sshd

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

exit

Затем попробуйте снова подключиться используя новый ключ:

ssh пользователь@адрес -i закрытый_ключ

Если при подключении терминал запросит пароль пользователя в удалённой системе:

пользователь@адрес password:

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

Если подключение произойдёт автоматически, или терминал запросит кодовую фразу:

Enter passphrase for key 'файл_закрытого_ключа':

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

sudo vi /etc/ssh/sshd_config

и отключите возможность подключения по паролю приведя директиву «PasswordAuthentication» к виду:

PasswordAuthentication no

Затем перезагрузите SSH-сервер:

sudo systemctl restart sshd

На этом настройка аутентификации по ключам на стороне сервера закончена и можно выйти из сессии. Чтобы не указывать закрытый ключ при каждом подключении можно записать его в конфигурационный файл SSH-клиента строкой:

IdentityFile ~/.ssh/закрытый_ключ

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

AddKeysToAgent yes

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

Не работает аутентификация по SSH-ключам.

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

Одной из причин может быть директива «AuthorizedKeysFile», указывающая файл открытых ключей, она должна иметь такой вид:

AuthorizedKeysFile     .ssh/authorized_keys

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

Наиболее распространённой причиной является неправильно установленные права на файлы и каталоги. У пользователя должен быть доступ на чтение файла «~/.ssh/authorized_keys», для проверки можно попробовать открыть его, например, командой cat или в текстовом редакторе. Кроме того, права на изменение: «authorized_keys», «~/.ssh» и домашнего каталога, должен иметь только владелец, иначе OpenSSH-сервер, по соображениям безопасности, отклонит аутентификацию по ключам. Рекомендуемые права:

• «~/.ssh/authorized_keys» — 600;
• «~/.ssh» — 700;
• «~/» (домашний каталог) — 700 или 755.

Доступ к каталогам так же может блокироваться модулями безопасности вроде AppArmor или SELinux. Чтобы понять, блокируют ли они доступ, придётся смотреть их логи, но работа с AppArmor и SELinux это отдельные и большие темы и на одной странице вместить не получится. Чтобы упростить задачу, поясню, на CentOS и RHEL предустановлен SELinux, а на Ubuntu и Debian — AppArmor.

Если предложенные выше варианты не помогли, то остаётся вникать в логи, или идти за помощью на форумы. Команда для просмотра логов аутентификации в Ubuntu и Debian:

cat /var/log/auth.log

в CentOS и RHEL:

cat /var/log/secure

Чтобы просмотреть отчёт об ошибках на стороне SSH-клиента, выполните попытку подключения с опцией -v:

ssh пользователь@адрес -i закрытый_ключ -v