SSH-ключи: как создать, скопировать на сервер и отключить вход по паролю

Короткий ответ: SSH-ключ заменяет пароль парой файлов: приватный остаётся на вашей машине, публичный копируется на сервер в ~/.ssh/authorized_keys. После проверки входа по ключу вход по паролю отключается в /etc/ssh/sshd_config директивой PasswordAuthentication no. Это убирает целый класс атак: подобрать пароль к серверу невозможно, если пароля нет.

Тема относится к базовой настройке сервера — она разобрана в материале про первую настройку Ubuntu на VPS и в настройке firewall.

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

ssh-keygen -t ed25519 -C "рабочий ноутбук"

Утилита спросит путь (по умолчанию ~/.ssh/id_ed25519) и парольную фразу. Парольная фраза шифрует приватный ключ на диске — если файл украдут, без неё он бесполезен.

Создаются два файла: id_ed25519 — приватный, его нельзя никому передавать, и id_ed25519.pub — публичный, который копируется на серверы.

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

Самый простой способ, пока вход по паролю ещё работает:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@185.75.189.48

Утилита сама создаст каталог, положит ключ в authorized_keys и выставит нужные права. Если ssh-copy-id недоступен, то же самое вручную:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "содержимое файла .pub" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Права здесь — не формальность. При слишком широких правах на ~/.ssh или authorized_keys сервер молча откажет в аутентификации по ключу, и в логе будет строка про Authentication refused: bad ownership or modes.

Проверка перед отключением пароля

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

1. Откройте второе окно терминала и войдите по ключу: ssh -i ~/.ssh/id_ed25519 root@сервер.
2. Убедитесь, что пароль не запрашивался.
3. Только теперь правьте конфигурацию, не закрывая первую сессию.
4. Проверьте синтаксис: sshd -t.
5. Перезагрузите конфигурацию: systemctl reload ssh.
6. Проверьте вход в третьей сессии. Если что-то сломалось — первая сессия ещё открыта, и её можно починить.

Пункт про открытую сессию — самый важный. Отключение пароля при непроверенном ключе и закрытом терминале означает потерю доступа к серверу.

Настройка sshd

Правьте /etc/ssh/sshd_config или файл в /etc/ssh/sshd_config.d/. Значения по умолчанию в свежих сборках Ubuntu вынесены именно туда, поэтому проверяйте оба места — файл в sshd_config.d перекрывает основной.

PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
X11Forwarding no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

Отключать PermitRootLogin целиком (no) стоит только тогда, когда создан отдельный пользователь с sudo. Иначе вы потеряете административный доступ.

Обслуживание ключей

Ключ, который больше не используется, нужно убирать. Проверить, какие ключи есть:

# отпечатки всех ключей в authorized_keys
ssh-keygen -lf ~/.ssh/authorized_keys

# кто подключался и с какого адреса
last -i | head -20
grep "Accepted publickey" /var/log/auth.log | tail -20

Отпечаток в логе совпадает с отпечатком из ssh-keygen -lf, поэтому по журналу можно понять, какой именно ключ использовался и когда. Строку ненужного ключа удаляют из authorized_keys — этого достаточно, перезапуск sshd не требуется.

Агент и удобство работы

Чтобы не вводить парольную фразу при каждом подключении, используют ssh-agent:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Для часто используемых серверов удобно описать подключение в ~/.ssh/config:

Host myserver
    HostName 185.75.189.48
    User root
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60

После этого достаточно команды ssh myserver. Если доступ идёт через промежуточный сервер, добавляется ProxyJump bastion — отдельная строка для каждого узла цепочки.

Типичные ошибки

• Отключение пароля до проверки ключа. Самый дорогой вариант ошибки — потеря доступа к серверу.
• Неверные права на ~/.ssh. Сервер отказывает в аутентификации, а причина видна только в логе.
• Правка sshd_config без sshd -t. Ошибка в директиве не даст перезапустить службу, и вход перестанет работать для всех.
• Забыли про sshd_config.d/. Настройка в основном файле перекрывается файлом из подкаталога.
• Приватный ключ передан кому-то. Ключ нельзя восстановить или ограничить — только удалить из authorized_keys на всех серверах.
• Ключи не убираются при увольнении сотрудника. Доступ остаётся действующим, потому что ключ не привязан к человеку.