ssh-keygen (создание ключей OpenSSH)

Что создаёт ssh-keygen и какой тип ключа выбрать

В руководстве ssh-keygen для параметра -t перечислены типы ed25519 (по умолчанию), ecdsa, rsa и FIDO-типы ecdsa-sk и ed25519-sk. Выбирайте Ed25519, если только старая система не отказывается его принимать. У ключей Ed25519 длина фиксирована, поэтому для них параметр -b игнорируется. Для RSA в руководстве указаны минимум 1024 бита и значение по умолчанию 3072 бита, а 3072 обычно считается достаточным.

Файлы по умолчанию это ~/.ssh/id_ed25519 (закрытый) и ~/.ssh/id_ed25519.pub (открытый), причём закрытый файл не должен быть доступен никому, кроме вас. Утилита спрашивает парольную фразу; пустая означает отсутствие фразы, а потерянную фразу восстановить нельзя. Заданная фраза шифрует ключ с помощью функции выработки ключа, а -a задаёт число её раундов (по умолчанию 32): чем оно выше, тем медленнее подбор у украденного ключа. Комментарий по умолчанию состоит из имени пользователя и хоста, свой задаётся через -C. Если файл уже существует, перед перезаписью утилита спросит подтверждение.

Повседневные команды и безопасная проверка нового ключа

Вот команды, которых хватает в большинстве случаев:

ssh-keygen -t ed25519 -a 100 -C "alice-laptop-2026" -f ~/.ssh/id_ed25519_work
ssh-keygen -l -f ~/.ssh/id_ed25519_work.pub
ssh-keygen -p -f ~/.ssh/id_ed25519_work
ssh-keygen -y -f ~/.ssh/id_ed25519_work
ssh-keygen -F myserver
ssh-keygen -R myserver

Они создают ключ, печатают его отпечаток (по умолчанию SHA256, а -E md5 даёт старый формат), меняют парольную фразу, выводят открытый ключ из закрытого, ищут хост в known_hosts и удаляют все записи хоста. В актуальном OpenSSH -l принимает и файл authorized_keys, выводя по строке на ключ, а -R сохраняет прежний файл как known_hosts.old. Применяйте -R после законной переустановки сервера, а не чтобы заглушить непонятное предупреждение о ключе хоста (см. known_hosts).

Чтобы проверить новый ключ, установите его через ssh-copy-id, не закрывая текущую сессию, и из второго терминала выполните ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_work myserver. Только после успеха можно думать об отключении входа по паролю.

Ошибки и риски

Чаще всего ошибаются в обращении с ключом, а не в выборе алгоритма:

• Нет парольной фразы. Любой, кто скопирует файл закрытого ключа с украденного ноутбука или из случайной резервной копии, сразу сможет им пользоваться. Обычный компромисс это фраза плюс ssh-agent.
• Копирование закрытого ключа на сервер. С вашей машины уходит только файл .pub. См. аутентификацию по ключу.
• Один ключ на все случаи. Заводите ключ на каждого человека и каждое устройство с понятным комментарием, тогда потеря ноутбука означает удаление одной строки.
• Доверие комментарию. Это произвольный текст. Ключ определяет отпечаток.
• Слабые старые ключи. Руководство допускает RSA от 1024 бит, поэтому не выбирайте меньше 3072 по умолчанию.
• Привычная передача агента. См. перенаправление ssh-agent.

Помните также, что -C задаёт комментарий только при создании. Чтобы изменить его у готового ключа, используйте -c. Если после добавления ключа вход не работает, причины разбирает руководство по ошибке Permission denied (publickey).

ssh-keygen в регулярной защите сервера

Порядок с ключами складывается из небольших привычек. Создавайте ключи Ed25519 с парольной фразой, храните каждый ключ на одном устройстве и записывайте, у кого какой отпечаток. При аудите сервера сравнивайте отпечатки из ssh-keygen -l с этой записью и удаляйте ключи, происхождение которых никто не может объяснить, как советует руководство по усилению защиты SSH.

При первом подключении к новому серверу сверьте отпечаток, который показывает ssh, с отпечатком, напечатанным той же утилитой на самом сервере:

ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

Для второго фактора команда ssh-keygen -t ed25519-sk -O verify-required создаёт ключ, привязанный к аппаратному токену. В руководстве перечислены FIDO-параметры (resident, no-touch-required, verify-required и другие), а компромиссы разобраны в статье FIDO2 и WebAuthn. Порядок внедрения показывает руководство по двухфакторной аутентификации SSH. Если закрытый ключ утёк, удалите его открытую строку из всех authorized_keys и затем по руководству по реагированию на взлом проверьте, не было ли злоупотреблений. Что сервер делает с открытым ключом, описано в руководстве sshd.

Связанные термины: Аутентификация по ключу, authorized_keys, ssh-copy-id, known_hosts, FIDO2 и WebAuthn.