Войти
| Протокол связи | |
| Цель | безопасное соединение, удаленный интерфейс командной строки |
|---|---|
| Разработчики) | Тату Юленен, Инженерная группа Интернета (IETF) |
| Введено | 1995 г. |
| Слой OSI | Уровень приложения |
| Порт (ы) | 22 |
| RFC (ы) | RFC 4250, RFC 4251, RFC 4252, RFC 4253, RFC 4254 |
| Набор интернет-протоколов |
|---|
| Уровень приложения |
| Транспортный уровень |
|
| Интернет-уровень |
| Связующий слой |
|
|
Secure Shell ( SSH) - это криптографический сетевой протокол для безопасного управления сетевыми службами в незащищенной сети. Типичные приложения включают удаленную командную строку, вход в систему и удаленное выполнение команд, но любую сетевую службу можно защитить с помощью SSH.
SSH обеспечивает безопасный канал в незащищенной сети за счет использования клиент-серверной архитектуры, соединяя клиентское приложение SSH с сервером SSH. В спецификации протокола различаются две основные версии, называемые SSH-1 и SSH-2. Стандартный порт TCP для SSH - 22. SSH обычно используется для доступа к Unix-подобным операционным системам, но его также можно использовать в Microsoft Windows. Windows 10 использует OpenSSH в качестве SSH-клиента и SSH-сервера по умолчанию.
SSH был разработан как замена Telnet и незащищенных протоколов удаленной оболочки, таких как Berkeley rsh и связанные с ними протоколы rlogin и rexec. Эти протоколы отправляют конфиденциальную информацию, в частности пароли, открытым текстом, что делает их уязвимыми для перехвата и раскрытия с помощью анализа пакетов. Шифрования, используемый SSH предназначен для обеспечения конфиденциальности и целостности данных по незащищенной сети, такие как Интернет.
SSH использует криптографию с открытым ключом для аутентификации удаленного компьютера и позволяет ему при необходимости аутентифицировать пользователя.
Есть несколько способов использовать SSH; один из них - использовать автоматически сгенерированные пары открытого и закрытого ключей, чтобы просто зашифровать сетевое соединение, а затем использовать аутентификацию по паролю для входа в систему. Другой - использовать сгенерированную вручную пару открытого и закрытого ключей для выполнения аутентификации, позволяя пользователям или программам входить в систему без необходимости указывать пароль. В этом сценарии любой может создать соответствующую пару разных ключей (открытый и закрытый). Открытый ключ размещается на всех компьютерах, которые должны разрешить доступ владельцу соответствующего закрытого ключа (владелец хранит закрытый ключ в секрете). Хотя аутентификация основана на закрытом ключе, сам ключ никогда не передается по сети во время аутентификации. SSH только проверяет, владеет ли то же лицо, предлагающее открытый ключ, соответствующим закрытым ключом. Во всех версиях SSH важно проверять неизвестные открытые ключи, т. Е. Связывать открытые ключи с идентификаторами, прежде чем принимать их как действительные. Принятие открытого ключа злоумышленника без проверки авторизует неавторизованного злоумышленника как действительного пользователя.
В Unix-подобных системах список авторизованных открытых ключей обычно хранится в домашнем каталоге пользователя, которому разрешен удаленный вход, в файле ~ /.ssh / authorized_keys. Этот файл используется SSH только в том случае, если он не доступен для записи никому, кроме владельца и root. Когда открытый ключ присутствует на удаленном конце, а соответствующий закрытый ключ присутствует на локальном конце, ввод пароля больше не требуется. Однако для дополнительной безопасности сам закрытый ключ может быть заблокирован парольной фразой.
Закрытый ключ также можно искать в стандартных местах, а полный путь к нему можно указать в параметрах командной строки (параметр -i для ssh). SSH-серийник утилита производит открытые и закрытые ключи, всегда парами.
SSH также поддерживает аутентификацию на основе пароля, которая шифруется автоматически сгенерированными ключами. В этом случае злоумышленник может имитировать легитимную сторону сервера, запросить пароль и получить его ( атака «человек посередине» ). Однако это возможно только в том случае, если обе стороны никогда ранее не аутентифицировались, поскольку SSH запоминает ключ, который ранее использовала сторона сервера. Клиент SSH выдает предупреждение перед тем, как принять ключ нового, ранее неизвестного сервера. Парольную аутентификацию можно отключить со стороны сервера.
SSH обычно используется для входа на удаленный компьютер и выполнения команд, но он также поддерживает туннелирование, пересылку портов TCP и соединений X11 ; он может передавать файлы, используя соответствующие протоколы передачи файлов SSH (SFTP) или безопасного копирования (SCP). SSH использует модель клиент-сервер.
Клиентская программа SSH обычно используется для установления подключений к демону SSH , принимающему удаленные подключения. Оба обычно присутствуют в большинстве современных операционных систем, включая macOS, большинство дистрибутивов Linux, OpenBSD, FreeBSD, NetBSD, Solaris и OpenVMS. Примечательно, что версии Windows до Windows 10 версии 1709 по умолчанию не включают SSH. Существуют проприетарные, бесплатные программы и версии с открытым исходным кодом (например, PuTTY и версия OpenSSH, которая является частью Cygwin ) различных уровней сложности и полноты. Файловые менеджеры для UNIX-подобных систем (например, Konqueror ) могут использовать протокол FISH для предоставления графического интерфейса с разделенной панелью с перетаскиванием. Программа WinSCP для Windows с открытым исходным кодом предоставляет аналогичные возможности управления файлами (синхронизация, копирование, удаленное удаление) с использованием PuTTY в качестве серверной части. И WinSCP, и PuTTY доступны в упаковке для запуска непосредственно с USB-накопителя, без необходимости установки на клиентском компьютере. Настройка SSH-сервера в Windows обычно включает включение функции в приложении «Настройки». В Windows 10 версии 1709 доступен официальный порт OpenSSH для Win32.
SSH важен в облачных вычислениях для решения проблем с подключением, избегая проблем безопасности, связанных с открытием облачной виртуальной машины непосредственно в Интернете. Туннель SSH может обеспечить безопасный путь через Интернет через брандмауэр к виртуальной машине.
IANA присвоила TCP - порт 22, UDP порт 22 и SCTP порт 22 для этого протокола. IANA перечислила стандартный TCP-порт 22 для серверов SSH как один из хорошо известных портов еще в 2001 году. SSH также может быть запущен с использованием SCTP, а не TCP, в качестве протокола транспортного уровня, ориентированного на соединение.
В 1995 году Тату Юленен, исследователь из Хельсинкского технологического университета, Финляндия, разработал первую версию протокола (теперь называемого SSH-1), инициированную атакой по перехвату пароля в его университетской сети. Целью SSH было заменить более ранние протоколы rlogin, TELNET, FTP и rsh, которые не обеспечивали строгую аутентификацию и не гарантировали конфиденциальность. Ylönen выпустил свою реализацию как бесплатное ПО в июле 1995 года, и инструмент быстро завоевал популярность. К концу 1995 года база пользователей SSH выросла до 20 000 пользователей в пятидесяти странах.
В декабре 1995 года Илонен основал SSH Communications Security для продвижения и разработки SSH. Первоначальная версия программного обеспечения SSH использовала различные части бесплатного программного обеспечения, такие как GNU libgmp, но более поздние версии, выпущенные SSH Communications Security, превратились во все более проприетарное программное обеспечение.
Было подсчитано, что к 2000 году количество пользователей выросло до 2 миллионов.
«Secsh» было официальным интернет - Engineering Task Force имя (IETF) для рабочей группы IETF, ответственной за версию 2 протокола SSH. В 2006 году обновленная версия протокола SSH-2 была принята в качестве стандарта. Эта версия несовместима с SSH-1. SSH-2 отличается как безопасностью, так и улучшенными функциями по сравнению с SSH-1. Например, лучшая безопасность достигается за счет обмена ключами Диффи – Хеллмана и строгой проверки целостности с помощью кодов аутентификации сообщений. Новые функции SSH-2 включают возможность запускать любое количество сеансов оболочки через одно соединение SSH. Из-за превосходства и популярности SSH-2 над SSH-1 некоторые реализации, такие как libssh (v0.8.0 +), Lsh и Dropbear, поддерживают только протокол SSH-2.
В январе 2006 года, намного позже, чем была создана версия 2.1, RFC 4253 определил, что сервер SSH, который поддерживает как 2.0, так и предыдущие версии SSH, должен идентифицировать свою прототипную версию как 1.99. Это не актуальная версия, а метод определения обратной совместимости.
В 1999 году разработчики, желая, чтобы была доступна бесплатная версия программного обеспечения, вернулись к старому выпуску 1.2.12 исходной программы SSH, который был последним выпущенным под лицензией с открытым исходным кодом. OSSH Бьорна Грёнвалля был впоследствии разработан на основе этой кодовой базы. Вскоре после этого, OpenBSD разработчиков раздвоенного кода Grönvall и сделали большую работу на нем, создавая OpenSSH, который поставляется с выпуском OpenBSD 2.6. Начиная с этой версии была сформирована ветвь «переносимости» для переноса OpenSSH на другие операционные системы.
По состоянию на 2005 год OpenSSH был единственной самой популярной реализацией SSH, входящей по умолчанию в большое количество операционных систем. OSSH тем временем устарел. OpenSSH продолжает поддерживаться и поддерживает протокол SSH-2, исключив поддержку SSH-1 из кодовой базы с выпуском OpenSSH 7.6.
Пример туннелирования приложения X11 через SSH: у пользователя josh есть SSHed с локальной машины foofighter на удаленную машину tengwar для запуска xeyes. 
Вход в OpenWrt через SSH с помощью PuTTY, работающего в Windows. SSH - это протокол, который можно использовать для многих приложений на многих платформах, включая большинство вариантов Unix ( Linux, BSD, включая MacOS от Apple и Solaris ), а также Microsoft Windows. Некоторым из перечисленных ниже приложений могут потребоваться функции, которые доступны или совместимы только с определенными клиентами или серверами SSH. Например, использование протокола SSH для реализации VPN возможно, но в настоящее время только с сервером OpenSSH и реализацией клиента.
Протоколы Secure Shell используются в нескольких механизмах передачи файлов.
Схема бинарного пакета SSH-2. Протокол SSH-2 имеет внутреннюю архитектуру (определенную в RFC 4251) с хорошо разделенными уровнями, а именно:
Эта открытая архитектура обеспечивает значительную гибкость, позволяя использовать SSH для различных целей помимо безопасной оболочки. Функциональность одного транспортного уровня сравнима с безопасностью транспортного уровня (TLS); уровень аутентификации пользователя очень расширяем с помощью настраиваемых методов аутентификации; а уровень соединения обеспечивает возможность мультиплексирования множества вторичных сеансов в одно соединение SSH, функция, сравнимая с BEEP и недоступная в TLS.
Несмотря на распространенное заблуждение, SSH не является реализацией Telnet с криптографией, обеспечиваемой Secure Sockets Layer (SSL).
В 1998 году в SSH 1.5 была описана уязвимость, которая позволяла несанкционированно вставлять контент в зашифрованный поток SSH из-за недостаточной защиты целостности данных от CRC-32, используемого в этой версии протокола. Исправление, известное как SSH Compensation Attack Detector, было введено в большинство реализаций. Многие из этих обновленных реализаций содержали новую уязвимость целочисленного переполнения, которая позволяла злоумышленникам выполнять произвольный код с привилегиями демона SSH, обычно с правами root.
В январе 2001 года была обнаружена уязвимость, позволяющая злоумышленникам изменять последний блок сеанса, зашифрованного IDEA. В том же месяце была обнаружена еще одна уязвимость, позволяющая злоумышленнику перенаправить аутентификацию клиента на другой сервер.
Поскольку SSH-1 имеет врожденные недостатки конструкции, которые делают его уязвимым, в настоящее время он обычно считается устаревшим, и его следует избегать, явно отключив откат к SSH-1. Большинство современных серверов и клиентов поддерживают SSH-2.
В ноябре 2008 года была обнаружена теоретическая уязвимость для всех версий SSH, которая позволяла восстанавливать до 32 бит открытого текста из блока зашифрованного текста, который был зашифрован с использованием стандартного режима шифрования по умолчанию, CBC. Наиболее простое решение - использовать CTR, режим счетчика, вместо режима CBC, поскольку это делает SSH устойчивым к атаке.
28 декабря 2014 года Der Spiegel опубликовал секретную информацию, просочившуюся разоблачителем Эдвардом Сноуденом, из которой следует, что Агентство национальной безопасности может расшифровать некоторый трафик SSH. Технические детали, связанные с таким процессом, не разглашаются. Проведенный в 2017 году анализ хакерских инструментов ЦРУ BothanSpy и Gyrfalcon показал, что сам протокол SSH не был взломан.
В следующих публикациях RFC рабочей группы IETF "secsh" SSH-2 задокументирован как предлагаемый стандарт Интернета.
Позже он был изменен и расширен следующими публикациями.
Кроме того, проект OpenSSH включает в себя несколько спецификаций / расширений протоколов поставщиков:
