SSH

Название — Secure Shell

Семейство TCP/IP

Порт/ID 22/TCP

Назначение протокола — Удалённый доступ

Спецификация RFC 4251

Основные реализации (клиенты): OpenSSH, PuTTY/KiTTY, SecureCRT, Xshell

Основные реализации (серверы) — OpenSSH

SSH (англ. Secure Shell— «безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов). SSH использует сервер-клиентскую архитектуру, шифрует весь трафик, включая и передаваемые пароли. SSH допускает выбор различных алгоритмов шифрования и предоставляет гибкую архитектуру безопасности. Протокол был создан в 1995 году Тату Улёненом как замена небезопасным протоколам удалённого доступа Telnet и rlogin. В настоящий момент SSH является стандартом де-факто для безопасного удалённого доступа и управления.

Техническая информация

SSH — это протокол прикладного уровня, использующий архитектуру клиент-сервер. SSH-сервер по умолчанию прослушивает соединения на TCP-порту 22. Текущая версия протокола — SSH-2, описанная в RFC 4251.

Архитектура протокола

SSH имеет многоуровневую архитектуру, состоящую из трёх основных компонентов:

1. Транспортный уровень (RFC 4253) — обеспечивает начальный обмен ключами, аутентификацию сервера, устанавливает алгоритмы шифрования, сжатия и проверки целостности. Предоставляет интерфейс для пересылки пакетов размером до 32 КБ. Также отвечает за повторный обмен ключами, обычно производимый после передачи каждого гигабайта данных или после каждого часа работы.
2. Пользовательский уровень (RFC 4252) — отвечает за аутентификацию клиента и предоставляет различные методы аутентификации: по паролю, по открытому ключу, интерактивный (с вводом одноразовых паролей и т. п.), через GSSAPI.
3. Уровень соединения (RFC 4254) — определяет понятия каналов, глобальных и специфичных для канала запросов. Единственное SSH соединение может мультиплексироваться в несколько логических каналов, каждый из которых работает в полнодуплексном режиме. Запросы на уровне каналов позволяют передавать канально-специфичные данные, например изменение размера окна терминала. Глобальные запросы используются для передачи информации вне рамок каналов.

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

Аутентификация

Для аутентификации сервера в SSH используются алгоритмы электронной цифровой подписи RSA, DSA, ECDSA, EdDSA. В большинстве реализаций применяется RSA. Аутентификация клиента может производиться различными методами:

• Аутентификация по паролю — наиболее распространённый метод. Пароль передаётся по защищённому SSH-соединению.
• Аутентификация по открытому ключу — клиент и сервер предварительно обмениваются открытыми ключами RSA, DSA, ECDSA или Ed25519. Закрытый ключ клиента хранится локально и никуда не передаётся. SSH лишь проверяет, что владелец закрытого ключа имеет доступ к соответствующему открытому.
• Интерактивная аутентификация (keyboard-interactive) — универсальный метод, позволяющий серверу запрашивать у пользователя одноразовые пароли, ПИН-коды и другие временные токены. Например, подходит для интеграции с PAM и использования аппаратных OTP-токенов.
• Аутентификация через GSSAPI — позволяет интегрировать SSH с Kerberos 5, NTLM и другими механизмами единого входа (SSO), распространёнными в корпоративных сетях.

Шифрование и защита целостности

Для выработки общих секретных ключей используются алгоритмы Диффи-Хеллмана и ECDH на эллиптических кривых. Далее трафик шифруется симметричными алгоритмами: AES (рекомендуется), ChaCha20-Poly1305, Camellia, Blowfish, 3DES, RC4 (не рекомендуется). Целостность данных проверяется с помощью HMAC на базе SHA-2 или SHA-1. В SSH версии 1 использовались CRC32, что было небезопасно.

Современные реализации поддерживают согласование алгоритмов между клиентом и сервером. Рекомендуется использовать только алгоритмы, считающиеся криптографически стойкими: AES, ChaCha20-Poly1305, SHA-2, Diffie-Hellman/ECDH с достаточной длиной ключа.

Сжатие данных

SSH поддерживает сжатие передаваемых данных алгоритмом LempelZiv (LZ77), обеспечивающим степень сжатия, сравнимую с архиватором ZIP. Сжатие включается по запросу клиента и выполняется перед шифрованием. На практике сжатие используется редко, так как даёт выигрыш лишь на некоторых типах данных.

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

Посредством SSH можно туннелировать любой TCP-трафик через единственный зашифрованный канал, реализуя таким образом VPN. Один из наиболее полезных видов туннелей — перенаправление (forwarding) TCP-портов. SSH позволяет привязать локальный порт клиента к заданному порту на сервере (local forwarding) или наоборот (remote forwarding).

Например, чтобы получить доступ к веб-серверу, находящемуся внутри периметра безопасности, можно перенаправить с локальной машины порт 8080 на удалённый хост example.com и порт 443: bashCopyssh -L 8080:example.com:443 user@sshserver

После этого, обращаясь к localhost:8080, пользователь попадет на example.com:443, причём трафик будет шифроваться SSH-сервером sshserver. Таким образом реально организовать защищённый доступ к ресурсам сети, закрытым брандмауэром.

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

Поверх SSH работают несколько специализированных протоколов передачи файлов:

• SFTP — работает поверх SSH и является его стандартным расширением. Обеспечивает безопасную передачу файлов и работу с файловой системой (листинг, переименование, удаление и т. д.)
• SCP — простой протокол для копирования файлов с удалённого хоста или на него. Безопасная замена rcp.
• FISH — нестандартный протокол, реализованный в файловом менеджере Konqueror. Работает как SFTP, но использует для команд оболочку Unix.
• rsync-over-SSH — rsync, работающий поверх SSH. Позволяет эффективно синхронизировать файлы и каталоги.

В отличие от FTP и FTPS, протоколы SFTP и SCP работают в рамках единого SSH-соединения, используя его для передачи команд и данных. Это упрощает настройку и обеспечивает полноценное шифрование при передаче файлов.

История

SSH был разработан в 1995 году финским учёным Тату Улёненом из Хельсинкского технологического университета под впечатлением от атаки на университетскую сеть путём перехвата паролей. Целью Улёнена было создание безопасной замены небезопасным протоколам удалённого доступа rlogin, TELNET и rsh.

В июле 1995 года Улёнен выпустил первую версию SSH (сейчас известную как SSH-1) как свободное ПО. К концу 1995 года у SSH было уже около 20 000 пользователей в 50 странах. В декабре 1995 года Улёнен основал компанию SSH Communications Security для дальнейшей разработки и коммерциализации SSH. Постепенно лицензия на SSH становилась всё более ограничительной. Поздние версии SSH запрещали его использование в коммерческой среде без покупки лицензии у компании Datafellows.

В начале 1999 года Берн Гренвалл повторно открыл старую свободную версию ssh 1.2.12 и начал исправлять в ней ошибки. Его версия получила название OSSH и поддерживала только протокол SSH 1.3.

В конце 1999 года разработчики OpenBSD узнали о работе Гренвалла и решили включить SSH в дистрибутив OpenBSD 2.6. Для этого они форкнули OSSH и занялись быстрой доработкой кода. Нужно было успеть к релизу OpenBSD 2.6, который планировался через 2 месяца. Основные изменения включали:

• удаление зависимостей и чистка кода для упрощения поиска проблем безопасности (Тэо де Раадт);
• удаление оставшихся криптографических компонентов, защищённых патентами и лицензией GPL (заменены на OpenSSL) — Нильс Провос;
• замена поддержки устаревшего протокола SSH 1.3 на SSH 1.5 с сохранением обратной совместимости (Маркус Фридл);
• поддержка SSH в сборке OpenBSD без запатентованных алгоритмов RSA (Боб Бек);
• улучшение документации (Аарон Кэмпбелл);
• доработка аутентификации в случае использования Kerberos IV (Даг Сонг).

Эта версия под названием OpenSSH 1.2.2 была включена в OpenBSD 2.6, выпущенный 1 декабря 1999 года. OpenSSH быстро портировали на Linux и другие ОС. Разработчики OpenSSH сразу приняли архитектуру, разделяющую независимую от ОС базовую версию и переносимую версию с адаптацией к конкретным платформам.

В 2000 году Маркус Фридл реализовал в OpenSSH поддержку протокола SSH 2 при сохранении совместимости с SSH 1. Новая версия OpenSSH 2.0 вышла 15 июня 2000 г. в составе OpenBSD 2.7. В ноябре 2000 года в OpenSSH 2.3.0 добавлена поддержка SFTP на стороне сервера, вскоре Дамьен Миллер написал клиент SFTP.

В 2006 году протокол SSH-2 был окончательно стандартизирован IETF. К 2006 году OpenSSH стал основной реализацией SSH, применяемой по умолчанию в большинстве Unix-подобных ОС. Параллельно развивались и проприетарные реализации SSH, такие как коммерческий SSH Tectia от SSH Communications Security. Однако OpenSSH доминирует благодаря открытости, переносимости и включению в состав ОС.

Новые функции и улучшения безопасности непрерывно добавляются в OpenSSH. Так, в 2015-2018 годах добавлена поддержка более современных алгоритмов обмена ключами и цифровой подписи: Curve25519, Ed25519, ECDSA, ECDH. В 2020 г. удалена поддержка устаревшего и небезопасного протокола SSH-1.

Сферы применения

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

1. Безопасный удалённый доступ к системам. SSH является стандартным средством для защищённого интерактивного доступа к командной строке удалённых серверов и устройств. Администраторы повсеместно используют SSH для управления серверами, настройки сетевого оборудования, запуска команд и сценариев. SSH заменил небезопасный протокол Telnet и де-факто стал промышленным стандартом для удалённого администрирования.
2. Безопасная передача файлов. Поверх SSH работают специализированные протоколы для передачи файлов — SFTP и SCP. Они позволяют безопасно загружать файлы на удалённую систему и скачивать с неё, а также выполнять основные операции с файлами и каталогами. SFTP и SCP являются защищённой заменой устаревшему протоколу FTP.
3. Организация защищённых туннелей. SSH позволяет создавать зашифрованные туннели для передачи произвольного TCP-трафика. Такие туннели применяются для защиты передаваемых данных, обхода сетевых ограничений, организации VPN. Например, SSH-туннели часто используют для безопасного доступа к веб-серверам, базам данных, почтовым службам внутри периметра безопасности организации.
4. Сквозная передача соединений с аутентификацией (port forwarding). SSH умеет передавать TCP-соединения с одной машины на другую с сохранением аутентификации. Это применяется для доступа с локальной машины к портам и сервисам, расположенным на удалённой машине за SSH-сервером. Например, можно направить обращения к локальному порту на сервис внутри удалённой сети.
5. Безопасная работа с графическими приложениями. Через SSH можно безопасно использовать графические приложения, работающие на удалённой машине. При включении SSH-forwarding сервер будет направлять команды отрисовки и события X11 через SSH-соединение, а локальный X-сервер отобразит окна удалённого приложения. Это используют для работы со специфическим ПО без установки его на локальной машине.
6. Автоматизация управления серверами и выполнения команд. SSH встроен практически во все языки программирования и скрипты (Python, Ruby, Perl) и применяется для автоматизированного исполнения команд на удалённых серверах. Библиотеки, такие как paramiko для Python, позволяют легко встроить управление по SSH в программы резервного копирования, скрипты настройки, системы управления конфигурациями и развёртыванием.
7. Защита облачных сред и виртуальных машин. При работе с публичными и гибридными облаками SSH является основным способом управления виртуальными машинами, контейнерами, сетевыми службами. Он позволяет безопасно управлять экземплярами в облаке без необходимости выставлять дополнительные порты или сервисы наружу. SSH-туннели защищают доступ к БД, кэшам, очередям сообщений и внутренним API.
8. Защита сетевых протоколов управления и мониторинга. Многие протоколы сетевого управления, такие как SNMP, NETCONF, Syslog имеют привязку к SSH. Она обеспечивает шифрование, целостность данных и аутентификацию при передаче чувствительной информации о конфигурации, логах, метриках, событиях безопасности. Использование SSH вместо обычных текстовых протоколов существенно снижает риски при администрировании сетевого оборудования и серверов.
9. Безопасный доступ к сетевым устройствам. SSH является стандартным методом администрирования маршрутизаторов, коммутаторов, межсетевых экранов. Практически все современные сетевые операционные системы (Cisco IOS, Juniper Junos) и сетевые устройства поддерживают SSH «из коробки». Это позволяет централизованно и безопасно управлять сетевой инфраструктурой.
10. Двухфакторная аутентификация. SSH поддерживает множество методов аутентификации, в том числе двухфакторную с использованием аппаратных ключей, смарт-карт, одноразовых паролей. Это позволяет усилить защиту доступа к критичным системам и данным, снизить риски компрометации учётных данных. Например, популярны решения с SSH-аутентификацией через PAM-модули, интегрированные с RSA SecurID или аналогичными системами.

Уязвимости и практики безопасности

За долгую историю существования в реализациях SSH были выявлены различные уязвимости. Большинство из них достаточно быстро исправлялись, но некоторые приводили к серьёзным проблемам безопасности.

Уязвимости SSH-1

Изначальная версия протокола SSH-1 содержала ряд концептуальных недостатков и уязвимостей:

• Уязвимость CRC-32 (1998) — из-за слабой целостности CRC-32 была возможна инъекция данных в зашифрованный поток. Была закрыта в новых версиях SSH-1.
• Уязвимость ключей SSH-1 (2001) — слабость алгоритма обмена ключами позволяла модифицировать сессионный ключ. Не устранена полностью.
• Переадресация аутентификации (2001) — вредоносный SSH-сервер мог перенаправить аутентификацию клиента на другой сервер.

Из-за этих и других проблем SSH-1 считается устаревшим и небезопасным. Современные реализации по умолчанию используют SSH-2 и должны блокировать попытки клиента согласовать SSH-1.

Атака на CBC в SSH-2

В 2008 году теоретически показана возможность частичного (до 32 бит) восстановления открытого текста при использовании CBC-режима шифрования. Поэтому рекомендуется вместо CBC использовать режим CTR, который неуязвим к этой атаке.

Уязвимости реализаций

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

• Уязвимость агента SSH Tectia, позволявшая обходить ограничения настроенные в sudoers.
• Уязвимости переполнения буфера и подмены адреса в SSH-клиентах с GUI (например, в PuTTY).
• Утечки чувствительных данных (закрытых ключей) через переменные окружения и файлы сессий.
• Проблемы совместимости между различными реализациями SSH.

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

Уязвимости SSH-сервера

При некорректной настройке SSH-сервера возможны атаки:

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

Передовые практики безопасности

Для снижения рисков при использовании SSH рекомендуется:

1. Запретить прямой вход суперпользователя (root) по SSH.
2. Отключить аутентификацию по паролю и использовать только аутентификацию по ключам.
3. Использовать нестандартный порт для SSH (вместо 22).
4. Ограничить диапазон IP-адресов, с которых разрешены подключения (allow/deny в sshd_config).
5. Регулярно пересматривать и ротировать SSH-ключи сотрудников, особенно при увольнениях.
6. Использовать двухфакторную аутентификацию (2FA) с SSH для защиты критичных серверов.
7. Централизованно логировать и мониторить попытки аутентификации по SSH.
8. Не использовать SSH-агент (ssh-agent) без необходимости, шифровать закрытые ключи ключевой фразой.
9. Контролировать и ограничивать команды, которые могут выполнять пользователи.
10. На критичных серверах использовать только проверенные реализации SSH-серверов и регулярно обновлять их.

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

Ссылки

Стандарты

• RFC 4250 (англ.) — The Secure Shell (SSH) Protocol Assigned Numbers
• RFC 4251 (англ.) — The Secure Shell (SSH) Protocol Architecture
• RFC 4252 (англ.) — The Secure Shell (SSH) Authentication Protocol
• RFC 4253 (англ.) — The Secure Shell (SSH) Transport Layer Protocol
• RFC 4254 (англ.) — The Secure Shell (SSH) Connection Protocol
• RFC 4255 (англ.) — Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
• RFC 4256 (англ.) — Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
• RFC 4335 (англ.) — The Secure Shell (SSH) Session Channel Break Extension
• RFC 4344 (англ.) — The Secure Shell (SSH) Transport Layer Encryption Modes
• RFC 4345 (англ.) — Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol
• RFC 4419 (англ.) — Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
• RFC 4432 (англ.) — RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
• RFC 4716 (англ.) — The Secure Shell (SSH) Public Key File Format

SSH-клиенты

• Уязвимость в SSH
• Теория и практика использования SSH
• Команды Linux / SSH
• SSH для администратора

Данная статья имеет статус «готовой». Это не говорит о качестве статьи, однако в ней уже в достаточной степени раскрыта основная тема. Если вы хотите улучшить статью — правьте смело!