SSH: ключи вместо пароля, смена порта и защита от брутфорса

Почему пароль для SSH — плохая идея

SSH-порт любого сервера, подключённого к интернету, начинает получать автоматические попытки входа от ботов практически сразу после запуска — это не гипотетическая угроза, а фоновый шум интернета: специализированные боты постоянно сканируют диапазоны IP-адресов и пробуют стандартные логины (root, admin, ubuntu) с популярными или простыми паролями.

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

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

Как работает аутентификация по ключу

В основе лежит асимметричная криптография: генерируется пара математически связанных ключей — приватный (закрытый) и публичный (открытый). Приватный ключ остаётся только на вашем компьютере и никогда никуда не передаётся; публичный ключ можно свободно копировать куда угодно, в том числе на любое количество серверов — по своей природе он не даёт возможности восстановить из него приватный ключ.

При попытке подключения сервер не запрашивает у клиента сам ключ — вместо этого он отправляет клиенту случайную строку данных (challenge), клиент подписывает её своим приватным ключом и отправляет подпись обратно. Сервер проверяет эту подпись с помощью публичного ключа, который заранее сохранён в файле ~/.ssh/authorized_keys, — если подпись математически совпадает, значит запрос действительно пришёл от обладателя приватного ключа, и доступ предоставляется без единого пароля, передаваемого по сети.

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

Шаг 1. Генерация пары ключей

На своём компьютере (не на сервере) выполните команду ssh-keygen -t ed25519 -C "комментарий" — алгоритм Ed25519 рекомендуется для новых ключей: он даёт короткие ключи с высокой криптографической стойкостью и работает быстрее классического RSA. Если инструмент на другой стороне не поддерживает Ed25519 (редкость на современных системах), используйте ssh-keygen -t rsa -b 4096 как надёжную альтернативу.

При генерации будет предложено задать passphrase — дополнительный пароль, который шифрует сам файл приватного ключа на диске. Это необязательный, но настоятельно рекомендуемый шаг: без passphrase кража самого файла ключа (например, с ноутбука) сразу даёт доступ ко всем серверам, где этот ключ добавлен; с passphrase злоумышленнику потребуется вдобавок узнать эту фразу.

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

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

Самый простой способ — команда ssh-copy-id пользователь@адрес-сервера, которая подключится к серверу (запросив пароль в последний раз) и автоматически добавит содержимое вашего публичного ключа в файл ~/.ssh/authorized_keys нужного пользователя, создав файл и директорию с правильными правами доступа, если их ещё не было.

Если ssh-copy-id недоступен (например, на Windows без дополнительных утилит), тот же результат достигается вручную: скопируйте содержимое файла id_ed25519.pub и добавьте его отдельной строкой в файл ~/.ssh/authorized_keys на сервере через любой текстовый редактор. Важно, чтобы у директории ~/.ssh были права 700, а у самого файла authorized_keys — права 600, иначе SSH может отказаться использовать ключ из соображений безопасности.

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

Шаг 3. Проверка входа по ключу — до отключения пароля

Прежде чем отключать вход по паролю, обязательно откройте новое, отдельное окно терминала (не закрывая текущую сессию) и попробуйте подключиться заново: ssh пользователь@адрес-сервера. Если всё настроено правильно, подключение пройдёт без запроса пароля — либо с запросом passphrase, если вы его задавали при генерации ключа, что является ожидаемым поведением.

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

Шаг 4. Отключение входа по паролю

Откройте файл конфигурации SSH-демона /etc/ssh/sshd_config от имени root или через sudo и найдите (или добавьте) строку PasswordAuthentication — установите значение no. Дополнительно рекомендуется установить ChallengeResponseAuthentication no и UsePAM no (если PAM не используется для других целей вроде двухфакторной аутентификации), чтобы полностью исключить альтернативные способы входа по паролю в обход основного механизма.

После изменения конфигурации перезапустите службу SSH командой systemctl restart sshd (или ssh на некоторых дистрибутивах) — обратите внимание, что перезапуск не разрывает уже открытые сессии, поэтому если вы подключены по SSH прямо сейчас, соединение не оборвётся, но новые попытки входа по паролю будут отклоняться сразу.

Ещё раз откройте новую сессию в отдельном окне терминала и убедитесь, что вход по ключу по-прежнему работает, а попытка ввести пароль (если временно вернуть PasswordAuthentication на yes для теста) действительно отклоняется. Только после этой финальной проверки можно быть уверенным, что настройка выполнена корректно и без риска потери доступа.

Шаг 5. Отключение прямого входа под root

Даже с отключённым паролем прямой вход под root остаётся излишним риском: если приватный ключ, привязанный к root, будет скомпрометирован, злоумышленник сразу получает полный контроль над сервером без промежуточных шагов. Правильная практика — создать отдельного пользователя с правами sudo для повседневной работы и запретить прямой вход под root через параметр PermitRootLogin no в том же файле sshd_config.

Создать нового пользователя и добавить его в группу с правами sudo можно командами adduser имя_пользователя и usermod -aG sudo имя_пользователя (для Debian/Ubuntu) — после этого не забудьте скопировать публичный ключ и в файл authorized_keys нового пользователя, иначе после отключения root окажется, что входить попросту не через кого.

При необходимости выполнить действия от имени root после входа под обычным пользователем используется команда sudo — она запрашивает пароль именно этого пользователя (не root) и логирует, какая команда была выполнена и от чьего имени, что дополнительно помогает при разборе инцидентов на сервере с несколькими администраторами.

Шаг 6. Смена порта SSH по умолчанию

Порт 22 — это первый порт, который проверяют автоматические сканеры и боты при массовом сканировании диапазонов адресов. Смена порта на нестандартный (любое значение от 1024 до 65535, не занятое другими службами) не делает сервер неуязвимым — это мера класса «security through obscurity», — но на практике на порядок снижает фоновый шум от автоматических ботов в логах и нагрузку от постоянных бессмысленных попыток входа.

Порт меняется той же директивой Port в /etc/ssh/sshd_config. Критически важно перед перезапуском службы также открыть новый порт в firewall (ufw allow новый_порт/tcp или аналогичная команда для используемого фаервола) — если открыть только новый порт SSH-демона, но не разрешить его на уровне firewall, соединение будет заблокировано ещё до того, как дойдёт до SSH, и восстанавливать доступ придётся через консоль провайдера.

После смены порта не забудьте использовать его явно при подключении: ssh -p новый_порт пользователь@адрес-сервера — и обновить эту настройку в любых используемых SFTP/SCP-клиентах и скриптах автоматизации, которые ранее подключались к порту 22 по умолчанию.

Шаг 7. fail2ban — автоматическая блокировка за подбор

fail2ban — это сервис, который анализирует логи системы в реальном времени и временно блокирует на уровне firewall IP-адреса, с которых зафиксировано подозрительное количество неудачных попыток входа за короткий промежуток времени. Даже с отключённым паролем fail2ban полезен: он снижает нагрузку от постоянных попыток подключения ботов и дополнительно защищает другие сервисы на сервере — веб-формы входа, FTP, почтовые сервисы — если настроить для них соответствующие правила (jails).

Установка на Ubuntu/Debian выполняется командой apt install fail2ban, после чего базовая защита SSH обычно включена по умолчанию в конфигурации jail для sshd. Рекомендуется скопировать файл /etc/fail2ban/jail.conf в /etc/fail2ban/jail.local и вносить изменения именно в копию — оригинальный файл может быть перезаписан при обновлении пакета, а .local-версия имеет приоритет и сохраняется.

Типичные параметры для тонкой настройки: maxretry (число неудачных попыток до блокировки, обычно 3–5), findtime (интервал времени, за который считаются попытки) и bantime (продолжительность блокировки — от нескольких минут для мягкого режима до нескольких часов или постоянной блокировки для более строгого). Полезно также задать ignoreip с вашим собственным статичным IP-адресом, чтобы случайно не заблокировать самого себя при ошибках ввода.

Дополнительные меры: 2FA и ограничение по IP

Для серверов с повышенными требованиями к безопасности можно добавить двухфакторную аутентификацию поверх ключа — например, через модуль Google Authenticator для PAM, который запрашивает одноразовый код из приложения на телефоне в дополнение к SSH-ключу. Это защищает даже в теоретическом сценарии кражи приватного ключа вместе с его passphrase.

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

Обе меры — усиление, а не замена базовой связки «ключ + отключённый пароль + отключённый root + fail2ban», которая закрывает подавляющее большинство реальных угроз для типичного сервера без специфических требований к безопасности.

Настройка Google Authenticator для SSH на Ubuntu/Debian выполняется через пакет libpam-google-authenticator: после установки команда google-authenticator, запущенная от имени нужного пользователя, генерирует секретный ключ, QR-код для приложения-аутентификатора на телефоне и набор одноразовых резервных кодов на случай утери телефона — их стоит сохранить в надёжном месте отдельно от самого сервера.

Дальше нужно подключить модуль в /etc/pam.d/sshd (строка auth required pam_google_authenticator.so) и включить ChallengeResponseAuthentication yes вместе с AuthenticationMethods publickey,keyboard-interactive в sshd_config — это указывает SSH требовать одновременно и ключ, и одноразовый код, а не любой из них по отдельности. После перезапуска службы обязательно проверьте вход в новой сессии по той же схеме, что и на предыдущих шагах.

Удобство: файл ~/.ssh/config для частых подключений

Если серверов несколько и у каждого свой порт, пользователь и файл ключа, команды подключения быстро становятся громоздкими: ssh -p 2222 -i ~/.ssh/id_work user@203.0.113.10. Файл ~/.ssh/config на локальном компьютере решает это одной записью вида «Host myserver», после которой построчно указываются HostName, Port, User и IdentityFile для этого конкретного сервера.

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

Мониторинг: как понять, что сервер атакуют

Журнал попыток аутентификации на большинстве дистрибутивов доступен командой journalctl -u sshd или через файл /var/log/auth.log (Debian/Ubuntu) — в нём видны все попытки входа, включая отклонённые, с указанием времени, имени пользователя и IP-адреса источника. После настройки fail2ban там же видны записи о временных блокировках.

Резкий рост числа записей о неудачных попытках входа за короткий период — не обязательно повод для паники, если базовые меры (ключ вместо пароля, fail2ban) уже настроены: это тот самый фоновый шум ботов, который сервер теперь просто отражает автоматически. Поводом для более пристального внимания служит успешный вход с неизвестного IP-адреса или в необычное время — это стоит проверять вручную и, при сомнениях, сразу сменить ключи.

Команда fail2ban-client status sshd показывает текущее состояние конкретного jail: сколько адресов заблокировано прямо сейчас и сколько попыток было отражено за всё время работы сервиса — удобный способ быстро оценить интенсивность фонового шума без разбора полного журнала вручную. Для разовой проверки конкретного адреса удобна команда grep "искомый IP" /var/log/auth.log, которая покажет все связанные с ним записи.

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

Типичные ошибки при настройке

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

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

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

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

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

Чек-лист безопасной настройки SSH с нуля

Сгенерируйте пару ключей Ed25519 с passphrase на своём компьютере. Скопируйте публичный ключ на сервер через ssh-copy-id. Проверьте вход по ключу в новой сессии терминала, не закрывая текущую. Только после успешной проверки отключите PasswordAuthentication в sshd_config и перезапустите службу — и снова проверьте вход в новой сессии.

Создайте отдельного пользователя с правами sudo и перенесите на него свой публичный ключ, затем отключите PermitRootLogin. Смените порт SSH на нестандартный, не забыв открыть новый порт в firewall до перезапуска службы. Установите и настройте fail2ban для сервиса sshd с разумными значениями maxretry и bantime.

При повышенных требованиях к безопасности добавьте двухфакторную аутентификацию и ограничение доступа по IP-адресам. Периодически проверяйте журнал auth.log на подозрительную активность и содержимое authorized_keys на устаревшие ключи, которые пора отозвать.

Что делать, если доступ всё же потерян

Если по SSH попасть на сервер больше не получается — например, из-за ошибки в правилах firewall или опечатки в конфигурации sshd, — не паникуйте: у большинства провайдеров VPS, включая Timeweb Cloud, в панели управления есть встроенная веб-консоль (VNC или serial console), которая подключается напрямую к виртуальному терминалу сервера в обход сети и SSH. Через неё можно войти под тем же пользователем и паролем (если он ещё не отключён на уровне системы, а не только SSH) или в однопользовательском режиме и исправить конфигурацию.

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

Итог: минимальный набор мер для любого нового сервера

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

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