Отключение парольного входа по SSH без риска запереть себя снаружи
Работа только по ключам — самое сильное одиночное изменение для открытого SSH-сервера. Безопасный порядок действий, строки конфигурации, которые действительно решают, и то, чего это не чинит.
Почему это самое ценное изменение
Почти любой захват Linux-сервера, смотрящего в интернет, начинается с действующего пароля — угаданного, переиспользованного из чужой утечки или выуженного фишингом. Отключите парольную аутентификацию — и весь этот класс перестаёт быть возможным. Не сложнее: невозможен. Подбирать нечего.
Ничто другое в чек-листе харденинга не даёт столько при таких затратах. Это две строки конфигурации и перезагрузка конфига.
Откладывают это из-за риска сделать неправильно, и риск настоящий: перепутайте порядок — и отключите себя от машины, к которой есть доступ только по SSH. Остальная часть руководства — это и есть порядок.
Безопасная последовательность
Каждый шаг ниже проверяется до того, как делается следующий, а сессия, в которой вы находитесь, остаётся открытой всё время. Не закрывайте её до самого конца.
Сначала создайте ключ, если его нет. Ed25519 — текущий выбор по умолчанию: короче, быстрее и не слабее 4096-битного RSA.
# 1. На своей машине, а не на сервере
ssh-keygen -t ed25519 -C "you@example.com"
# 2. Скопировать публичный ключ на сервер (пароль спросят в последний раз)
ssh-copy-id user@server
# 3. Проверить из ВТОРОГО терминала, не закрывая первый
ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no user@serverКонфигурация, которая действительно решает
Только после успешного шага 3 правьте конфигурацию сервера. На современных дистрибутивах править надо, возможно, не сам sshd_config: многие поставляют каталог /etc/ssh/sshd_config.d/, файлы которого подключаются и могут переопределить написанное выше.
Работу делают четыре настройки:
# /etc/ssh/sshd_config.d/10-hardening.conf (или прямо sshd_config)
PasswordAuthentication no
KbdInteractiveAuthentication no # старое имя: ChallengeResponseAuthentication
PermitRootLogin prohibit-password # или 'no', если root не входит напрямую
PubkeyAuthentication yes
# Всегда проверяйте конфиг перед перезагрузкой — это ловит опечатки,
# из-за которых sshd мог бы вообще не подняться:
sudo sshd -t
# Затем reload, а не restart: существующие сессии выживают
sudo systemctl reload ssh # или 'sshd' в семействе RHELКак убедиться, что применилось
Не доверяйте файлу конфигурации — спросите у sshd, во что он это фактически развернул. sshd -T печатает эффективную конфигурацию после всех включений и переопределений:
sudo sshd -T | grep -iE 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'
# ожидается:
# passwordauthentication no
# kbdinteractiveauthentication no
# permitrootlogin prohibit-password
# И докажите снаружи: это должно быть отвергнуто
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password user@serverЧего это не чинит
Ключи убирают риск подбора. Они не убирают трафик и не закрывают все пути внутрь.
Боты продолжают подключаться. Они не знают вашей конфигурации, поэтому продолжают предлагать пароли и получать отказ — каждая попытка по-прежнему стоит TCP-соединения, форка sshd и строки в логе. Ваш лог аутентификации по-прежнему забивается шумом, а нужное вам событие по-прежнему устаревает. Кто-то всё равно должен блокировать источники.
И приватный ключ — это файл. На ноутбуке, который украли; в репозитории, куда его закоммитили по ошибке; в окружении CI-раннера. Защищайте ключи парольной фразой, не держите на общих машинах и ротируйте при уходе людей — утёкший ключ ровно так же плох, как утёкший пароль.
Это также ничего не делает с непропатченным sshd, открытым сервисом на другом порту или уязвимым приложением на том же хосте. Это лучшее доступное изменение и одна мера из нескольких.
Что идёт в паре
С отключёнными паролями остаётся объём. SSH Protector читает тот же поток аутентификации, банит источники, которые продолжают приходить, — подсетями, навсегда, с восстановлением при загрузке — и вносит ваш адрес в белый список раньше любой блокировки.
Он определяет реальный порт SSH по конфигурации sshd, а не считает, что это 22, так что сервер, который вы уже перенесли, защищён без единой настройки.
Ключи — от риска. Бан источников — от нагрузки и ради читаемого лога, в котором вы заметите то самое единственное значимое событие.
FAQ
- Как безопасно отключить парольный вход по SSH?
- Создайте ключ, скопируйте его через ssh-copy-id, затем из второго терминала убедитесь, что вход только по ключу работает, пока первая сессия остаётся открытой. Только после этого ставьте PasswordAuthentication no и KbdInteractiveAuthentication no, запускайте sshd -t для проверки синтаксиса и делайте reload, а не restart. Именно открытая первая сессия делает ошибку исправимой.
- Почему SSH всё ещё спрашивает пароль после PasswordAuthentication no?
- Почти всегда по одной из двух причин. Либо KbdInteractiveAuthentication всё ещё yes, и PAM предлагает парольный запрос через другой механизм, либо файл в /etc/ssh/sshd_config.d/ подключается после вашего изменения и переопределяет его. Запустите sudo sshd -T | grep -i passwordauth, чтобы увидеть значение, до которого sshd фактически дошёл.
- Ed25519 или RSA?
- Ed25519, если что-то в вашем окружении не требует иного. Ключи заметно короче, проверка быстрее, а стойкость не ниже 4096-битного RSA. RSA остаётся допустимым запасным вариантом для старых устройств и легаси-клиентов; если используете его — генерируйте не меньше 4096 бит.
- Останавливает ли работа только по ключам попытки брутфорса?
- Она делает их принципиально безуспешными — в этом и смысл. Их число она не снижает: боты не имеют способа узнать вашу конфигурацию и продолжают подключаться и предлагать пароли бесконечно. Вы по-прежнему платите за каждую попытку соединениями, форками и строками лога, так что блокировать источники всё равно стоит.