Вход по SSH-ключам и отключение аутентификации по паролю

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

Создайте пару ключей

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

Linux и macOS

ssh-keygen -t ed25519 -C "you@laptop"

Оставьте расположение по умолчанию, ~/.ssh/id_ed25519, и задайте парольную фразу. Она шифрует закрытый ключ на диске; благодаря агенту ее достаточно вводить один раз за сеанс, а не при каждом подключении. В macOS ssh-add --apple-use-keychain ~/.ssh/id_ed25519 сохраняет ее в связке ключей.

Windows 10 и 11

Клиент OpenSSH встроен в систему. В PowerShell:

ssh-keygen -t ed25519 -C "you@laptop"

Закрытый ключ сохраняется как %USERPROFILE%\.ssh\id_ed25519, открытый — как id_ed25519.pub рядом с ним. Чтобы пользоваться агентом, один раз выполните Get-Service ssh-agent | Set-Service -StartupType Automatic в PowerShell с правами администратора, затем Start-Service ssh-agent и ssh-add.

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

Установите открытый ключ на сервер

В примерах используются учетная запись deploy (создана в руководстве Первые шаги) и адрес 203.0.113.10. Для root используйте вместо этого root@.

С помощью ssh-copy-id (Linux и macOS)

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

Утилита один раз входит по паролю учетной записи и дописывает ключ в ~/.ssh/authorized_keys на сервере, создавая каталог и файл с безопасными правами доступа, если их еще нет.

Из Windows или вручную

В Windows нет ssh-copy-id. Ту же задачу выполняет эта команда PowerShell:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Можно также вставить содержимое файла .pub одной строкой в конец ~/.ssh/authorized_keys на сервере.

Проверьте права доступа

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

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Домашний каталог тоже не должен быть доступен для записи группе или всем остальным. В AlmaLinux и Rocky Linux выполните restorecon -Rv ~/.ssh, если создавали или перемещали файлы вручную, чтобы SELinux разрешил sshd их читать.

Теперь войдите командой ssh deploy@203.0.113.10. Если запрашивается парольная фраза ключа или не запрашивается вообще ничего, ключ работает. Если запрашивается пароль учетной записи — не работает: исправьте это, прежде чем двигаться дальше. ssh -v показывает, какие ключи предлагает ваш клиент и что отвечает сервер.

Отключите аутентификацию по паролю

Эту часть выполняйте от root (sudo -i). Актуальные релизы Ubuntu, Debian, AlmaLinux и Rocky Linux подключают все файлы *.conf из /etc/ssh/sshd_config.d/ в самом начале sshd_config. Для большинства параметров sshd сохраняет первое прочитанное значение, поэтому действует тот drop-in-файл, имя которого идет первым при сортировке. Создайте /etc/ssh/sshd_config.d/00-keys-only.conf в своем редакторе:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

prohibit-password по-прежнему позволяет root входить по ключу. Когда будете входить только под своим пользователем с sudo, используйте PermitRootLogin no. Найдите старые параметры, которые могут конфликтовать, затем проверьте конфигурацию:

grep -ri -E 'passwordauthentication|permitrootlogin' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
sshd -t

Если конфигурация корректна, sshd -t ничего не выводит. В некоторых образах есть файлы вроде 50-cloud-init.conf, которые задают PasswordAuthentication yes; благодаря префиксу 00- ваш файл имеет приоритет, но старую строку лучше удалить, чтобы потом не путаться. Примените изменения — открытые сессии не прервутся:

systemctl reload ssh

В AlmaLinux и Rocky Linux служба называется sshd: systemctl reload sshd. Затем проверьте значения, которые sshd фактически использует:

sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin)'

Вы должны увидеть passwordauthentication no. prohibit-password может отображаться под старым названием — without-password.

Проверьте во второй сессии, прежде чем выходить

1. Откройте новый терминал и войдите по ключу. Команда ssh deploy@203.0.113.10 должна сработать.

2. Убедитесь, что пароли отклоняются. Принудительно запросите аутентификацию по паролю:

   Shell

   ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password deploy@203.0.113.10

   Ожидаемый ответ: Permission denied (publickey).

3. Только после этого закройте исходную сессию.

Если первый шаг не удался, удалите 00-keys-only.conf из все еще открытой сессии, перезагрузите конфигурацию sshd и еще раз проверьте ключ и права доступа.

Сократите ввод с помощью алиаса в конфигурации SSH

На своем компьютере добавьте запись в ~/.ssh/config (в Windows — %USERPROFILE%\.ssh\config):

Host web1
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Теперь достаточно команды ssh web1, а инструменты, работающие поверх SSH, например scp, rsync и git, принимают тот же алиас. IdentitiesOnly yes не дает клиенту предлагать все ключи из агента, что избавляет от ошибок «Too many authentication failures».

Потеряли доступ? Восстановите его через консоль IPMI

Настройки sshd действуют только на вход по сети. Локальная консоль по-прежнему принимает пароль root, поэтому консоль IPMI/KVM — ваш путь обратно в систему:

1. Откройте консоль. В личном кабинете откройте сервер и выберите «Консоль (IPMI)».

2. Войдите как root с паролем root.

3. Отмените изменение и перезагрузите конфигурацию sshd (в AlmaLinux и Rocky Linux — sshd):

   Shell

   mv /etc/ssh/sshd_config.d/00-keys-only.conf /root/
   systemctl reload ssh

4. Устраните причину (обычно это отсутствующий ключ или неверные права доступа), затем верните файл на место.

Для входа в консоль нужен пароль, поэтому root без пароля войти туда не сможет. Так бывает, если сервер устанавливался только с SSH-ключом. Задайте надежный пароль root прямо сейчас командой passwd и сохраните его в менеджере паролей: SSH по-прежнему будет отклонять пароли, а консоль его примет. Если пароля нет, используйте режим восстановления, чтобы задать его или исправить файлы.

Следующие шаги

Далее переходите к защите сервера. Если вы также переносите SSH на другой порт, сначала разрешите новый порт в файрволе. В Ubuntu проверьте systemctl status ssh.socket: если socket-юнит активен, для смены порта также нужны systemctl daemon-reload и systemctl restart ssh.socket.

Все еще не получается? Создайте тикет в разделе Поддержка и приложите вывод ssh -v.