Аутентификация по ключу

Почему ключи считаются надёжнее паролей

Пароль можно подобрать, использовать повторно на разных сайтах, или он может утечь при взломе другого сервиса. Приватный ключ не переходит между сервисами, его практически невозможно подобрать методом brute-force при современной длине ключа, и его никогда не нужно вводить в форму входа, где он может быть перехвачен или залогирован.

Что должно быть настроено правильно

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

Как перейти на вход только по ключу и не потерять доступ, описано здесь: руководство по усилению защиты SSH.

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

Как правильно создать ключ и обращаться с ним

Большая часть надёжности входа по ключу определяется при создании ключа и в повседневном обращении с ним. В актуальном руководстве ssh-keygen сказано, что запуск без указания типа создаёт ключ Ed25519, а у ключей Ed25519 длина фиксирована, поэтому параметр размера -b для них игнорируется. Если задана парольная фраза, закрытый ключ шифруется с помощью функции выработки ключа, а параметр -a увеличивает число её раундов, что замедляет подбор фразы у украденного ключа. В руководстве по умолчанию указано 32.

ssh-keygen -t ed25519 -a 100 -C "alice@laptop-2026"
ssh-keygen -p -f ~/.ssh/id_ed25519
ssh-keygen -lf ~/.ssh/id_ed25519.pub

Вторая команда меняет парольную фразу существующего ключа. Третья печатает отпечаток, по которому ключ потом узнают в журналах и в authorized_keys. Заводите один ключ на человека и на устройство с понятным комментарием, тогда потеря ноутбука означает удаление одной строки. Чтобы не вводить фразу весь день, пусть ключ хранит агент. В ~/.ssh/config параметр AddKeysToAgent yes загружает ключ после первого использования (по умолчанию no), а IdentitiesOnly yes не даёт ssh предлагать все известные ключи подряд. Оставляйте ForwardAgent в значении по умолчанию no, если нет конкретной необходимости.

Докажите, что вход по паролю действительно выключен

Добавление ключа не отключает пароли. После установки PasswordAuthentication no проверьте результат из второго терминала, не закрывая первую сессию. Заставьте клиент пробовать только пароль:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no alice@your-server

Правильно настроенный сервер откажет, не предложив ввести пароль. Если вы видите приглашение, что-то всё ещё включено. Спросите у демона напрямую:

sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|authenticationmethods) '

Проверяйте kbdinteractiveauthentication наравне с настройкой пароля. В руководстве sshd_config у PasswordAuthentication и KbdInteractiveAuthentication значение по умолчанию yes, а вход keyboard-interactive на системах с PAM может быть ещё одним путём к запросу пароля. Если вывод расходится с отредактированным файлом, вероятно, побеждает другой подключённый файл, как объясняет статья про sshd_config. Наконец, помните, что один ключ это один фактор, а следующий шаг описан в руководстве по двухфакторной аутентификации SSH.

Связанные термины: SSH, authorized_keys, sshd_config, Вход под root, Двухфакторная аутентификация (2FA), PasswordAuthentication, ssh-keygen (создание ключей OpenSSH), ssh-copy-id (установка ключа на сервер), FIDO2 и WebAuthn (вход с аппаратным ключом).