Защита SSH: распространенные мисконфигурации и как их исправить
Введение
Secure Shell (SSH) — сетевой протокол и программный набор для безопасного удаленного доступа к системам. SSH шифрует весь трафик (включая вводимые логины, пароли и команды), заменяя собой небезопасные средства вроде Telnet. Он позволяет администраторам удаленно управлять серверами, сетевым оборудованием и IoT‑устройствами, не опасаясь перехвата данных. Протокол SSH стал стандартным инструментом администрирования для Unix‑подобных систем, а начиная с недавнего времени в Windows по умолчанию доступен OpenSSH‑клиент.
SSH‑клиент устанавливает зашифрованный канал с SSH‑сервером, после чего на удаленной системе можно выполнять команды, передавать файлы или организовывать туннелирование портов. По данным из открытых источников, SSH обеспечивает доступ к более чем 38 миллионам серверов в открытом интернете, поэтому его безопасность критически важна.
Ранее мы рассматривали способы злоупотребления ssh.exe на Windows. В этой статье разберем, как протокол SSH работает на Unix‑подобных системах и на какие настройки следует обратить внимание. Также покажем, как выявлять мисконфигурации и атаки на SSH, на примере решения BI.ZONE EDR. В конце вы можете скачать Ansible‑плейбук, который поможет настроить SSH на Linux‑хостах согласно рекомендациям из статьи.
Работа SSH: принципы шифрования и аутентификации
При установке SSH‑соединения первым этапом идет обмен криптографическими параметрами и согласование механизмов защиты, которые обеспечивают безопасность канала связи.
1. Обмен алгоритмами (negotiation)
Клиент и сервер обмениваются списками поддерживаемых алгоритмов и выбирают набор, который будет использоваться на следующих этапах:
- алгоритмы обмена ключами (ECDH, Curve25519);
- алгоритмы шифрования трафика (AES, ChaCha20);
- алгоритмы контроля целостности (HMAC‑SHA2);
- методы сжатия данных.
2. Обмен ключами (key exchange)
На этом этапе стороны формируют общий сеансовый ключ, который никогда не передается по сети. Применяются современные схемы на основе эллиптических кривых, обеспечивающие конфиденциальность даже при перехвате трафика. Главный результат — невозможность восстановления сеансового ключа третьими лицами, что гарантирует защищенность передаваемых данных.
3. Симметричное шифрование канала
После завершения обмена ключами весь последующий трафик шифруется симметричным алгоритмом (чаще всего AES‑GCM). Это обеспечивает полную конфиденциальность данных «на лету»: все команды, логины и результаты выполнения передаются в зашифрованном виде.
4. Контроль целостности (message authentication code, MAC)
Для каждого пакета вычисляется криптографическая контрольная сумма (hash‑based message authentication code, HMAC), позволяющая проверить неизменность данных при передаче. Это исключает возможность незаметной подмены или внедрения пакетов злоумышленником.
Таким образом, SSH формирует многоуровневую систему защиты, в которой каждое соединение последовательно проходит через этапы выбора алгоритмов, обмена ключами, шифрования и проверки целостности. Так обеспечивается надежная и устойчивая к атакам передача данных.
Основные возможности и варианты использования SSH
SSH известен прежде всего как инструмент для удаленной оболочки, но его функциональность намного шире. Рассмотрим основные режимы использования SSH и связанные с ними тонкости безопасности.
Удаленная оболочка
Классическое применение — интерактивная оболочка: администратор выполняет команду ssh user@host, проходит аутентификацию и получает консоль (shell) на удаленном сервере, работая с ним как с локальным. SSH передает ввод и вывод, эмулирует терминал и поддерживает терминальные управляющие последовательности. Это позволяет полноценно работать, запускать текстовые редакторы, консольные программы и так далее.
Второй вариант — неинтерактивный режим, когда SSH‑клиенту передается команда для выполнения, например ssh user@host "uname -a" или скрипт. В этом случае сессия выполняет команду и завершается, не предоставляя полноценной оболочки. Это удобно для автоматизации: из скриптов можно запускать команды на удаленных узлах по SSH и получать результат.
В конфигурации sshd можно различать интерактивные и неинтерактивные сессии:
- Когда открывается pty (RequestTTY), это обычно интерактивная сессия.
- Когда
sshзапущен с командой или с‑T(без pty), сессия предназначена только для выполнения команды.
При работе с удаленным доступом через SSH всегда необходимо учитывать вопросы безопасности, ведь каждая предоставленная сессия потенциально открывает путь к системе.
Минимизируйте права доступа
Если вы предоставляете пользователю SSH‑доступ, подумайте, действительно ли ему нужен полноценный shell. Во многих случаях достаточно ограничиться выполнением одной команды. В файле authorized_keys можно задать ограничения:
no-port-forwarding,no-agent-forwarding,no-X11-forwarding— отключают возможность форвардинга и туннелирования;command="..."— задает фиксированную команду, которая будет выполнена после входа.
Такой подход значительно снижает риск злоупотребления доступом. Именно по этой схеме организован доступ к git‑репозиториям по SSH (через
Ограничивайте привилегии учетных записей (УЗ)
Если доступ к оболочке все же необходим, убедитесь, что УЗ не обладает избыточными правами:
- не используйте root‑доступ без необходимости;
- не предоставляйте
sudoбез пароля; - проверяйте, что пользователь не входит в чувствительные группы, например
docker,adm,wheel.
Контролируйте время бездействия (idle timeout)
Для автоматического завершения неактивных сессий настройте параметры ClientAliveInterval и ClientAliveCountMax в конфигурации SSH‑сервера.
Эта функция работает аналогично переменной TMOUT в оболочке: если пользователь оставил терминал без присмотра, соединение будет закрыто автоматически. Это особенно важно на общих узлах (например, jumpbox‑серверах), где к консоли может подойти другой человек.
Передача файлов: SFTP vs SCP
SSH изначально задумывался не только для работы с терминалом, но и для копирования файлов. Есть две основные подсистемы:
- SCP (secure copy) — старый протокол, произошедший от
rcp(remote copy). Командаscpпозволяет копировать файлы между локальной и удаленной системой по SSH. Принцип работы прост: фактически открывается SSH‑сессия, в которую передаются команды типа «начать прием файла с таким‑то именем». SCP работает по принципу push или pull: вы запускаетеscp file user@host:/pathлибо вы запускаетеscp user@host:/path file, и файл копируется. - SFTP (SSH file transfer protocol) — полноценный протокол файловых операций поверх SSH. Это не FTP поверх SSH, а независимый бинарный протокол внутри канала SSH, поддерживающий команды типа
open file,read,write,list directoryи так далее. Фактически SFTP позволяет реализовать файловый менеджер: видеть список файлов, скачивать, загружать, переименовывать и управлять правами.
В OpenSSH 9.0 утилита scp по умолчанию использует SFTP‑протокол. То есть, вызывая scp, клиент устанавливает SFTP‑сессию и через нее передает файл. Это сделано незаметно для пользователя, чтобы не менять привычки, но избавиться от недостатков SCP.
Туннелирование и проксирование
Протокол SSH может быть использован для создания сетевых соединений через зашифрованный канал. Это называется SSH‑туннелированием (или SSH port forwarding в терминологии мануала SSH). С его помощью можно передать TCP‑пакеты с одной стороны SSH‑соединения на другую, изменив их адрес назначения по заранее заданному правилу. Таким образом можно получить удаленный доступ к ресурсам внутри закрытых сетей через одну команду SSH.
SSH‑туннель можно представить как point‑to‑point‑соединение внутри SSH‑сессии. Любой TCP‑пакет, попавший в один конец туннеля, выходит на другом конце. При этом SSH переписывает IP‑адрес и порт назначения пакета согласно маршруту, заданному при установлении туннеля.
Важно отметить, что через SSH‑туннель напрямую передается только TCP‑трафик. Кроме того, в отличие от полноценного VPN, где трафик можно инициировать с любой стороны, в SSH‑туннелировании существует четкое понятие «точки входа» для трафика — либо на локальной стороне, либо на удаленной стороне SSH‑сессии. Эта точка входа указывается в виде пары <адрес>:<порт> и определяет, где будет открыт сокет для принятия подключений в туннель. Также при создании туннеля задается вторая пара <адрес>:<порт> — конечный адрес назначения, к которому SSH должен подключить пакет на противоположной стороне. В SSH‑клиенте за точку входа отвечают опции ‑L (local) и ‑R (remote). Они указывают, на какой стороне туннеля открыть порт для входящих соединений: локальной или удаленной (с точки зрения инициатора сессии).
Распространенные типы атак на SSH
SSH — один из ключевых протоколов удаленного администрирования, поэтому он является привлекательной целью для атакующих. Ниже мы рассмотрели распространенные методы атак и кейсы компрометации. Методы защиты от атак мы разберем в части о мисконфигурациях и усилении безопасности SSH.
Брутфорс и словарные атаки
Эти методы взлома через SSH основаны на систематическом переборе комбинаций логинов и паролей. Атаки полностью автоматизированы и масштабируются за счет ботнетов. Схема работы массового брутфорса:
- Атакующий сканирует сеть (обычно весь IPv4) с помощью
masscanилиzmap. - Все хосты с открытым портом 22 заносятся в список целей.
- Запускается программа вроде Hydra и Medusa либо собственный скрипт.
- Инструмент делает десятки или сотни попыток входа в минуту. Для каждого хоста последовательно перебираются стандартные логины, словари паролей и сгенерированные комбинации.
- Если попытка аутентификации удается, бот автоматически выполняет полезную нагрузку: загрузку шифровальщика, майнера, бэкдора или подключение к C2.
Сегодня атакующие редко используют классический перебор паролей из‑за наличия средств защиты вроде Fail2Ban и предпочитают распределенные атаки:
- Злоумышленник управляет ботнетом из тысяч или десятков тысяч зараженных машин.
- Он распределяет задачи по перебору среди всех узлов.
- Каждому устройству ботнета дается не более 1–2 попыток входа на конкретный сервер за 10–15 минут.
С точки зрения сервера каждая IP делает очень мало попыток, отсутствуют всплески активности, и Fail2Ban или аналогичное средство защиты не успевают блокировать источники атак. Так ботнет имитирует естественный трафик.
Атаки на основе ранее утекших паролей (credential stuffing)
При наличии базы скомпрометированных логинов и паролей злоумышленник систематически перебирает эти комбинации, пытаясь войти на SSH‑хосты. Эта техника особенно эффективна при отсутствии MFA и наличии повторяющихся паролей. Атака часто проводится по такому механизму:
- Злоумышленник загружает огромный массив:
user@example.com : qwerty123,admin@corp.com : Summer2020!и так далее. - Генерирует логины: оставляет исходный вариант, преобразует в формат u.user, из email берет первые части имени.
- Сопоставляет их с паролями из утечки.
- Автоматически перебирает комбинации через SSH.
Сервисные учетные записи могут иметь повторяющиеся пароли, даже если используются в разных системах. Это позволяет использовать в атаках ранее утекшие секреты.
Атаки через скомпрометированные ключи SSH
Злоумышленник может получить доступ, если:
- приватный ключ утек через GitHub, Docker‑образ, облачное хранилище или лог;
- ключи не защищены паролем;
- используется слабый алгоритм (DSA, RSA менее 2048 бит);
- не включена ротация и ограничение по хостам (
from= в authorized_keys).
MITM‑атаки и подмена сервера
Несмотря на криптографическую устойчивость SSH, атаки типа man‑in‑the‑middle возможны при неправильной конфигурации или в ненадежных сетях. Один из способов атакующих — подмена публичного ключа сервера:
- SSH полагается на модель TOFU (trust on first use).
- При первом подключении клиент видит:
The authenticity of host ... can't be established. ED25519 key fingerprint is ...
- Если пользователь, не подумав, нажимает
yes, ключ добавляется вknown_hosts. - Злоумышленник находится в той же сети (Wi‑Fi, корпоративный сегмент).
- Использует ARP‑спуфинг или поддельный шлюз.
- Проксирует SSH‑трафик через себя.
- При использовании неподтвержденных ключей может просматривать вводимые пароли, внедрять команды, логировать сессию и менять содержимое терминала.
В таком случае злоумышленник может поднять поддельный SSH‑сервер, перехватывать соединения (ARP‑спуфинг, DHCP‑спуфинг, поддельные точки доступа), предложить свой ключ. Если пользователь не сверяет отпечаток ключа (fingerprint), он фактически доверяет атакующему. Или же атакующий может перехватить активную сессию следующим образом:
Все перечисленные атаки возможны из‑за использования слабых настроек SSH, поэтому критически важна корректная конфигурация параметров.
Основные мисконфигурации и меры по их исправлению
Чтобы усилить безопасность SSH, важно не просто усложнить доступ, а создать сбалансированную конфигурацию, где SSH остается функциональным инструментом администрирования, но при этом исключает возможности злоупотреблений и атак.
Ниже мы рассматриваем популярные ошибки в настройке SSH, а также практические меры, позволяющие значительно повысить устойчивость SSH к угрозам в корпоративных и облачных инфраструктурах.
Внешняя доступность
Принцип минимального доступа гласит, что SSH‑сервер не должен быть открыт для всех. Чем уже периметр компании, тем меньше возможностей для атаки.
Отключите SSH там, где он не нужен
Это очевидный, но часто игнорируемый шаг. Если SSH‑сервер не используется — его не должно быть. В контейнерах Kubernetes, на вспомогательных сервисах и тестовых машинах SSH часто запускается по инерции. Это лишняя точка входа, и ее проще устранить, чем защищать.
Ограничьте доступ по IP (файрвол, ACL)
Самое надежное — разрешить подключение только из доверенных сетей: корпоративного офиса, VPN или заранее известных IP‑адресов администраторов. Все остальное — блокировать. Ограничение доступа можно настроить как на внешнем файрволе, так и локально на Linux‑хосте, например, с помощью iptables:
iptables -A INPUT -p tcp --dport 22 -s/32 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP
В облачных инфраструктурах та же логика применяется через Security Groups или правила брандмауэра. Эта простая мера мгновенно отсечет 99% массовых сканеров и ботов, ежедневно «простукивающих» интернет в поисках открытого порта 22.
Используйте port knocking и Single Packet Authorization (SPA)
Если статический IP использовать невозможно, можно «спрятать» SSH за дополнительным уровнем доступа. Классический вариант — port knocking: сервер временно открывает порт 22 только после определенной последовательности «стуков» по другим портам (например, 10000 → 11000 → 12000).
Современная альтернатива — fwknop, реализующий SPA с HMAC‑подписью. Один авторизованный пакет — и порт открывается на несколько секунд. Это добавляет неудобства администраторам, но полностью исключает случайные и автоматические сканеры.
Перенесите SSH на нестандартный порт
Смена порта — не полноценная защита, однако переход с 22 на 2022 или 2222 избавит от потока примитивных ботов, пытающихся войти от имени root с паролем 123456. Против целевых атак это не поможет: умный сканер все равно найдет сервис. Поэтому нестандартный порт стоит рассматривать только как дополнительную меру маскировки, а не средство безопасности.
Некорректный механизм аутентификации
SSH предоставляет несколько механизмов аутентификации, которые могут использоваться как по отдельности, так и в комбинации, в зависимости от требований безопасности.
Аутентификация по паролю
Наиболее простой и наименее надежный способ. Пароль передается внутри зашифрованного канала, что защищает его от перехвата. Однако остаются уязвимости, связанные с подбором и фишингом. Использовать этот метод допустимо только в максимально доверенных средах или при дополнительных мерах защиты (например, ограничениях по IP и системах блокировки).
По данным BI.ZONE TDR, аутентификация по паролю является одной из самых популярных мисконфигураций.
Рекомендуется в конфигурации PasswordAuthentication no, чтобы исключить возможность брутфорса пароля.
Аутентификация по ключам
Рекомендуемый и наиболее безопасный механизм. Приватный ключ хранится на стороне клиента, а соответствующий публичный ключ — на сервере. Процесс аутентификации основан на принципе challenge—response:
- сервер отправляет уникальный криптографический вызов;
- клиент подписывает его приватным ключом;
- сервер проверяет подпись с помощью публичного ключа.
Преимущества такого подхода:
- пароль не передается и не хранится;
- невозможен перебор ключей по сети;
- поддерживается автоматизация и удобство использования (SSH‑агенты, сценарии single sign‑on).
Отключенную аутентификацию по ключам можно детектировать по строке PubkeyAuthentication no в конфигурации sshd .
Двухфакторная и многофакторная аутентификация (MFA)
SSH может быть интегрирован с дополнительными факторами аутентификации:
- одноразовые коды (TOTP);
- аппаратные ключи U2F/FIDO2;
- сертификаты;
- Kerberos‑токены.
Применение MFA значительно снижает риск несанкционированного доступа, даже если один из факторов (например, приватный ключ) будет скомпрометирован.
Таким образом, SSH обеспечивает гибкую и масштабируемую систему аутентификации, где уровень защиты можно адаптировать под конкретные требования инфраструктуры и политики безопасности.
Разрешенный вход под root
Разрешенный SSH‑доступ для пользователя root — одна из самых частых и опасных ошибок в настройке. На первый взгляд это удобно, потому что не нужно переключаться с обычного пользователя на root я и можно сразу выполнять команды от имени администратора. Но с точки зрения безопасности это открытая дверь для атакующего. Если пользователю нужны права администратора системы, безопаснее выдавать их на каждой системе отдельно, при этом отключая root‑аутентификацию в конфигурации sshd с помощью параметра PermitRootLogin no.
Рекомендуем запретить вход под учетной записью root на всех Unix‑подобных системах в инфраструктуре.
Слабая политика доступа
Тысячи ботов по всему миру непрерывно сканируют открытые порты 22 и пытаются войти, перебирая логины и пароли. Даже если пароль достаточно сложный, систематические попытки входа создают нагрузку и заполняют логи, а при слабой политике доступа могут привести к случайному успеху.
Чтобы защитить SSH от подобных атак, важно ограничить количество попыток аутентификации и блокировать подозрительные подключения. Рекомендуется установить максимальное число попыток входа не более трех (MaxAuthTries = 3). Найти проблемные хосты, на которых количество попыток не ограничено, позволяет EDR‑решение, например, BI.ZONE EDR.
Разрешенная переадресация X11
Такая ситуация создает дополнительный риск безопасности, поскольку позволяет пересылать графический интерфейс X11 с сервера на клиент. Этот механизм не рассчитан на современные требования безопасности и может использоваться для перехвата событий на клавиатуре, содержимого окон или внедрения вредоносных команд. По сути, X11‑туннель открывает обратный канал к локальной машине, что особенно опасно на серверах общего назначения и jump‑хостах.
Если пересылка графики не требуется (а в большинстве случаев она не нужна), параметр следует отключить в конфигурации sshd: X11Forwarding no.
Устаревшие алгоритмы
Один из основных аспектов защиты SSH — использование современных криптоалгоритмов. Они позволяют исключить устаревшие и уязвимые схемы шифрования, обеспечив максимально устойчивый трафик. Для начала стоит отключить старые алгоритмы обмена ключами и шифрования. В конфигурации sshd_config следует явно указать только надежные варианты:
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group14-sha256 Ciphers aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
Это исключает слабые схемы вроде diffie-hellman-group1-sha1 и cbc‑шифры, оставляя современные, безопасные и производительные алгоритмы.
Для ключей хоста целесообразно ограничить список безопасными алгоритмами, например:
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519
Если таких ключей нет, стоит их сгенерировать, в частности Ed25519 (ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key). DSA-ключи необходимо удалить — они давно признаны небезопасными.
Пользователям стоит рекомендовать ключи Ed25519 или RSA длиной не менее 2048 бит.
Отсутствие мониторинга
Мониторинг SSH позволяет своевременно выявлять подозрительные попытки входа, брутфорс‑атаки и аномальные действия пользователей. Это помогает не только обнаружить взлом или утечку доступа, но и оперативно реагировать на инциденты, сохраняя целостность инфраструктуры.
Чтобы настроить корректное логирование, необходимо для начала раскомментировать (удалить символ # перед параметром) два параметра в конфигурационном файле /etc/ssh/sshd_config:
SyslogFacility AUTH LogLevel VERBOSE
Затем добавить в /etc/login.defs строки для логирования несуществующих учетных записей и успешных входов:
LOG_UNKFAIL_ENAB yes FAILLOG_ENAB yes LOG_OK_LOGINS yes
Для применения изменений необходимо перезапустить sshd:
service sshd restart # Для UpStart systemctl restart sshd # Для Systemd rc-service sshd restart # Gentoo (OpenRC)
Выявить некорректные настройки логирования ssh также позволяет BI.ZONE EDR.
Включенная host‑based‑аутентификация
Host‑based‑аутентификация в SSH — механизм, при котором сервер доверяет клиенту на основании имени или IP‑адреса хоста, а не учетных данных пользователя. Такой подход исторически применялся в закрытых доверенных сетях, но в современных условиях считается небезопасным.
Основная проблема в том, что доверие переносится с субъекта доступа на инфраструктуру. IP‑адреса и DNS‑имена могут быть подделаны, а скомпрометированный доверенный хост позволяет атакующему автоматически получать доступ к другим системам без ввода пароля или подтверждения владения ключом. Это значительно упрощает горизонтальное распространение атак внутри сети и противоречит принципам нулевого доверия (zero trust) и персонализированной аутентификации.
По этой причине не рекомендуется использовать host‑based‑аутентификацию. Безопасный подход — ее отключение (HostbasedAuthentication no) и применение аутентификации с использованием ключей, сертификатов и многофакторных методов доступа.
Включенная rhosts‑аутентификация
Этот параметр позволяет SSH использовать старый механизм доверия через rhosts‑файлы. Сервер доверяет пользователям на основании наличия их имени в этих файлах, а не проверяет пароль. Такой подход небезопасен, так как любой, кто имеет доступ к доверенному хосту, может подключиться без аутентификации. Рекомендуется игнорировать rhosts‑файлы, установив IgnoreRhosts yes.
Разрешенные пустые пароли
Если в SSH включена возможность входа с пустым паролем, любой пользователь может получить доступ к учетной записи без ввода пароля. Это прямое нарушение принципа аутентификации и серьезный риск безопасности. Правильная настройка — запрет любых пустых паролей через PermitEmptyPasswords no.
Один SSH‑ключ на разных хостах или УЗ
Когда один и тот же публичный SSH‑ключ привязан к нескольким УЗ или разным серверам, компрометация ключа на одном хосте автоматически открывает доступ к другим системам. Это увеличивает риск распространения атаки внутри инфраструктуры. С помощью BI.ZONE EDR можно выявить все хосты в инфраструктуре, на которых существуют разные пользователи с одинаковым SSH‑ключом.
Заключение
Харденинг SSH остается одной из ключевых задач при защите серверной инфраструктуры. Именно этот протокол чаще всего используется для административного доступа и становится первичной целью атак. Небезопасные параметры конфигурации, устаревшие механизмы аутентификации и слабые политики управления ключами существенно повышают риск компрометации системы и упрощают развитие атаки внутри сети.
На примере BI.ZONE EDR мы показали, как автоматизировать контроль состояния SSH‑конфигураций, выявлять небезопасные параметры, отслеживать аномальные попытки аутентификации и фиксировать нарушения политик доступа в реальном времени. Это обеспечивает не только соответствие требованиям по харденингу, но и постоянный мониторинг фактической безопасности, что особенно важно в динамичных инфраструктурах.
Корректная настройка SSH в связке со средствами поведенческого мониторинга и корреляции событий снижает поверхность атаки, повышает устойчивость к компрометации и обеспечивает контролируемый доступ к критически важным системам.
Мы подготовили Ansible‑плейбук, который поможет настроить SSH на Linux‑хостах согласно рекомендациям из этой статьи (однако в инструкции закомментированы строки, отключающие аутентификацию по паролю).