Security Guide

Базовая настройка SSH: вход по ключам вместо пароля

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

01.09.2026 Обновлено: 01.09.2026 8 мин Начальный
Проверено: Ubuntu 24.04, Debian 12 Версия: OpenSSH 9.6 Нужно знать: Доступ к серверу по SSH с паролем
Базовая настройка SSH: вход по ключам вместо пароля

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

Что решает эта инструкция

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

Когда это нужно

  • Новый сервер, который смотрит в интернет
  • В логах много строк Failed password for invalid user
  • Нужен беспарольный доступ для скриптов и Ansible

Что потребуется

  • Текущий доступ к серверу по паролю
  • OpenSSH на локальной машине (в Windows 10/11 встроен)
  • Вторая открытая SSH-сессия — страховка на случай ошибки в конфиге

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

Шаг 1: сгенерировать пару ключей

На локальной машине, не на сервере:

ssh-keygen -t ed25519 -C "admin@laptop" -f ~/.ssh/id_ed25519_server

Почему ed25519, а не RSA: короче, быстрее, стойкость выше при меньшем размере. Поддерживается OpenSSH с версии 6.5 (2014 год).

Ключи:

  • -t ed25519 — тип ключа
  • -C — комментарий, попадёт в конец публичного ключа; помогает понять, чей это ключ, когда их накопится десяток
  • -f — путь к файлу; отдельное имя удобнее, чем общий id_ed25519 для всех серверов

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

Получится два файла:

  • id_ed25519_server — приватный ключ, никогда никуда не передаётся
  • id_ed25519_server.pub — публичный, его и ставим на сервер

Шаг 2: скопировать публичный ключ на сервер

ssh-copy-id -i ~/.ssh/id_ed25519_server.pub user@server

Утилита сама создаст ~/.ssh/authorized_keys с правильными правами. Если ssh-copy-id недоступен (например, в Windows), делаем вручную:

cat ~/.ssh/id_ed25519_server.pub | ssh user@server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Совет. Права критичны. SSH игнорирует authorized_keys, если у каталога .ssh права шире 700 или у файла шире 600 — и молча откатывается на пароль.

Шаг 3: проверить вход по ключу

В новом окне терминала, не закрывая текущее:

ssh -i ~/.ssh/id_ed25519_server user@server

Должно пустить без запроса пароля. Если запрашивает — не идите дальше, сначала разберитесь (раздел «Возможные проблемы»).

Шаг 4: отключить парольный вход

Только после успешной проверки. На сервере:

sudo nano /etc/ssh/sshd_config

Приводим три параметра к такому виду:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Третий параметр важен: без него на части систем остаётся обходной путь через PAM, и пароли продолжают приниматься.

Проверяем синтаксис до перезапуска:

sudo sshd -t

Пустой вывод — ошибок нет. Применяем:

sudo systemctl reload ssh

reload, а не restart — текущие сессии не разорвутся.

Шаг 5: упростить подключение

Чтобы не писать длинную команду каждый раз, добавьте на локальной машине в ~/.ssh/config:

Host myserver
    HostName 203.0.113.10
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519_server
    IdentitiesOnly yes

Теперь достаточно ssh myserver. Параметр IdentitiesOnly yes заставляет использовать именно указанный ключ — без него SSH переберёт все ключи из агента и может упереться в лимит попыток.

Проверка результата

Убедитесь, что пароли действительно отключены:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password user@server

Ожидаемый ответ — Permission denied (publickey). Значит сервер больше не принимает пароли.

Возможные проблемы

Всё ещё спрашивает пароль

Смотрим подробный вывод клиента:

ssh -vvv -i ~/.ssh/id_ed25519_server user@server 2>&1 | grep -i "offering\|denied\|authentications"

Чаще всего причина — права на файлы. Исправляем на сервере:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

Permission denied после отключения паролей

Если вторая сессия ещё открыта — верните PasswordAuthentication yes и перезагрузите sshd. Если сессий не осталось, поможет только консоль провайдера (VNC или recovery-режим).

Ключ не подходит для root

Проверьте PermitRootLogin в sshd_config. Значение prohibit-password разрешает root только по ключу, no запрещает полностью.

Итог

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

Читайте также