SSH-ключи вместо пароля на сервере: частые ошибки и решения

MAATRIX

Переход на SSH-ключи вместо пароля резко повышает безопасность, но именно на этом переходе новички чаще всего теряют доступ к серверу или спотыкаются о загадочный Permission denied. Разберём частые ошибки SSH-ключей на сервере по симптому, причине и решению с командами. Почти все они сводятся к правам на файлы, неверному пользователю и порядку отключения паролей — и решаются, если знать, куда смотреть.

Permission denied (publickey) при входе

Самая частая ошибка: вы настроили ключ, но при входе сервер отвечает Permission denied (publickey) и не пускает. Причин несколько, разберём по порядку. Первым делом запустите SSH в подробном режиме, он покажет, что именно происходит при аутентификации.

ssh -v user@ВАШ_IP

Подробный вывод покажет, какой ключ клиент предлагает и как сервер реагирует. Частая причина — клиент предлагает не тот ключ: если файл ключа лежит не в стандартном месте, укажите его явно параметром -i. Вторая причина — на сервере нет вашего открытого ключа в authorized_keys, или он записан с ошибкой, например разорван на несколько строк при копировании вручную. Открытый ключ должен быть одной сплошной строкой. Третья и самая частая причина — неправильные права на файлы, о чём отдельный раздел ниже.

Слишком открытые права на файлы

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

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

Каталог .ssh должен быть доступен только владельцу (700), файл authorized_keys — только владельцу на чтение и запись (600). Не менее важен владелец: файлы должны принадлежать самому пользователю, а не root. Частая ошибка возникает, когда каталог .ssh или файл создавались от root, например при ручном копировании, и пользователь не может ими воспользоваться. Исправьте владельца командой chown на нужного пользователя. При подробном выводе SSH в логах сервера видно сообщение о плохих правах — это прямая подсказка, что дело именно в них.

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

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

Выход один — аварийный доступ через панель провайдера. Практически все хостинги дают консоль VNC или recovery-режим, минуя SSH. Зайдите через неё и временно верните парольный вход, чтобы восстановить доступ, либо сразу исправьте проблему с ключом.

nano /etc/ssh/sshd_config
systemctl restart ssh

Верните PasswordAuthentication yes на время, зайдите, спокойно доведите настройку ключа до рабочего состояния, проверьте вход по ключу и только потом снова отключайте пароли. На будущее запомните порядок: правка sshd_config, перезапуск, проверка входа по ключу в НОВОЙ сессии при живой старой, и лишь затем закрытие рабочего соединения.

Настройки sshd_config не применяются

Вы прописали PasswordAuthentication no, но сервер всё равно пускает по паролю, или наоборот, изменения будто игнорируются. На современных системах причина часто в том, что основной sshd_config подключает дополнительные файлы из каталога sshd_config.d, и один из них переопределяет ваш параметр. Итоговое значение определяется не только главным файлом.

Проверьте, какие файлы подключены и что реально применяется.

grep -r PasswordAuthentication /etc/ssh/
sshd -T | grep -i passwordauthentication

Команда sshd -T показывает итоговую эффективную конфигурацию сервера с учётом всех подключённых файлов — это истина в последней инстанции. Если она показывает не то, что вы задали в основном файле, ищите переопределение в каталоге sshd_config.d, где облачные образы часто кладут свои файлы, например разрешающие пароли. Поправьте или уберите конфликтующий файл. Важно и не забыть перезапустить сервис после правки: без перезапуска SSH продолжает работать со старой конфигурацией, и это ещё одна частая причина, почему изменения будто не действуют.

Root не может зайти по ключу

Вы настроили ключ для root, но вход под ним не проходит, хотя для обычного пользователя всё работает. Причина в параметре PermitRootLogin. Если он стоит в значении no, root не пустят вообще, даже по ключу. Для аварийного доступа по ключу нужно значение prohibit-password, которое разрешает root вход по ключу, но запрещает по паролю.

grep PermitRootLogin /etc/ssh/sshd_config
sshd -T | grep permitrootlogin

Проверьте эффективное значение через sshd -T. Если стоит prohibit-password, а вход всё равно не проходит, вернитесь к правам и содержимому authorized_keys именно в домашнем каталоге root, который обычно /root/.ssh/authorized_keys, а не в каталоге обычного пользователя. Ключ должен лежать именно там. Отмечу, что вход root по ключу удобен для аварийных ситуаций, но в повседневной работе безопаснее заходить обычным пользователем и повышать права через sudo, оставив root только как запасной вариант.

Ключ с парольной фразой спрашивает её каждый раз

Не столько ошибка, сколько неудобство: вы защитили ключ парольной фразой, и теперь она спрашивается при каждом подключении. Это нормальное поведение, но его можно сделать удобнее с помощью ssh-agent, который держит расшифрованный ключ в памяти на время сессии, и фраза спрашивается один раз.

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

После добавления ключа в агент подключения проходят без повторного ввода фразы до конца сессии. Не отказывайтесь от парольной фразы ради удобства — лучше использовать агент. На своём рабочем компьютере агент обычно уже запущен окружением рабочего стола, и ключ добавляется автоматически. Это сочетание даёт и безопасность зашифрованного ключа, и удобство входа без постоянного ввода фразы. Если же фраза спрашивается, хотя вы её не задавали, значит, клиент предлагает не тот ключ — проверьте, какой файл используется.

Частые вопросы