Миф: пароль из 40 символов защитит сервер

MAATRIX

Кто-то в команде предлагает простое решение: сделать пароль root на сервере длиной 40 случайных символов — и вопрос безопасности SSH закрыт раз и навсегда, никакой перебор такое не возьмёт. Логика на первый взгляд безупречна, и в одной узкой части она даже верна. Но безопасность сервера — это не про один параметр, а про модель угроз целиком, и именно здесь миф про суперпароль рассыпается.

Что в этом мифе правда

Начнём с честной части: чем длиннее и случайнее пароль, тем экспоненциально дороже его перебор. Пароль из 8 символов в нижнем регистре — это 26^8, около 2×10^11 комбинаций, современный кластер с GPU разбирает такое пространство за разумное время при офлайн-переборе хэша. Пароль из 40 случайных символов из большого алфавита (буквы верхнего и нижнего регистра, цифры, спецсимволы — то есть алфавит около 90 символов) — это уже 90^40, число с примерно 78 нулями. Прямой перебор именно этого конкретного секрета методом полного перебора комбинаций действительно становится вычислительно бессмысленным на любом обозримом горизонте, при текущих доступных вычислительных мощностях.

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

Где ломается модель "пароль = секрет, который никто не узнает"

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

• Кейлоггер на клиентской машине. Если ноутбук, с которого вы заходите на сервер, скомпрометирован (вредонос, вредоносное расширение браузера, вредоносный менеджер буфера обмена), кейлоггер зафиксирует пароль в момент набора — неважно, 8 в нём символов или 40. Ключ SSH в этой ситуации ведёт себя принципиально иначе: секретная часть пары (приватный ключ) никогда не покидает машину и не вводится посимвольно — она используется криптографическим модулем локально для подписи challenge, а по сети уходит только подпись, из которой восстановить приватный ключ вычислительно невозможно.
• Плечевой сёрфинг и запись экрана. Пароль, который вводится каждый раз заново, рано или поздно виден кому-то рядом, на записи видеозвонка с расшаренным экраном, на скриншоте случайно попавшего в кадр терминала.
• Случайный коммит в текстовый файл. Пароли имеют неприятное свойство оседать в истории команд шелла (~/.bash_history), в скриптах автоматизации, в файлах .env, которые кто-то по ошибке закоммитил в публичный репозиторий. Поиск на GitHub по паттернам password= регулярно находит именно такие утечки — и длина пароля тут вообще не защита, потому что утечка происходит не через перебор, а через прямое раскрытие значения.
• Фишинг и социальная инженерия. Никто не перебирает 40-символьный пароль — гораздо проще создать поддельную страницу входа, письмо от "техподдержки хостинга" с просьбой ввести пароль, или позвонить и представиться инженером безопасности. Человек, который держит пароль в голове или в файле, физически способен его назвать или ввести туда, куда его попросят — сложность пароля этому не мешает никак.

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

Пароль не убирает шум и нагрузку от постоянного перебора

Второй пласт проблемы — даже если ваш конкретный 40-значный пароль в принципе не подбираем, парольная аутентификация как механизм остаётся включённой и видимой на порту. Любой сервер с белым IP-адресом обнаруживается автоматическими сканерами в течение минут-часов после запуска, и на порт 22 тут же начинают идти попытки подключения ботов из ботнетов, перебирающих типовые логины (root, admin, ubuntu, test) со словарями популярных паролей.

Что это даёт атакующему при вашем неподбираемом пароле? Ничего — ни один пароль из словаря не подойдёт. Но что это даёт вам:

• Постоянный фоновый шум в /var/log/auth.log — тысячи записей Failed password в сутки, из-за которых реальную аномалию (например, попытку входа с необычного логина или гео) сложнее заметить в логах.
• Нагрузку на процесс sshd от обработки каждой попытки подключения — на слабом VPS это заметная доля CPU и I/O, особенно если ботов много одновременно.
• Саму открытую поверхность атаки: включённая парольная аутентификация — это работающий, отвечающий на запросы сервис, а любой работающий сервис — потенциальный вектор через будущую уязвимость в самом OpenSSH (такие уязвимости случаются не часто, но случаются, и известный пример — regreSSHion CVE-2024-6387 в 2024 году).

Отключение парольного входа (PasswordAuthentication no в /etc/ssh/sshd_config) в пользу ключей не делает пароль более стойким — оно убирает саму категорию атаки. Боты продолжат стучаться, но sshd будет отвечать им Permission denied (publickey) без единого шанса на попадание, вне зависимости от того, что они перебирают. Как поставить ключи и безопасно отключить пароль пошагово — в статье как установить и настроить SSH-ключи вместо пароля на VPS; там же разобраны типичные ошибки, из-за которых люди случайно блокируют себе доступ при переключении.

Длина пароля ничего не решает вне периметра самого входа по SSH

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

Уязвимость в другом сервисе на сервере. Если на сервере крутится веб-приложение с дырой (устаревшая CMS, незапатченная библиотека, инъекция в API), злоумышленник получает шелл через веб-сервис, минуя SSH целиком. Пароль от SSH-доступа в этом сценарии вообще не участвует — атакующий уже внутри системы. Разбор реального случая, когда компрометация пришла именно так, — в статье сервер взломали через забытый порт: реконструкция.

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

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

Во всех трёх случаях 40-символьный пароль от SSH — это неприступная стена вокруг двери, когда стены вокруг дома нет вообще.

Как на самом деле выглядит защищённый вход на сервер

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

Практический минимум для нового сервера выглядит так:

# 1. Генерируем пару ключей на клиенте (не на сервере!)
ssh-keygen -t ed25519 -C "you@example.com"
# на вопрос про passphrase — не оставляйте пустым

# 2. Копируем публичный ключ на сервер
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server_ip

# 3. Проверяем, что вход по ключу работает,
#    и только после этого отключаем пароль
ssh user@server_ip   # должно пустить без запроса пароля

# 4. На сервере правим /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no

# 5. Перезапускаем sshd (в отдельной сессии,
#    не закрывая текущую — на случай ошибки конфига)
sudo systemctl restart sshd

Дальше — fail2ban как дополнительный слой против оставшегося автоматизированного шума (баны по IP за подозрительную активность даже в сервисах, где пароля нет вовсе), и, при желании, смена порта SSH с 22 на нестандартный — это не столько защита, сколько снижение фонового шума в логах, потому что целенаправленная атака найдёт порт сканированием за секунды. Установка и тонкая настройка fail2ban разобраны в статье как установить и настроить fail2ban на VPS.

Отдельный практический нюанс: если ключ где-то потерян или недоступен (сменился ноутбук, затёрся диск), восстановление доступа к серверу без пароля требует другого пути — через консоль провайдера или recovery-режим, а не через "вспомнить пароль". Это разобрано в статье потерян SSH-ключ: как вернуть доступ — стоит заранее понимать этот сценарий, а не сталкиваться с ним впервые в момент, когда доступ уже нужен.

Почему интуиция про "длину = безопасность" вообще возникает

Она возникает не на пустом месте — в криптографии длина ключа действительно напрямую определяет стойкость к перебору, и это верно, скажем, для длины ключа шифрования AES или для размера RSA-ключа. Проблема в переносе этой интуиции на пароль, вводимый человеком по сети, где угроза номер один — почти никогда не прямой перебор случайного 40-значного значения (это статистически редкая и дорогая для атакующего атака против конкретной цели), а куда более дешёвые и массовые векторы: словарные атаки против типовых логинов на тысячах случайных серверов подряд, фишинг, вредоносное ПО на клиенте, забытые открытые сервисы. Длинный пароль оптимизирует защиту именно от той угрозы, которая и так статистически маловероятна, оставляя без изменений все остальные, куда более вероятные пути входа.

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

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