OpenSSH: руководство по установке, настройке и обеспечении безопасности

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

Пакет OpenSSH представляет собой полный набор инструментов, необходимых для работы с удаленной инфраструктурой :  

• ssh: основной инструмент для удаленного входа в систему.
• scp: предназначен для безопасного копирования файлов между хостами.
• sftp: предоставляет функциональность защищенного протокола передачи файлов, аналогичного FTP, но с шифрованием.

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

Помимо шифрования, OpenSSH предлагает широкий спектр функций, которые расширяют его применимость далеко за рамки простого удаленного входа. К ним относятся :  

• X11 Forwarding: позволяет безопасно передавать трафик X Window System, обеспечивая работу с графическим интерфейсом удаленного сервера.
• Port Forwarding: создает зашифрованные туннели для небезопасных протоколов, таких как POP3, что позволяет использовать их в защищенной среде.
• Agent Forwarding: упрощает аутентификацию на нескольких удаленных серверах, используя один локальный ключ.

В условиях непрерывной эволюции киберугроз, таких как недавние уязвимости, выявленные в OpenSSH (например, CVE-2025-26465 и CVE-2025-26466), крайне важно поддерживать программное обеспечение в актуальном состоянии. В этой статье представить комплексный подход к установке, настройке и обеспечению безопасности OpenSSH с учетом современных практик, что позволит выстроить надежную и устойчивую к взлому инфраструктуру.  

Установка и управление службой OpenSSH

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

Подготовка и установка OpenSSH Server

Установка OpenSSH Server осуществляется через стандартные пакетные менеджеры дистрибутивов, что позволяет избежать привязки к конкретной операционной системе. Ниже представлены команды для наиболее распространенных семейств Linux:

Для дистрибутивов на базе Debian/Ubuntu (apt):

sudo apt update
sudo apt install openssh-server

В этом случае пакетный менеджер автоматически установит все необходимые зависимости и настроит службу sshd.  

Для дистрибутивов на базе RHEL/CentOS/Fedora (dnf):

sudo dnf install openssh-server

В CentOS 7 для установки может использоваться команда yum.  

Для дистрибутивов на базе Arch Linux (pacman):

sudo pacman -S openssh

Перед установкой также рекомендуется обновить систему: sudo pacman -Syu.  

Управление службой SSH

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

Для запуска службы вручную:

sudo systemctl start sshd

Для включения автозагрузки и немедленного запуска:

sudo systemctl enable --now sshd

Ключ --now запускает службу сразу после включения автозагрузки, что является удобной и эффективной практикой.  

Для проверки статуса службы:

sudo systemctl status sshd

Вывод команды должен содержать строку Active: active (running), что подтверждает успешную работу службы.  

Следует отметить, что на некоторых системах служба может быть названа ssh.service вместо sshd.service.  

Переход на безопасную аутентификацию по ключам

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

Создание и управление SSH-ключами

Процесс создания ключевой пары осуществляется с помощью утилиты ssh-keygen, которая является неотъемлемой частью пакета OpenSSH.  

Выбор типа ключа: Ed25519 против RSA

На сегодняшний день существует несколько типов ключей, но два из них заслуживают особого внимания: Ed25519 и RSA. Хотя RSA долгое время был стандартом, современные рекомендации отдают предпочтение Ed25519 из-за его превосходства в нескольких ключевых областях.  

• Ed25519: Этот тип ключей использует криптографию на эллиптических кривых (ECC), которая обеспечивает очень высокий уровень безопасности при относительно небольшом размере ключа. Ключи Ed25519 устойчивы к отказам генератора псевдослучайных чисел (PRNG), что делает их более надежным выбором для защиты от потенциальных уязвимостей. Кроме того, они значительно быстрее в процессе генерации и проверки подписи по сравнению с  RSA, что приводит к более быстрому входу в систему. Размер публичного ключа  Ed25519 составляет всего 68 символов, что делает его более компактным и удобным для управления.
• RSA: Хотя RSA по-прежнему широко поддерживается, для обеспечения надежной защиты требуется использовать ключи размером не менее 2048 бит, а еще лучше — 4096 бит. В OpenSSH 8.8 была прекращена поддержка старых и криптографически слабых подписей  ssh-rsa (на основе SHA-1), что делает его использование менее предпочтительным.

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

Для генерации ключа Ed25519 используется следующая команда:

ssh-keygen -t ed25519 -C "your_email@example.com"

Опция -t ed25519 указывает тип ключа, а -C добавляет комментарий, который помогает идентифицировать ключ.  

Безопасное хранение и управление ключами

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

• Приватный ключ — это самый важный элемент. Он должен храниться в строгой секретности. Для этого необходимо установить правильные права доступа, чтобы только владелец мог читать и записывать его: chmod 600 ~/.ssh/id_ed25519.  
• Публичный ключ можно безопасно передавать на серверы. На удаленном сервере он добавляется в файл ~/.ssh/authorized_keys, который также должен иметь строгие права доступа (chmod 600). Каталог ~/.ssh должен иметь права 700.  

Также рекомендуется защитить приватный ключ надежной фразой-паролем. Это дополнительный уровень защиты, который не позволит использовать ключ, даже если он будет скомпрометирован.  

Удобство и безопасность с ssh-agent

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

Agent Forwarding и риски безопасности

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

При экспертном подходе к безопасности не просто запрещается использование этой функции, а анализируются альтернативы. Вместо того, чтобы полагаться на agent forwarding, современным и более безопасным решением является использование ProxyJump. Доступный с OpenSSH 7.3, ProxyJump позволяет клиенту устанавливать прямое сквозное соединение с конечным сервером через промежуточный, не передавая туда ssh-agent. Это снижает поверхность атаки, так как ключ никогда не «попадает» на промежуточный хост.  

Укрепление защиты SSH-демона (sshd_config)

SSH-демон (sshd) является критически важной службой, часто подвергающейся автоматизированным атакам. Файл конфигурации /etc/ssh/sshd_config является первой линией обороны и позволяет значительно укрепить безопасность сервера.  

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

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Ключевые меры безопасности

Отключение парольной аутентификации: Парольная аутентификация должна быть отключена в пользу ключевой для предотвращения брутфорс-атак. Для этого в  sshd_config устанавливаются следующие параметры:

PasswordAuthentication no
ChallengeResponseAuthentication no

Запрет входа под root: Учетная запись root является основной целью для злоумышленников из-за своих неограниченных привилегий. Запрет прямого входа под root (PermitRootLogin no) вынуждает пользователей сначала входить под обычным аккаунтом, а затем повышать привилегии с помощью sudo. Такой подход обеспечивает более четкий аудит и снижает риски.  

PermitRootLogin no

Смена стандартного порта: Стандартный порт SSH (22) является наиболее частой мишенью для автоматизированных сканирований. Изменение его на нестандартный (например, 2222) снижает «шум» от таких атак, хотя и не является полноценной мерой безопасности.  

Port 2222

Важность опции UsePAM yes

На первый взгляд может показаться, что если парольная аутентификация отключена и используется только ключевая, опцию UsePAM можно установить в no. Однако это заблуждение. PAM (Pluggable Authentication Modules) — это не просто механизм проверки пароля. Это мощный, модульный фреймворк, который интегрируется с SSH-демоном и выполняет множество других критически важных функций, включая :  

• Управление сессиями: PAM отвечает за создание и управление сессиями пользователя, включая выделение системных ресурсов (CPU, память), настройку переменных окружения и запуск скриптов при входе.
• Логирование: PAM обеспечивает детальное логирование событий аутентификации, что важно для аудита и мониторинга.
• Интеграция с MFA: PAM позволяет легко интегрировать SSH с двухфакторной аутентификацией, например, с Google Authenticator.  

Таким образом, отключение UsePAM значительно снижает общую безопасность и управляемость системы, даже если аутентификация по паролю запрещена. Правильная практика — оставлять UsePAM yes и при необходимости отключать парольную аутентификацию на уровне самого PAM, что обеспечивает комплексный подход к защите.

Современные криптографические настройки

Для предотвращения атак, направленных на принудительное использование слабых алгоритмов (downgrade attacks), рекомендуется явно указывать современные и надежные криптографические параметры в sshd_config.  

• Протокол: Использовать только вторую версию протокола SSH.  
• Алгоритмы обмена ключами (KexAlgorithms):

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

• Шифры (Ciphers):

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

• Коды аутентификации сообщений (MACs):

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Устаревшие алгоритмы, такие как diffie-hellman-group1-sha1 и ssh-dss, считаются слабыми и отключены по умолчанию в последних версиях OpenSSH.  

Дополнительные параметры защиты

• LoginGraceTime 30: Ограничивает время, отведенное на аутентификацию, что помогает смягчить DoS-атаки, основанные на заполнении сервера медленными запросами.  
• MaxAuthTries 3: Ограничивает количество попыток аутентификации до трех, что противодействует брутфорс-атакам.  
• ClientAliveInterval 300: Отключает неактивные сессии через 300 секунд (5 минут).  

Также важно помнить, что опция UsePrivilegeSeparation устарела и была удалена в OpenSSH 7.5, поэтому ее не следует использовать в современных конфигурациях.  

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

sudo systemctl restart sshd

Конфигурация брандмауэра для OpenSSH

Даже самая надежная конфигурация OpenSSH будет бессмысленной, если порт, на котором он работает, не защищен брандмауэром. Брандмауэр является важнейшим компонентом безопасности, так как он контролирует входящий и исходящий трафик.

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

Настройка UFW (Uncomplicated Firewall)

UFW — это простой и интуитивно понятный интерфейс для управления iptables, который является стандартным брандмауэром в дистрибутивах на базе Debian и Ubuntu.  

Разрешение трафика по имени службы:

sudo ufw allow "OpenSSH"

Эта команда автоматически разрешает входящие соединения на стандартный порт SSH (22).  

Разрешение трафика по номеру порта:

sudo ufw allow 22/tcp

Эта команда также разрешает трафик на порт 22. Если вы сменили стандартный порт, укажите новый номер. Например,  sudo ufw allow 2222/tcp

Разрешение доступа с определенного IP-адреса или подсети:

sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp

Это позволяет SSH-трафик только с указанной подсети, что значительно снижает поверхность атаки.  

Настройка Firewalld

Firewalld — это динамический брандмауэр, стандартный для RHEL, CentOS и Fedora, который использует nftables.  

Разрешение трафика по имени службы:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Команда --permanent делает изменения постоянными, а --reload применяет их без перезапуска всей службы.  

Разрешение трафика по номеру порта:

sudo firewall-cmd --permanent --add-port=22/tcp
sudo firewall-cmd --reload

Если стандартный порт был изменен, необходимо указать новый номер порта, так как предопределенный сервис ssh распознает только порт 22.  

Настройка iptables

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

Правила для разрешения входящего SSH-трафика:

sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Эти правила позволяют устанавливать новые SSH-соединения на порт 22 и поддерживать уже установленные.  

Сохранение правил:

• Для Debian/Ubuntu: Установить пакет iptables-persistent и сохранить правила: sudo netfilter-persistent save.  
• Для CentOS 7: Установить iptables-services и сохранить правила: sudo service iptables save.  

Актуальные угрозы и непрерывный мониторинг

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

Последние уязвимости OpenSSH

Недавние отчеты по безопасности выявили две критически важные уязвимости, которые подчеркивают важность своевременного обновления OpenSSH :  

• CVE-2025-26465: Эта уязвимость затрагивает клиент OpenSSH и позволяет провести атаку «человек посередине» (man-in-the-middle). Злоумышленник может вынудить клиента принять его ключ вместо легитимного ключа сервера, что приводит к перехвату сессии. Уязвимости подвержены версии OpenSSH с 6.8p1 по 9.9p1.  
• CVE-2025-26466: Это уязвимость типа «отказ в обслуживании» (Denial-of-Service), которая может быть использована злоумышленником для истощения ресурсов сервера (памяти и CPU) еще на этапе преаутентификации. Повторная эксплуатация этой уязвимости может привести к полной блокировке доступа для администраторов. Уязвимости подвержены версии OpenSSH с 9.5p1 по 9.9p1.  

Обе уязвимости были устранены в версии OpenSSH 9.9p2, что делает ее установку первоочередной задачей для всех системных администраторов.  

Цикл «Патчинг-Конфигурация-Мониторинг»

При анализе таких уязвимостей, как CVE-2025-26466, становится ясно, что безопасность не может быть обеспечена только путем установки последних обновлений. Эта DoS-атака могла быть смягчена проактивными мерами, такими как настройка параметров LoginGraceTime, MaxStartups и PerSourcePenalties в sshd_config. Такой подход показывает, что безопасность — это непрерывный цикл, состоящий из трех взаимосвязанных этапов:  

• Патчинг: Регулярное обновление программного обеспечения — это базовая гигиена, которая устраняет известные уязвимости.  
• Конфигурация (hardening): Проактивная настройка защитных механизмов, которая может смягчить последствия еще не обнаруженных атак, делая систему более устойчивой к будущим угрозам.  
• Мониторинг: Настройка детального логирования (LogLevel VERBOSE в sshd_config) и регулярный просмотр журналов (/var/log/auth.log или /var/log/secure) для обнаружения и расследования подозрительной активности.  

Эта непрерывная петля позволяет не просто реагировать на угрозы, а опережать их, создавая по-настоящему защищенную и отказоустойчивую среду.

Управление жизненным циклом ключей

Безопасность ключей не заканчивается их генерацией. Необходимо регулярно проводить аудит файла ~/.ssh/authorized_keys на сервере, чтобы убедиться, что там не осталось ключей от бывших сотрудников или устройств, которые больше не используются. Своевременное удаление неактуальных ключей является критически важной мерой безопасности.  

Заключение: Искусство безопасного удаленного доступа

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

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

Дополнительный материал

• Атрибуты файлов в Linux
• Linux Scheduler: Автоматизация задач с Cron и Systemd Timers
• Управление процессами в Linux
• Структура каталогов Linux
• Установка и настройка Linux Terminal Server Project (LTSP)