Перейти к основному содержимому

2.08. Шифрование и SSH

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ
Всем

Шифрование и SSH​

Что такое SSH​

SSH — это протокол безопасного удалённого доступа к компьютерным системам.

Он обеспечивает шифрованное соединение между клиентом и сервером, позволяя пользователям выполнять команды, передавать файлы и управлять ресурсами через ненадёжные сети, такие как интернет. Протокол SSH заменил устаревшие и незащищённые методы вроде Telnet и rlogin, которые передавали данные, включая пароли, в открытом виде.

Основная цель SSH — создание доверенного канала связи, защищённого от прослушивания, подмены и атак типа «человек посередине» (Man in the Middle, MITM).

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

SSH работает на прикладном уровне модели OSI и использует порт 22 по умолчанию. Протокол не зависит от операционной системы и реализован во всех основных платформах: Linux, macOS, Windows, BSD и даже встроенных устройствах.

Зашифрованное соединение​

SSH создаёт зашифрованное соединение между двумя узлами — клиентом и сервером. Это соединение защищает все передаваемые данные от прослушивания, подмены и анализа трафика. Шифрование применяется ко всему содержимому сессии: командам, ответам, файлам, графическим данным и даже метаданным.

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

Зашифрованное соединение обеспечивает три свойства:

  • Конфиденциальность: данные недоступны третьим лицам.
  • Целостность: любое изменение трафика обнаруживается.
  • Аутентичность: клиент точно знает, с каким сервером он соединяется, и наоборот.

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

Удалённое управление​

SSH позволяет выполнять команды на удалённой машине так, будто пользователь работает непосредственно за её терминалом. Это называется удалённым управлением. Оно реализуется через логический канал «сессия», который создаётся после успешной аутентификации.

При подключении клиент запрашивает у сервера запуск оболочки (например, bash или zsh). Сервер создаёт процесс оболочки и связывает его стандартные потоки (stdin, stdout, stderr) с SSH-каналом. Всё, что пользователь вводит в терминал, отправляется на сервер, а всё, что сервер выводит, отображается у клиента.

Пример подключения:

ssh user@192.168.1.10

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

SSH также поддерживает выполнение одной команды без запуска оболочки:

ssh user@host "systemctl status nginx"

Этот режим часто используется в скриптах автоматизации.

Передача файлов​

SSH предоставляет два основных механизма передачи файлов: SCP и SFTP.

SCP (Secure Copy) — это упрощённый протокол, основанный на старой утилите rcp. Он использует тот же зашифрованный канал, что и обычная SSH-сессия, и не требует дополнительной аутентификации. Команда выглядит так:

scp local_file.txt user@remote:/home/user/

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

SFTP (SSH File Transfer Protocol) — это полноценный протокол передачи файлов, инкапсулированный в SSH. Он предоставляет интерактивную сессию с командами вроде ls, get, put, mkdir, rm. Пример:

sftp user@remote
sftp> get report.pdf
sftp> put image.jpg
sftp> quit

SFTP поддерживается большинством графических клиентов и является предпочтительным выбором для регулярной работы с файлами.

Оба метода используют шифрование SSH и не требуют открытия дополнительных портов.

Как работает шифрование трафика​

Шифрование трафика в SSH состоит из нескольких этапов.

На первом этапе клиент и сервер договариваются о наборе алгоритмов: для обмена ключами (KEX), шифрования (cipher), проверки целостности (MAC) и сжатия. Например, они могут выбрать:

  • KEX: curve25519-sha256
  • Cipher: chacha20-poly1305@openssh.com
  • MAC: не требуется (встроено в cipher)
  • Compression: none

Затем выполняется обмен ключами по алгоритму Диффи—Хеллмана или его эллиптической версии. Каждая сторона генерирует временные ключи, обменивается публичными частями и вычисляет общий секрет. Из этого секрета с помощью хеш-функций выводятся несколько сессионных ключей: для шифрования клиент→сервер, сервер→клиент, для MAC и т.д.

После этого весь трафик разбивается на пакеты фиксированного формата. Каждый пакет содержит:

  • длину данных,
  • номер пакета,
  • полезную нагрузку,
  • MAC (если не используется AEAD-шифр).

Полезная нагрузка шифруется выбранным симметричным алгоритмом. При использовании современных шифров, таких как ChaCha20-Poly1305 или AES-GCM, шифрование и проверка целостности выполняются за один проход.

Такой подход обеспечивает высокую производительность и стойкость к атакам.

Туннель и туннелирование​

Туннель в контексте SSH — это зашифрованный канал, через который передаётся трафик другого протокола. Туннелирование позволяет «обернуть» незащищённый протокол (например, HTTP, SMTP, VNC) в безопасную оболочку SSH.

SSH поддерживает три типа туннелей:

  • Локальный проброс — перенаправление локального порта на удалённый хост.
  • Удалённый проброс — перенаправление удалённого порта на локальный хост.
  • Динамический туннель — SOCKS-прокси для произвольного трафика.

Туннель создаётся на уровне TCP. Когда клиент подключается к локальному порту, SSH-клиент перехватывает соединение и пересылает данные через зашифрованный канал на сервер, который затем устанавливает соединение с целевым хостом.

Пример: защита веб-интерфейса базы данных, доступного только внутри сети:

ssh -L 8080:db.internal:8080 user@gateway

Теперь обращение к http://localhost:8080 будет безопасно передано на db.internal:8080.

Проброс портов​

Проброс портов — это механизм перенаправления сетевого трафика с одного порта на другой через SSH-соединение.

Локальный проброс (-L) связывает локальный порт с удалённым адресом:

ssh -L [локальный_порт]:[целевой_хост]:[целевой_порт] user@ssh_server

Пример: ssh -L 3307:mysql.internal:3306 user@jump — теперь MySQL на mysql.internal доступен локально на порту 3307.

Удалённый проброс (-R) делает локальный сервис доступным через удалённый сервер:

ssh -R [удалённый_порт]:localhost:[локальный_порт] user@vps

Пример: ssh -R 8080:localhost:3000 user@vps — веб-сервер на локальном порту 3000 становится доступен по адресу vps:8080.

Динамический проброс (-D) создаёт SOCKS-прокси:

ssh -D 1080 user@proxy

Все приложения, настроенные на использование SOCKS5-прокси localhost:1080, будут направлять трафик через SSH-туннель.

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

SSH-клиент​

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

На Unix-подобных системах стандартным клиентом является ssh из набора OpenSSH. Пример вызова:

ssh -i ~/.ssh/id_ed25519 -p 2222 user@host

Клиент может выполнять различные задачи:

  • Запуск интерактивной оболочки.
  • Выполнение одной команды.
  • Передача файлов (через scp или sftp).
  • Создание туннелей.
  • Управление SSH-агентом.

Существуют и графические клиенты: PuTTY (Windows), Termius, MobaXterm, OpenSSH в Windows 10+. Они предоставляют удобный интерфейс для управления соединениями, ключами и сессиями.

Клиент также хранит информацию о ранее подключённых хостах в файле ~/.ssh/known_hosts, чтобы предотвратить атаки подмены сервера.

Метод шифрования​

Метод шифрования в SSH — это конкретный алгоритм, используемый для защиты данных. Он определяет, как преобразовывать открытый текст в зашифрованный и обратно.

SSH поддерживает множество методов, разделённых на категории:

  • Симметричные шифры (для передачи данных):
    aes256-gcm@openssh.com, chacha20-poly1305@openssh.com, aes128-ctr, aes256-ctr.

  • Алгоритмы обмена ключами (для установления сессионного ключа):
    curve25519-sha256, diffie-hellman-group-exchange-sha256.

  • Алгоритмы хостовой аутентификации:
    ssh-ed25519, rsa-sha2-512, ecdsa-sha2-nistp256.

  • MAC-алгоритмы (для проверки целостности, если не используется AEAD):
    hmac-sha2-256, hmac-sha2-512.

Каждый метод имеет свои характеристики: скорость, безопасность, совместимость. Современные системы предпочитают AEAD-шифры (например, ChaCha20-Poly1305), которые объединяют шифрование и аутентификацию в одном алгоритме.

Согласование методов шифрования​

Согласование методов шифрования — это процесс, в ходе которого клиент и сервер выбирают общие криптографические алгоритмы для установления соединения.

При подключении клиент отправляет список поддерживаемых алгоритмов в порядке предпочтения. Сервер отвечает своим списком. Затем стороны выбирают первый алгоритм из списка клиента, который также поддерживается сервером.

Пример согласования шифров:

  • Клиент предлагает: chacha20-poly1305@openssh.com, aes256-gcm@openssh.com, aes128-ctr.
  • Сервер поддерживает: aes128-ctr, aes256-gcm@openssh.com.
  • Выбирается: aes256-gcm@openssh.com (первый общий в списке клиента).

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

Если общих алгоритмов нет, соединение прерывается с ошибкой.

Где применяется SSH​

SSH используется повсеместно в IT-инфраструктуре:

  • Системное администрирование: удалённое управление серверами, маршрутизаторами, сетевыми устройствами.
  • DevOps и автоматизация: развёртывание приложений, запуск скриптов, управление конфигурациями через Ansible, SaltStack, Fabric.
  • Безопасная передача файлов: замена FTP, rcp и других незащищённых протоколов.
  • Git и системы контроля версий: доступ к приватным репозиториям на GitHub, GitLab, Bitbucket.
  • Туннелирование: защита веб-интерфейсов, баз данных, VNC, RDP и других сервисов.
  • Обход ограничений сети: доступ к заблокированным ресурсам через SOCKS-прокси.
  • Интеграция с CI/CD: выполнение команд на удалённых машинах в процессе сборки.
  • Удалённая разработка: редактирование кода на сервере через VS Code Remote-SSH.
  • Безопасное резервное копирование: синхронизация данных с помощью rsync поверх SSH.

SSH стал стандартом де-факто для любого взаимодействия с удалёнными Unix-системами и широко применяется даже в Windows-средах благодаря встроенной поддержке OpenSSH.

Архитектура SSH​

Транспортный уровень​

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

Процесс начинается с отправки клиентом и сервером строк идентификации, например:

SSH-2.0-OpenSSH_9.2

Эта строка указывает версию протокола (в данном случае 2.0) и имя реализации (OpenSSH версии 9.2). Современные системы используют SSH-2, так как SSH-1 содержит уязвимости и считается небезопасным.

После согласования версии стороны выполняют обмен ключами по алгоритму Диффи—Хеллмана или его эллиптическим аналогом (ECDH). В результате обе стороны получают общий секрет — сессионный ключ, который используется для симметричного шифрования всего последующего трафика.

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

  • chacha20-poly1305@openssh.com
  • aes256-gcm@openssh.com
  • aes128-ctr
  • aes256-ctr

Алгоритмы проверки целостности (MAC) могут быть:

  • hmac-sha2-256
  • hmac-sha2-512
  • umac-128@openssh.com

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

Уровень аутентификации​

После установления защищённого канала клиент должен подтвердить свою личность. SSH поддерживает несколько методов аутентификации:

  • Парольная аутентификация: пользователь вводит имя и пароль. Пароль передаётся по зашифрованному каналу, поэтому не виден перехватчикам.
  • Аутентификация по публичному ключу: клиент доказывает владение приватным ключом, соответствующим публичному ключу, зарегистрированному на сервере.
  • Аутентификация с использованием Kerberos, GSSAPI, host-based и другие, менее распространённые методы.

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

Пример генерации ключевой пары с помощью OpenSSH:

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

Эта команда создаёт ключ на основе эллиптической кривой Ed25519, которая обеспечивает высокую криптостойкость при малом размере ключа. Альтернативой является RSA:

ssh-keygen -t rsa -b 4096 -C "user@example.com"

Здесь указывается длина ключа в 4096 бит, что соответствует современным рекомендациям безопасности.

Уровень соединения​

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

  • Канал сессии: запуск интерактивной оболочки (bash, zsh и т.п.) или выполнение одной команды.
  • Канал прямого TCP-туннелирования: перенаправление трафика с локального порта на удалённый хост.
  • Канал обратного TCP-туннелирования: перенаправление трафика с удалённого порта на локальный хост.
  • Канал SFTP: передача файлов с использованием протокола SFTP (SSH File Transfer Protocol).

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

Ключевые компоненты SSH​

Клиент и сервер​

Клиент SSH — это программа, инициирующая соединение. На большинстве Unix-систем используется ssh из набора OpenSSH. Пример вызова:

ssh user@hostname

Сервер SSH — это демон, ожидающий входящих подключений. В OpenSSH он называется sshd и обычно запускается как системная служба. Конфигурация сервера находится в файле /etc/ssh/sshd_config.

Пример базовой конфигурации сервера:

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
PermitRootLogin no
PasswordAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Эта конфигурация:

  • слушает стандартный порт 22,
  • разрешает только протокол версии 2,
  • указывает пути к хостовым ключам,
  • запрещает вход под пользователем root,
  • разрешает как парольную, так и ключевую аутентификацию,
  • определяет расположение файла с авторизованными публичными ключами.

Изменения в конфигурации требуют перезапуска службы:

sudo systemctl reload sshd

Хостовые ключи​

Каждый SSH-сервер имеет одну или несколько пар ключей, называемых хостовыми. Они используются для аутентификации самого сервера перед клиентом. При первом подключении клиент сохраняет отпечаток (fingerprint) хостового ключа в файле ~/.ssh/known_hosts.

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

Отпечаток можно просмотреть вручную:

ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

Результат:

256 SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz1234567890abcdefg user@host (ED25519)

Пользовательские ключи​

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

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

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

eval $(ssh-agent)
ssh-add ~/.ssh/id_ed25519

Безопасность SSH​

Выбор алгоритмов​

Безопасность SSH напрямую зависит от выбранных криптографических алгоритмов. Слабые или устаревшие алгоритмы снижают стойкость всего соединения. Например, использование RSA с длиной ключа 1024 бит или алгоритма CBC в режиме шифрования считается небезопасным.

Рекомендуется в конфигурации явно указывать предпочтительные алгоритмы и отключать ненадёжные. Пример настройки клиента в ~/.ssh/config:

Host *
    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
    HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256

Аналогичные параметры можно задать и на стороне сервера в sshd_config.

Ограничение прав доступа​

Важно минимизировать поверхность атаки. Это достигается следующими мерами:

  • Отключение входа под пользователем root (PermitRootLogin no)
  • Ограничение списка разрешённых пользователей (AllowUsers alice bob)
  • Использование групп для управления доступом (AllowGroups ssh-users)
  • Отключение парольной аутентификации при использовании ключей (PasswordAuthentication no)
  • Ограничение функциональности через ForceCommand или Match блоки

Пример ограничения для конкретного пользователя:

Match User deploy
    PasswordAuthentication no
    PubkeyAuthentication yes
    AllowTcpForwarding no
    X11Forwarding no
    PermitTTY no
    ForceCommand /usr/local/bin/deploy-script.sh

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

Защита от перебора​

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

  • Ограничение числа попыток входа
  • Использование fail2ban или подобных инструментов для временной блокировки IP-адресов
  • Перенос SSH на нестандартный порт (security through obscurity, но иногда эффективно)
  • Двухфакторная аутентификация (например, через Google Authenticator)

Пример настройки fail2ban для SSH:

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 600

После трёх неудачных попыток IP-адрес блокируется на 10 минут.

Протокол SSH: версии и совместимость​

SSH-1 и SSH-2​

SSH существует в двух основных версиях: SSH-1 и SSH-2. Эти версии несовместимы на уровне протокола. SSH-1 был разработан Тату Йлоненом в 1995 году как ответ на перехват паролей в университетской сети. Он обеспечил первое поколение зашифрованных удалённых соединений, но содержал архитектурные недостатки.

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

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

Современные реализации, такие как OpenSSH, по умолчанию используют только SSH-2. Поддержка SSH-1 была удалена из OpenSSH начиная с версии 7.6 (2017 год). Использование SSH-1 считается небезопасным и не рекомендуется в любых средах.

Совместимость реализаций​

Существует несколько реализаций SSH:

  • OpenSSH — стандарт де-факто в Unix-подобных системах, включая Linux и macOS.
  • Dropbear — лёгковесная реализация для встраиваемых систем.
  • PuTTY — популярный клиент для Windows с собственной библиотекой (libssh).
  • libssh и libssh2 — библиотеки для интеграции SSH в приложения.
  • Windows OpenSSH — официальный клиент и сервер от Microsoft, доступный с Windows 10 и Windows Server 2019.

Несмотря на различия в кодовой базе, все реализации следуют спецификациям RFC 4251–4256, что обеспечивает межплатформенную совместимость. Например, клиент PuTTY может подключаться к серверу OpenSSH без дополнительной настройки, если используются поддерживаемые алгоритмы.

Однако некоторые особенности могут вызывать проблемы. Например, PuTTY использует собственный формат ключей (.ppk), тогда как OpenSSH использует стандартные PEM или новую структуру openssh-key-v1. Для совместимости требуется конвертация ключей с помощью утилиты puttygen.

Аутентификация по публичному ключу​

Принцип работы​

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

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

Форматы ключей​

OpenSSH поддерживает несколько типов ключей:

  • RSA — самый старый и универсальный. Рекомендуется использовать длину не менее 3072 бит.
  • DSA — устаревший, ограничен 1024 битами, отключён по умолчанию в новых версиях OpenSSH.
  • ECDSA — основан на эллиптических кривых. Поддерживает кривые nistp256, nistp384, nistp521.
  • Ed25519 — современный алгоритм на основе кривой Ed25519. Обеспечивает высокую скорость и безопасность при коротком ключе (256 бит). Рекомендуется как основной выбор.

Пример содержимого публичного ключа Ed25519:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGxVrFQjJHmKqVdY1XzZ1aBcDfEgHiJkLmNoPqRsTuVw user@example.com

Первое поле — тип ключа, второе — base64-кодированное тело ключа, третье — комментарий (необязательный).

Защита ключей​

Приватный ключ должен быть недоступен для других пользователей. В Unix-системах права доступа должны быть установлены в 600:

chmod 600 ~/.ssh/id_ed25519

Если права слишком открыты, OpenSSH откажется использовать ключ, чтобы предотвратить утечку.

Дополнительный уровень защиты — passphrase. Она шифрует сам файл ключа. Без неё даже при компрометации файла злоумышленник не сможет использовать ключ. Passphrase вводится один раз при добавлении ключа в ssh-agent.

Продвинутые функции SSH​

Мультиплексирование соединений​

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

Настройка в ~/.ssh/config:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h:%p
    ControlPersist 600

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

Каталог для сокетов должен существовать:

mkdir -p ~/.ssh/sockets
chmod 700 ~/.ssh/sockets

Агент пересылки (Agent Forwarding)​

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

Включение:

ssh -A user@serverA

Или в конфиге:

Host serverA
    ForwardAgent yes

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

X11 Forwarding​

SSH может перенаправлять графические приложения с удалённого сервера на локальную машину. Это полезно при работе с GUI-программами в Linux.

Включение:

ssh -X user@hostname

Сервер должен иметь установленный X11 и разрешать перенаправление (X11Forwarding yes в sshd_config). Клиент должен запускать X-сервер (например, Xming на Windows или встроенный X11 на macOS/Linux).

Конфигурация клиента​

Файл ~/.ssh/config позволяет настраивать поведение SSH для разных хостов. Это упрощает подключение и повышает безопасность.

Пример комплексной конфигурации:

# Глобальные настройки
Host *
    IdentitiesOnly yes
    PreferredAuthentications publickey
    ServerAliveInterval 60
    ServerAliveCountMax 3
    ConnectTimeout 10
    StrictHostKeyChecking ask

# Рабочий сервер
Host work-server
    HostName 192.168.10.50
    User ttagirov
    IdentityFile ~/.ssh/id_ed25519_work
    Port 2222
    ForwardAgent no
    LocalForward 8080 localhost:80

# Личный VPS
Host vps
    HostName vps.example.com
    User admin
    IdentityFile ~/.ssh/id_ed25519_personal
    ProxyJump bastion
    Compression yes

# Бастеон-хост
Host bastion
    HostName jump.example.com
    User jumpuser
    IdentityFile ~/.ssh/id_rsa_bastion

Объяснение параметров:

  • IdentitiesOnly yes — использовать только указанные ключи, игнорируя остальные в агенте.
  • PreferredAuthentications — явно задаёт порядок методов аутентификации.
  • ServerAliveInterval — отправлять keepalive-пакеты каждые 60 секунд.
  • StrictHostKeyChecking ask — всегда спрашивать при неизвестном хосте.
  • LocalForward — проброс локального порта на удалённый хост.
  • ProxyJump — подключение через промежуточный хост (аналог -J в командной строке).

Такая конфигурация делает работу с несколькими серверами удобной и предсказуемой.

Протоколы передачи файлов поверх SSH​

SCP (Secure Copy Protocol)​

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

Команда для копирования файла с локальной машины на удалённый сервер:

scp /path/to/local/file.txt user@remote:/path/to/remote/

Для копирования с удалённого сервера на локальную машину:

scp user@remote:/path/to/remote/file.txt /local/destination/

SCP работает в режиме «push» или «pull», но не поддерживает расширенные функции, такие как возобновление прерванной передачи или синхронизация каталогов. Его простота делает его удобным для разовых операций, но в современных системах всё чаще рекомендуется использовать SFTP или rsync поверх SSH.

SFTP (SSH File Transfer Protocol)​

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

Запуск SFTP-сессии:

sftp user@hostname

После подключения доступны команды, похожие на FTP:

sftp> ls
sftp> cd documents
sftp> get report.pdf
sftp> put image.jpg
sftp> mkdir backups
sftp> rm old.log
sftp> quit

SFTP поддерживается большинством графических клиентов (FileZilla, WinSCP, Cyberduck), что делает его популярным выбором для пользователей, которым нужен графический интерфейс для передачи файлов.

Важно: SFTP не является расширением FTP через SSH. Это самостоятельный бинарный протокол, инкапсулированный в SSH-канал. Он использует один порт (обычно 22) и не требует открытия дополнительных соединений, в отличие от активного FTP.

Туннелирование и проброс портов​

SSH позволяет создавать зашифрованные туннели для перенаправления сетевого трафика. Это особенно полезно для защиты незашифрованных протоколов (например, HTTP, SMTP) или для обхода ограничений сети.

Локальный проброс (Local Port Forwarding)​

Локальный проброс направляет трафик с локального порта на удалённый хост через SSH-сервер.

Пример: подключение к веб-интерфейсу базы данных, запущенной на db.internal:8080, через публичный сервер jump.example.com:

ssh -L 9000:db.internal:8080 user@jump.example.com

Теперь обращение к http://localhost:9000 на локальной машине будет перенаправлено через SSH-туннель к db.internal:8080.

Это используется для безопасного доступа к внутренним сервисам без их публикации в интернете.

Удалённый проброс (Remote Port Forwarding)​

Удалённый проброс позволяет сделать локальный сервис доступным через удалённый сервер.

Пример: запустить веб-сервер на локальной машине и временно опубликовать его через VPS:

ssh -R 8080:localhost:3000 user@vps.example.com

Теперь любой, кто обратится к http://vps.example.com:8080, получит контент с локального порта 3000.

По умолчанию удалённый проброс слушает только на loopback-интерфейсе (127.0.0.1) удалённого хоста. Чтобы сделать порт доступным извне, требуется включить GatewayPorts yes в конфигурации сервера.

Динамическое туннелирование (SOCKS-прокси)​

SSH может создать динамический SOCKS-прокси, который перенаправляет произвольный трафик через зашифрованный канал.

Запуск прокси на локальном порту 1080:

ssh -D 1080 user@proxy-server

После этого можно настроить браузер или систему на использование SOCKS5-прокси localhost:1080. Весь трафик будет проходить через proxy-server, что обеспечивает анонимность и защиту в ненадёжных сетях (например, в общественном Wi-Fi).

Аудит и логирование SSH​

Сервер SSH записывает события в системный журнал. Уровень детализации задаётся параметром LogLevel в sshd_config. Возможные значения:

  • QUIET — минимальное логирование
  • FATAL, ERROR — только ошибки
  • INFO — стандартный уровень: подключения, аутентификация
  • VERBOSE — подробная информация, включая отпечатки ключей
  • DEBUG, DEBUG1, DEBUG2, DEBUG3 — для диагностики проблем

Пример записи при успешном входе:

Accepted publickey for alice from 192.168.1.100 port 54321 ssh2: ED25519 SHA256:AbCdEf...

При неудачной попытке:

Failed password for root from 203.0.113.5 port 22345 ssh2

Логи обычно находятся в /var/log/auth.log (Debian/Ubuntu) или /var/log/secure (RHEL/CentOS). Эти данные используются для мониторинга, анализа безопасности и интеграции с системами типа SIEM.

Для повышения прозрачности можно включить принудительную запись всех сессий с помощью auditd или сторонних решений вроде shellrecorder, но это требует дополнительной настройки и хранения данных.

Совместимость с другими протоколами и системами​

SSH интегрируется с множеством инструментов и систем:

  • Git использует SSH для аутентифицированного доступа к репозиториям (git@github.com:user/repo.git).
  • Ansible, SaltStack, Fabric и другие системы автоматизации полагаются на SSH для выполнения команд на удалённых узлах.
  • Kubernetes может использовать kubectl exec через SSH-подобные механизмы, хотя напрямую не зависит от SSH.
  • Rsync часто запускается поверх SSH для безопасной синхронизации файлов: 
    rsync -avz -e ssh /local/dir/ user@remote:/remote/dir/

Эта универсальность делает SSH фундаментальным компонентом современной инфраструктуры.

Безопасные практики использования SSH​

Регулярное обновление​

OpenSSH регулярно выпускает обновления, исправляющие уязвимости. Например, уязвимости типа CVE-2023-38408 (RCE через агент пересылки) показывают важность своевременного обновления.

Проверка версии:

ssh -V
# OpenSSH_9.2p1, OpenSSL 3.0.8 7 Feb 2023

Рекомендуется использовать последние стабильные версии из официальных репозиториев или собирать из исходников при необходимости.

Минимизация прав​

Принцип наименьших привилегий применяется и к SSH. Пользователи должны иметь только те права, которые необходимы для выполнения задач. Использование Match-блоков в sshd_config позволяет гибко настраивать политики для разных групп.

Отключение ненужных функций​

Если не используется X11 forwarding, TCP forwarding или агент пересылки, их следует отключить глобально:

AllowTcpForwarding no
X11Forwarding no
AllowAgentForwarding no

Это снижает векторы атаки.

Мониторинг и отзыв ключей​

Ключи должны периодически проверяться и отзываться при увольнении сотрудников, потере устройств или подозрении на компрометацию. Автоматизированные системы управления ключами (например, HashiCorp Vault, Teleport) помогают масштабировать этот процесс.

Взаимодействие с другими системами аутентификации​

SSH может интегрироваться с централизованными системами управления идентификацией, такими как LDAP, Active Directory или Kerberos. Это позволяет использовать единые учётные данные для входа на множество серверов без необходимости размещать ключи вручную на каждом из них.

Аутентификация через Kerberos​

Kerberos — это протокол сетевой аутентификации, основанный на билетах (tickets). При использовании с SSH клиент получает билет от KDC (Key Distribution Center) и предъявляет его серверу. Это исключает передачу паролей и упрощает управление доступом в крупных организациях.

Для включения Kerberos в OpenSSH требуется:

  • На стороне клиента: GSSAPIAuthentication yes
  • На стороне сервера: GSSAPIAuthentication yes, GSSAPICleanupCredentials yes

Пример подключения:

kinit user@REALM
ssh -K user@host

Флаг -K включает пересылку билетов, что позволяет использовать аутентификацию Kerberos и на промежуточных хостах.

Интеграция с PAM​

OpenSSH использует PAM (Pluggable Authentication Modules) для гибкой настройки процесса аутентификации. Через PAM можно подключить двухфакторную аутентификацию, ограничения по времени, географии или другим критериям.

Пример конфигурации /etc/pam.d/sshd для Google Authenticator:

auth required pam_google_authenticator.so
auth include common-auth
account include common-account
session include common-session

При этом в sshd_config должно быть включено:

ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

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

Безопасность ключей и управление ими​

Форматы хранения ключей​

OpenSSH поддерживает несколько форматов хранения приватных ключей:

  • PEM (традиционный) — текстовый файл, начинающийся с -----BEGIN RSA PRIVATE KEY-----. Уязвим к брутфорсу при слабой passphrase.
  • OpenSSH новый формат — начинается с -----BEGIN OPENSSH PRIVATE KEY-----. Использует более стойкое шифрование (bcrypt + AES) и является рекомендуемым.

Ключи можно конвертировать между форматами с помощью ssh-keygen -p -f keyfile.

Защита от утечки​

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

Если ключ скомпрометирован, его необходимо удалить из authorized_keys на всех серверах и сгенерировать новую пару.

Использование аппаратных ключей​

Ключи могут храниться на аппаратных устройствах, таких как YubiKey, Trezor или смарт-карты. Это обеспечивает физическую защиту: даже при заражении системы вредоносным ПО приватный ключ остаётся недоступным.

OpenSSH поддерживает FIDO/U2F и FIDO2 через типы ключей ecdsa-sk и ed25519-sk:

ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk

При подключении система запросит физическое нажатие кнопки на устройстве, что добавляет фактор «владение».

Автоматизация и скриптование​

SSH часто используется в автоматизированных сценариях: развёртывание приложений, резервное копирование, мониторинг. Для этого требуется бесшумная (non-interactive) аутентификация.

Рекомендации:

  • Использовать отдельный ключ без passphrase для автоматизации.
  • Ограничивать права этого ключа через authorized_keys:
command="/usr/local/bin/backup.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAA...

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

Пример резервного копирования:

#!/bin/bash
rsync -avz -e "ssh -i ~/.ssh/id_backup" /data/ backup@storage:/backups/$(date +%Y%m%d)/

Здесь используется специальный ключ id_backup, который авторизован только для выполнения операций rsync.

Диагностика и устранение неполадок​

При проблемах с подключением полезно включить подробное логирование:

ssh -v user@host          # базовая диагностика
ssh -vv user@host         # расширенная
ssh -vvv user@host        # максимальная детализация

Типичные проблемы:

  • Host key mismatch — изменился хостовый ключ. Решение: удалить запись из ~/.ssh/known_hosts.
  • Permission denied (publickey) — сервер не принимает ключ. Причины: неправильные права на ~/.ssh (должны быть 700), на authorized_keys (600), или ключ не добавлен.
  • Connection refused — демон sshd не запущен или слушает другой порт.
  • Too many authentication failures — клиент пытается использовать слишком много ключей. Решение: явно указать нужный ключ через -i или IdentitiesOnly yes.

Проверка конфигурации сервера:

sudo sshd -t

Эта команда проверяет синтаксис sshd_config без перезапуска службы.