SSH: отключение входа по паролю и защита сервера

Отключение SSH-пароля — одна из самых опасных настроек на VPS, если сделать её в неправильном порядке. Единственная безопасная последовательность действий выглядит так: сначала настроить и проверить вход по ключу, и только после того как ключ точно работает — отключать пароль. Нарушение этого порядка означает, что можно навсегда потерять доступ к серверу, если у хостинг-провайдера нет консольного доступа в обход SSH.

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

Зачем отключать SSH-пароль

Любой VPS с открытым SSH-портом постоянно сканируют боты, перебирающие логины и пароли. Даже сложный пароль теоретически можно подобрать при достаточном количестве попыток, а слабый пароль подбирается быстро. SSH-ключ устроен принципиально иначе: он представляет собой пару из приватной и публичной части, где приватная часть никогда не передаётся по сети и не может быть перехвачена или подобрана перебором в разумные сроки.

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

Шаг 1: Генерация SSH-ключа

Ключ создаётся на вашем локальном компьютере, а не на сервере. Если ключ уже существует, этот шаг можно пропустить — проверить наличие можно командой ls ~/.ssh/.

Создать новую пару ключей:

ssh-keygen -t ed25519 -C "мой-рабочий-ноутбук"

Алгоритм ed25519 — современный стандарт, который работает быстрее и считается как минимум не менее безопасным, чем более старый RSA. Флаг -C добавляет комментарий к ключу для удобства — он поможет отличить этот ключ от других, если их будет несколько.

При создании система предложит указать путь для сохранения ключа — можно просто нажать Enter, чтобы использовать путь по умолчанию. Затем система предложит задать парольную фразу для самого ключа — это дополнительный уровень защиты: если файл ключа украдут, без фразы он бесполезен. Для рабочей станции разумно задать фразу; для автоматизированных задач без участия человека ключ иногда создают без фразы.

После завершения команды в директории ~/.ssh/ появятся два файла: id_ed25519 — приватный ключ, который остаётся только на вашем компьютере и никогда никому не передаётся, и id_ed25519.pub — публичный ключ, который можно свободно копировать на любые серверы.

Шаг 2: Копирование публичного ключа на сервер

Самый простой способ — специальная утилита, которая сама создаёт нужные файлы и права доступа на сервере:

ssh-copy-id user@адрес_сервера

Система запросит пароль от сервера один последний раз, скопирует публичный ключ и настроит все необходимые права доступа автоматически.

Если утилита ssh-copy-id недоступна, тот же результат достигается вручную:

cat ~/.ssh/id_ed25519.pub | ssh user@адрес_сервера "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Шаг 3: Проверка прав доступа на сервере

Это критично важный шаг, о котором часто забывают. SSH на сервере проверяет права доступа к файлу authorized_keys и к директории .ssh — если права слишком открытые, SSH из соображений безопасности полностью игнорирует содержимое файла, даже если ключ там присутствует. Именно эта деталь чаще всего стоит за загадочной ситуацией «ключ добавлен, но сервер всё равно просит пароль».

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

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

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

Шаг 4: Обязательная проверка входа по ключу

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

ssh user@адрес_сервера

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

Шаг 5: Резервная копия конфигурации перед изменениями

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

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Шаг 6: Отключение SSH-пароля в конфигурации

Только теперь, когда вход по ключу проверен и работает, можно редактировать конфигурацию SSH-демона:

sudo nano /etc/ssh/sshd_config

Найдите или добавьте следующие параметры:

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Параметр PasswordAuthentication no полностью отключает вход по паролю. PubkeyAuthentication yes явно разрешает вход по ключу — обычно это значение уже установлено по умолчанию, но полезно указать его в конфигурации явно, чтобы не зависеть от значений по умолчанию в разных версиях SSH.

Для управления доступом root по SSH есть отдельный параметр:

PermitRootLogin prohibit-password

Значение prohibit-password означает, что root может подключиться только по ключу, но не по паролю — компромисс между удобством и безопасностью. Если доступ root по SSH не нужен вообще, используйте более строгое значение PermitRootLogin no.

Шаг 7: Проверка конфигурации перед применением

Прежде чем перезапускать SSH-демон, обязательно проверьте синтаксис изменённого файла — если в конфигурации есть ошибка, SSH-демон может не запуститься после перезапуска, что равносильно потере доступа к серверу:

sudo sshd -t

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

Шаг 8: Применение изменений

Перезапустите SSH-демон, чтобы применить новую конфигурацию:

sudo systemctl restart sshd

На некоторых системах Ubuntu сервис может называться иначе:

sudo systemctl restart ssh

Шаг 9: Финальная проверка в новом окне

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

ssh user@адрес_сервера

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

sudo cp /etc/ssh/sshd_config.backup /etc/ssh/sshd_config
sudo systemctl restart sshd

Дополнительные меры защиты

После отключения пароля можно усилить конфигурацию SSH ещё несколькими параметрами в том же файле /etc/ssh/sshd_config.

Ограничение числа попыток аутентификации за одно подключение снижает эффективность автоматизированных атак:

MaxAuthTries 3

Ограничение времени на аутентификацию после установки соединения:

LoginGraceTime 30

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

AllowUsers ваш_логин

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

Смена стандартного порта SSH

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

Port 2222

Важно: прежде чем перезапускать SSH-демон с новым портом, откройте этот порт в файрволе сервера — иначе после перезапуска подключиться будет попросту некуда:

sudo ufw allow 2222/tcp

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

ssh -p 2222 user@адрес_сервера

Часто задаваемые вопросы

Что произойдёт если отключить SSH-пароль до проверки ключа?

Если ключ настроен неправильно или права доступа к файлу authorized_keys некорректны, а пароль уже отключён — вход на сервер станет невозможен ни одним из способов. Восстановить доступ в такой ситуации можно только через консольный доступ хостинг-провайдера в обход SSH, если он предусмотрен, или через полную переустановку сервера. Именно поэтому проверка входа по ключу в новом окне терминала должна происходить строго до отключения пароля, а не после.

Почему SSH всё равно запрашивает пароль хотя ключ уже добавлен?

Самая частая причина — неправильные права доступа к файлу ~/.ssh/authorized_keys или к директории ~/.ssh на сервере. SSH из соображений безопасности полностью игнорирует ключи в файле, если права слишком открытые. Исправляется командами chmod 700 ~/.ssh и chmod 600 ~/.ssh/authorized_keys.

В чём разница между PermitRootLogin no и prohibit-password?

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

Нужно ли менять порт SSH ради безопасности?

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

Как восстановить доступ если я всё же заблокировал себя?

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

Официальная документация: man.openbsd.org/sshd_config

Прежде чем экспериментировать с настройками SSH на боевом сервере, убедитесь что у вас есть запасной путь для восстановления доступа. На UFO.Hosting каждый VPS поставляется с доступом к веб-консоли через личный кабинет — она работает независимо от SSH и позволяет восстановить доступ даже при ошибке в конфигурации.