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

Шифрование данных и протокол SSH

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Всем
Связанные темы

Пароли и хеши при передаче защищает HTTPS — см. асимметричную криптографию ниже и кратко в статье про пароли.

Модель входа и токены — в аутентификации и авторизации.

Фильтрация сетевого доступа — в фаерволах.

Открытый Wi‑Fi — в отдельной статье.

Автоматизация SSH из Python — библиотека paramiko, обзор — сетевые библиотеки Python.

Шифрование данных и протокол SSH​

Типовые сценарии SSH​

SSH нужен не только администраторам крупных серверов:

  • shell на VPS или учебной машине;
  • передача файлов (scp, sftp);
  • туннель к внутреннему сервису;
  • автоматизация деплоя и бэкапов.

Идея: вместо доверия к сети — шифрованный и аутентифицированный канал с явными правилами доступа.

Асимметричная криптография — открытый и закрытый ключ​

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

КлючДругое имяКто хранитТипичная роль
ОткрытыйpublicПубликуется — на сайте, в DNS, в authorized_keysШифруют данные для вас; проверяют вашу подпись
ЗакрытыйprivateТолько у владельца, часто с паролем (passphrase)Расшифровывают то, что зашифровали вашим открытым; подписывают от вашего имени

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

Шифрование по открытому ключу получателя​

Типичная цепочка (как на учебных схемах "Public Key vs Private Key"):

  1. Открытый текст — исходные данные (пароль в форме, файл, фрагмент TLS-handshake).
  2. Шифрование — отправитель берёт открытый ключ получателя и получает шифротекст.
  3. Передача — шифротекст можно слать по любой сети; перехват без закрытого ключа бесполезен.
  4. Расшифровка — получатель применяет свой закрытый ключ и восстанавливает открытый текст.

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

Цифровая подпись — те же ключи, другая роль​

Для подлинности и целостности роли меняются:

  • Подпись создаётся закрытым ключом отправителя.
  • Проверка выполняется открытым ключом отправителя.

Так работают подпись TLS-сертификата, DKIM у исходящей почты, JWT с RS256 / ES256, вход в SSH по ключу (сервер шлёт challenge, клиент подписывает его закрытым ключом). Прочитать подпись без закрытого ключа нельзя; подделать без закрытого ключа тоже.

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

ОбластьКак участвуют ключи
HTTPS (TLS)Сертификат содержит открытый ключ; браузер проверяет подпись цепочки CA. На рукопожатии стороны согласуют сессионный секрет (ECDH и др.), дальше трафик шифруют симметрично (AES-GCM, ChaCha20). См. HTTP и HTTPS.
SSHОбмен ключами (KEX), затем симметричное шифрование сессии; вход по ключу — подпись challenge. Ниже в этой статье — раздел "Как работает шифрование трафика" и интерактив EncryptionPlay.
ПочтаTLS на портах 587/993 защищает канал до сервера. Сквозное шифрование письма — OpenPGP / S/MIME (открытый ключ адресата). DKIM — подпись заголовков закрытым ключом домена, проверка по TXT в DNS. См. почта в справочнике портов.
Токены и APIAccess-токен подписан закрытым ключом auth-сервиса; API проверяет открытым или JWKS. Ошибки смешения алгоритмов — JWT — семь строк.
Диск и архивыЧаще один симметричный пароль или ключ восстановления (BitLocker, LUKS, AES в ZIP). Асимметрия встречается в корпоративных схемах и TPM.

Симметричное и асимметричное — зачем оба​

ПодходОдин секретный ключ (симметрия)Пара ключей (асимметрия)
СкоростьВысокая — подходит для потока HTTP, диска, VPNНиже — используют на коротких этапах
Обмен ключомНужен защищённый канал, чтобы передать секретОткрытый ключ можно слать открыто
ПримерыAES, ChaCha20 после TLS-handshakeRSA, Ed25519, ECDH на рукопожатии

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

Не путать с хешем пароля

На сервере пароль хранят как хеш (необратимо). HTTPS защищает пароль по пути до сервера. Разбор для формы входа — в статье про пароли.

Что такое SSH​

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

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

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

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

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

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

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

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

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

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

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

В рунет-дискурсе​

Слово "шифровка" в рунете часто означает любую "защиту" без уточнения — TLS в браузере, пароль на архив, BitLocker, хеш пароля в базе, "зашифрованный Telegram". В учебных и рабочих текстах полезно называть механизм точно:

Бытовая фразаЧто обычно имеют в виду
"Сайт с шифровкой"HTTPS (TLS между браузером и сервером)
"Зашифровал файл"Симметричное шифрование (AES) или контейнер
"Пароль захеширован"Хеш при хранении, это про базу, не про канал
"Захожу по SSH"Зашифрованный канал + аутентификация ключа

Путаница мешает диагностике: TLS защищает трафик, но не спасает от утечки на сервере или от слабого пароля. Иронические статьи — Неолурк (Шифровка); пароли и хеши — Устройство и надёжность паролей; HTTPS в браузере — HTTP как основа веб-интеграций, этапы TCP и TLS — HTTPS и TLS — шифрование веба.

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

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, шифрование и проверка целостности выполняются за один проход.

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

Play ITЗагрузка интерактивного демо…

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

Туннель в контексте 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-сервер (remote port forwarding). Подробный разбор синтаксиса, маршрута трафика и параметра GatewayPorts — ниже.

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

Пример: ssh -R 8080:localhost:3000 user@vps — веб-сервер на локальном порту 3000 доступен на VPS по порту 8080 (с учётом настроек sshd, см. ниже).

Динамический проброс (-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 закрывает сразу несколько задач одним стандартом — доступ, передача файлов, туннелирование и автоматизация. Это уменьшает число разных протоколов в инфраструктуре и, как следствие, снижает операционные риски.

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

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

Быстрый чек-лист "укрепления" SSH​

Минимальный набор, который стоит применять почти всегда:

  1. Использовать только SSH-2 и актуальный OpenSSH.
  2. Вход только по ключам, PasswordAuthentication no (где это допустимо).
  3. Запретить вход root по SSH.
  4. Ограничить список пользователей/групп, которым вообще разрешен SSH.
  5. Включить мониторинг логов и бан по перебору (например, fail2ban).
  6. Периодически пересматривать и отзывать неиспользуемые ключи.

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

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

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

  • Ограничение числа попыток входа
  • Использование 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 (rw------- — только владелец; расчёт цифры из rwx — таблица прав Linux):

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)​

Remote port forwarding (ssh -R) публикует сервис на вашей машине через удалённый SSH-сервер. Клиент с другой сети обращается к публичному хосту; sshd принимает соединение на пересланном порту и отправляет трафик по уже установленному SSH-каналу на адрес и порт, указанные в команде (обычно localhost на стороне клиента SSH).

Типичный сценарий — разработчик за домашним NAT запускает веб-сервер на localhost:80, поднимает туннель на VPS, коллега выполняет curl public-ssh-server:8080 и получает ответ с локальной машины разработчика.

Синтаксис — короткая и полная форма​

Общий вид команды:

ssh -R [remote_addr:]remote_port:local_addr:local_port [user@]ssh_server
ЧастьНазначение
-RВключить удалённый проброс порта
remote_addr (опционально)Адрес привязки на SSH-сервере; в полной форме часто 0.0.0.0
remote_portПорт на SSH-сервере, куда приходят внешние клиенты
local_addr:local_portКуда доставить трафик на машине, где запущен SSH-клиент
user@ssh_serverУдалённый хост с sshd

Короткая форма — без remote_addr (поведение привязки задаёт sshd, см. GatewayPorts):

ssh -R 8080:localhost:80 user@pub-ssh-server

Полная форма — явно указан адрес прослушивания на сервере:

ssh -R 0.0.0.0:8080:localhost:80 user@pub-ssh-server

Префикс 0.0.0.0 означает "слушать на всех сетевых интерфейсах VPS" только при соответствующей настройке сервера. Без неё sshd может всё равно привязать порт к 127.0.0.1.

Маршрут трафика​

Цепочка в одном абзаце: внешний клиент → TCP на remote_port у SSH-сервера → шифрованный канал SSH → SSH-клиент на вашей машине → local_addr:local_port (часто локальный веб-сервер или API).

Параметр GatewayPorts в sshd_config​

На сервере (файл /etc/ssh/sshd_config, после правки — systemctl reload sshd) параметр GatewayPorts определяет, к каким интерфейсам привязывается порт удалённого проброса:

ЗначениеПоведение
no (по умолчанию)Пересланный порт слушает только 127.0.0.1 на VPS. Снаружи к сервису не подключиться, даже если в -R указан 0.0.0.0. Доступ возможен с самого VPS (curl 127.0.0.1:8080).
yesПорт может слушать на всех интерфейсах. Внешние клиенты подключаются к публичному IP или DNS VPS.
clientspecifiedСервер учитывает адрес привязки из команды клиента (0.0.0.0, 127.0.0.1 и т.д.).

Пример для временной публикации dev-сервера через VPS (порт приложения 3000):

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

При GatewayPorts no запрос http://vps.example.com:8080 с интернета не дойдёт до туннеля; с самого VPS сработает curl http://127.0.0.1:8080. Для доступа извне администратор VPS включает GatewayPorts yes или clientspecified и при необходимости открывает порт в фаерволе.

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

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

Связанный сценарий без правки роутера — NAT и проброс портов. Настройка Remote Forward в PuTTY — Работа с PuTTY.

Динамическое туннелирование (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=... и запрет форвардинга превращают такой ключ в "узкоспециализированный пропуск", а не универсальный доступ к серверу.

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" /Данные/ 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 без перезапуска службы.

Куда идти дальше

Чтобы связать SSH с общей безопасностью: фаерволы, аутентификация и авторизация, пароли и хеширование, публичные Wi-Fi сети.

Основа по протоколу

Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.

Содержание