SSH

Как обычно взламывают доступ по SSH

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

Как усилить SSH без потери доступа

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

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

Как проверить, что SSH сервер делает на самом деле

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

sudo ss -tlnp | grep sshd
sudo sshd -T | grep -iE '^(port|permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers) '
ssh -V
sudo journalctl -u ssh --since today | grep -E 'Accepted|Failed'

Первая команда выводит слушающие TCP сокеты вместе с процессом-владельцем (-t TCP, -l слушающие, -n числовой вывод, -p процесс), так что видно, на каком адресе и порту работает sshd. Вторая использует расширенный тестовый режим sshd, который, согласно руководству sshd, печатает действующую конфигурацию, а не содержимое файла, поэтому подключаемые файлы и переопределения уже учтены. Запускайте её от root, потому что sshd должен прочитать свои ключи хоста. Третья показывает версию клиента, четвёртая читает недавние входы. В Debian и Ubuntu служба обычно называется ssh, в семействе Red Hat sshd. Повторяйте проверку после каждого изменения и каждого инцидента, потому что конфигурация незаметно расходится с ожиданиями.

Ключи хоста: половина доверия в SSH, которую часто пропускают

Ваш вход доказывает серверу, кто вы. Ключ хоста доказывает вам, что это именно ваш сервер. При первом подключении ssh показывает отпечаток открытого ключа сервера и, после вашего согласия, запоминает его в ~/.ssh/known_hosts. Руководство ssh сообщает, что ssh предупреждает, если идентификация известного хоста позднее изменилась. По умолчанию (StrictHostKeyChecking ask) он спрашивает перед тем, как доверять неизвестному ключу, поэтому не вводите "yes" по привычке.

Сравните отпечаток до согласия. Один раз откройте веб-консоль провайдера и выполните на сервере:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Результат должен совпасть с тем, что показывает ваш клиент. Смена ключа нормальна после пересборки или переустановки сервера, потому что генерируются новые ключи хоста. Убедившись, что причина в этом, удалите устаревшую запись командой ssh-keygen -R your-server и подключитесь заново. Если на сервере вы ничего не меняли, остановитесь и разберитесь, а не пропускайте предупреждение: оно может означать перехват соединения. Если вы подозреваете сам сервер, порядок действий описан в руководстве по реагированию на взлом.

Связанные термины: Аутентификация по ключу, sshd_config, Вход под root, Атака подбором, PermitRootLogin, Bastion host (бастионный хост), known_hosts, Проброс SSH-агента (agent forwarding), SSH X11 forwarding (проброс X11), ssh-keygen (создание ключей OpenSSH).

В новостях: CVE-2026-35414 показывает, как один необработанный символ в сертификатной аутентификации SSH превратился в полный обход входа.