Что такое SSH и как он работает?

Secure Shell (SSH) – это общепринятый протокол безопасности с широким спектром применения. Его самое известное приложение позволяет пользователям безопасный доступ к удаленным компьютерам и серверам, но его также можно использовать для туннелирования, переадресации портов, безопасной передачи файлов и многого другого.

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

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

Использование SSH

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

Удаленный доступ

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

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

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

Перенаправление порта

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

Переадресация портов может быть выполнена тремя различными способами:

• Местный Перенаправление порта – Локальная переадресация портов позволяет подключить локальный клиент и внешнюю сеть. Это может быть эффективно для таких вещей, как доступ к веб-сайтам, которые заблокированы локально, или для подключения к базе данных, которая находится за брандмауэром..
• Переадресация удаленных портов – Этот тип пересылки позволяет серверным приложениям получать доступ к службам на стороне клиента. Удаленная переадресация портов SSH позволяет пользователям безопасно подключаться к удаленным серверам через локальный ПК, перенаправляя локальный порт на удаленный сервер SSH..
• динамический Перенаправление порта – Это позволяет пользователям отправлять свои данные через определенный порт на удаленный компьютер или сервер, используя несколько серверов SSH, которые действуют как прокси.

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

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

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

SFTP

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

SCP

Протокол защищенного копирования (SCP) аналогичен протоколу SFTP, но более ограничен по объему. Это позволяет только безопасную передачу файлов, а не полный набор функций, которые позволяют SFTP выступать в качестве протокола удаленной файловой системы..

платформы & приложения, использующие SSH

Собственный SSH или OpenSSH можно использовать во всех основных операционных системах. Он доступен на Unix-платформах, таких как OpenBSD, macOS, Linux и Solaris, в то время как пользователи Windows могут использовать SSH через PowerShell..

История SSH

SSH был разработан в 1995 году в Хельсинкском технологическом университете Тату Йолененом в ответ на атаку с использованием пароля в сети университета. Он направлен на предоставление альтернативы таким протоколам, как FTP, TELNET, rsh и Rlogin, который не обеспечивал конфиденциальность или аутентификацию пользователей безопасным способом.

SSH был выпущен бесплатно для публики в 1995 году и был хорошо принят. В связи с его быстрым внедрением, Ylönen основал SSH Communications Security к концу того же года, чтобы продолжить разработку и коммерциализацию SSH..

В 1995 году Илонен также опубликовал проект интернет-проекта Целевой группы по Интернету (IETF), который задокументировал протокол SSH-1. Вскоре в протоколе были обнаружены ограничения, которые не могли быть устранены без обратной совместимости. Решением стала новая версия протокола, и SSH-2 была запущена компанией Ylönen в 1996 году..

В SSH-2 появились новые алгоритмы, которые побудили IETF создать рабочую группу, которая стремилась стандартизировать протокол. Группа получила прозвище SECSH, для SecЮр Shи он опубликовал свой первый интернет-проект для SSH-2 в 1997 году.

Программное обеспечение для SSH-2 было выпущено в 1998 году, но оно не было сразу широко распространено из-за более ограниченного лицензирования. В 2006 году IETF внесла изменения в версию протокола.. Это было более безопасно, используя коды аутентификации сообщений для проверки целостности и обмен ключами Диффи-Хеллмана для аутентификации.

В 1999 году проект OpenBSD выпустил OpenSSH. OpenSSH – бесплатная версия протокола это основано на модификациях, которые Бьёрн Грёнвалл сделал в SSH 1.1.12. Разработчики вернулись к этой старой версии и сильно изменили ее, потому что это была последняя версия SSH с полностью открытым исходным кодом. OpenSSH в настоящее время является наиболее широко используемым вариантом, и с тех пор он был реализован в ряде операционных систем, таких как Windows, macOS, Linux, Solaris и других..

SSH-1 против SSH-2 против OpenSSH

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

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

SSH: технические детали

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

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

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

Процесс удаленного входа в систему SSH происходит в соответствии со следующей базовой структурой (с вариациями в зависимости от конфигурации), которую мы рассмотрим более подробно позже:

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

Транспортный протокол

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

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

транспортный протокол аутентифицирует только сервер, а не клиент (проверка подлинности клиента выполняется в протоколе проверки подлинности, если это необходимо).

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

Как только соединение начинается, и сервер, и клиент должны отправить через строку идентификации, которая включает версию протокола (2.0).

Алгоритм согласования

Для настройки параметров соединения обе стороны отправляют через пакет, содержащий список со следующими параметрами:

байт SSH_MSG_KEXINIT

байт [16] cookie (случайные байты)
список имен kex_algorithms
список имен server_host_key_algorithms
name-list encryption_algorithms_client_to_server
name-list encryption_algorithms_server_to_client
список имен mac_algorithms_client_to_server
список имен mac_algorithms_server_to_client
сжатие имен_алгоритмов_client_to_server
сжатие имен_алгоритмов_сервер_в_клиент
список имен languages_client_to_server
список имен languages_server_to_client
логический first_kex_packet_follows
uint32 0 (зарезервировано для будущего расширения)

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

За обмен ключами (kex_algorithms), первый алгоритм, который поддерживают обе стороны, будет выбран для соединения (могут также быть другие факторы, которые должны быть выполнены, в зависимости от того, какой алгоритм был выбран). Если обе стороны не могут найти взаимно поддерживаемый алгоритм, который удовлетворяет этим требованиям, то соединение не устанавливается.

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

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

Оба Алгоритм MAC и алгоритм сжатия оговариваются таким же образом.

Обмен ключами

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

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

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

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

Согласно интернет-проекту Internet Engineering Task Force (IETF), следующие методы обмена ключами считаются безопасными:

• curve25519-sha256
• curve448-sha512
• Диффи-Хеллмана-группа обменных sha256
• Диффи-Хеллмана-group14-sha256
• Диффи-Хеллмана-group15-sha512
• Диффи-Хеллмана-group16-sha512
• Диффи-Хеллмана-group17-sha512
• Диффи-Хеллмана-group18-sha512
• ECDH-SHA2-nistp256
• ECDH-SHA2-nistp384
• GSS-group14-sha256
• GSS-group15-sha512
• GSS-group16-sha512
• GSS-group17-sha512
• GSS-group18-sha512
• GSS-nistp256-sha256
• GSS-nistp384-SHA384
• GSS-nistp521-sha512
• GSS-curve25519-sha256
• GSS-curve448-sha512
• rsa2048-sha256

Алгоритм ключа хоста сервера

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

• Он использует алгоритмы с открытым ключом для шифрования и / или цифровых подписей.
• Может быть реализован ряд методов кодирования, позволяющих конфигурировать с различными форматами данных, заполнением и порядком байтов.
• Различные форматы ключей позволяют кодировать ключи по-разному, а также ряд представлений сертификатов.

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

• SSH-RSA
• SSH-RSA-sha256
• SSH-ДСС
• SSH-ДСС-sha256
• x509v3-знак-ДСС
• x509v3-знак-ДСС-sha256
• x509v3-знак и РКА
• x509v3-вход-sha256 RSA

Алгоритмы шифрования

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

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

Алгоритмы MAC

Транспортный протокол проверяет целостность данных, добавляя код аутентификации сообщения (MAC) к пакету. Этот MAC основан на общем секрете (который устанавливается при обмене ключами), порядковом номере пакета и содержимом пакета. Он рассчитывается до шифрования.

Реализации должны предлагать независимый алгоритм для работы в каждом направлении, хотя идеально, если один и тот же алгоритм используется с обеих сторон. Могут быть реализованы самые разнообразные алгоритмы аутентификации сообщений, однако SHA-256 и выше должны использоваться в большинстве ситуаций для обеспечения высокого уровня безопасности..

компрессия

Сжатие не является обязательным в протоколе SSH, и его реализации должны разрешать соединения без сжатия. Сжатие может быть реализовано только как опция, с использованием таких схем, как Zlib. Если используется сжатие, оно влияет только на полезную нагрузку. MAC и поле длины пакета затем вычисляются на основе сжатой полезной нагрузки..

Пакет транспортного протокола

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

• Длина пакета
• Длина отступа
• Полезная нагрузка
• набивка
• Код аутентификации сообщения (MAC)

Протокол аутентификации

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

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

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

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

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

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

Процесс протокола аутентификации

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

Наиболее распространенные методы аутентификации клиента включают в себя:

• Открытый ключ – Этот метод использует такие алгоритмы, как RSA, DSA и ECDSA, для аутентификации клиента с помощью криптографии с открытым ключом. Некоторые реализации также используют сертификаты x.509. Сервер проверяет цифровую подпись клиента по его открытому ключу для проверки личности клиента.
• пароль – Пароли также могут быть использованы для аутентификации клиента. Клиент отправляет через свой пароль (который должен быть зашифрован транспортным протоколом). Если пароль соответствует сохраненному значению сервера, он принимается, и аутентификация продвигается вперед.
• GSSAPI – При этом методе внешние схемы, такие как Kerberos, могут использоваться для единого входа..
• Клавиатура интерактивная – Этот метод обеспечивает аутентификацию по одноразовому паролю, когда сервер запрашивает у клиента информацию.

Протокол соединения

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

Протокол соединения находится поверх транспортного уровня и протоколов аутентификации. Это позволяет удаленно выполнять команды, а также перенаправлять соединения X11 и TCP / IP. Если сервер или клиент были скомпрометированы, то протокол соединения не защищен.

каналы

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

Открытие каналов

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

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

Когда одна сторона запрашивает открытие канала, другая сторона откроет канал, если она сможет это разместить. Если нет, он отправит сообщение об ошибке. Каналы могут не открываться по следующим причинам:

• Запрещено администрацией
• Ошибка соединения
• Неизвестный тип канала
• Нехватка ресурсов

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

Закрытие каналов

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

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

Различные версии SSH имели свои собственные проблемы безопасности, хотя текущие конфигурации SSH-2 и OpenSSH считаются намного безопаснее, чем SSH-1.

SSH-1

SSH-1, как правило, считается дефектным, с рядом различных уязвимостей. К ним относится ошибка в SSH 1.5, которая позволяла неавторизованным пользователям вставлять контент в поток данных SSH. В этой атаке использовалась минимальная защита целостности данных алгоритма CRC-32..

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

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

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

SSH-2

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

В конце 2014 года Der Spiegel опубликовал документы АНБ, которые подразумевали, что АНБ может иногда нарушать SSH. Это утечка NSA PowerPoint заявляет, что АНБ может «Потенциально восстановить имена пользователей и пароли», Хотя никаких дополнительных подробностей не приводится. Неизвестно, какие методы использовались агентством для этого, но маловероятно, что оно будет полагаться на свои возможности в собственной внутренней документации..

В результате утечки Vault 7 в [year] году выяснилось, что у ЦРУ было два инструмента, которые можно было использовать для перехвата и кражи логинов и паролей SSH. BothanSpy предназначался для клиентов Windows Xshell, в то время как Gyrfalcon использовался против клиента OpenSSH в ряде различных дистрибутивов Linux..

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

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

OpenSSH

В OpenSSH версии 2, была обнаружена атака, которая использовала слабость двоичного пакета SSH. Атака позволила исследователям из Лондонского университета восстановить 14 бит открытого текста из зашифрованного блока. Это было исправлено в выпуске 5.2, так как протокол считывал всю недопустимую длину пакета или код аутентификации сообщения, а не разрывал соединение.

В версиях 6.8 и 6.9 Linux можно использовать для выполнения произвольных команд на терминалах других пользователей. Это было достигнуто благодаря уязвимости повышения привилегий, которая позволяла злоумышленникам вводить символы с помощью элемента управления вводом / выводом TIOCSTI..

Безопасен ли SSH??

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

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

Смотрите также: Общие типы шифрования объяснены

Кибернетические технологии фон от TheDigitalArtist по лицензии СС0