Протокол Secure Shell (SSH) — это криптографический сетевой протокол для безопасной работы сетевых служб в незащищенной сети. [1] Его наиболее заметными приложениями являются удаленный вход в систему и выполнение командной строки .
SSH был разработан для Unix-подобных операционных систем в качестве замены Telnet и незащищенных протоколов удаленной оболочки Unix , таких как Berkeley Remote Shell (rsh) и связанных с ними протоколов rlogin и rexec , которые используют небезопасные методы аутентификации с открытым текстом , например пароли .
Поскольку механизмы, такие как Telnet и Remote Shell, предназначены для доступа к удаленным компьютерам и управления ими, отправка токенов аутентификации (например, имени пользователя и пароля ) для этого доступа к этим компьютерам через публичную сеть незащищенным способом создает большой риск того, что третьи лица получат пароль и получат тот же уровень доступа к удаленной системе, что и пользователь telnet. Secure Shell снижает этот риск за счет использования механизмов шифрования, которые предназначены для сокрытия содержимого передачи от наблюдателя, даже если наблюдатель имеет доступ ко всему потоку данных. [2]
Финский ученый-компьютерщик Тату Юленен разработал SSH в 1995 году и предоставил реализацию в виде двух команд, ssh и slogin , как безопасные замены для rsh и rlogin соответственно. Последующая разработка набора протоколов продолжалась в нескольких группах разработчиков, создав несколько вариантов реализации. Спецификация протокола различает две основные версии, называемые SSH-1 и SSH-2. Наиболее часто реализуемым программным стеком является OpenSSH , выпущенный в 1999 году как программное обеспечение с открытым исходным кодом разработчиками OpenBSD . Реализации распространяются для всех типов операционных систем общего пользования, включая встроенные системы.
Приложения SSH основаны на архитектуре клиент-сервер , соединяющей экземпляр клиента SSH с сервером SSH . [3] SSH работает как многоуровневый набор протоколов, включающий три основных иерархических компонента: транспортный уровень обеспечивает аутентификацию сервера, конфиденциальность и целостность; протокол аутентификации пользователя проверяет пользователя на сервере; а протокол соединения мультиплексирует зашифрованный туннель в несколько логических каналов связи. [1]
SSH использует криптографию с открытым ключом для аутентификации удаленного компьютера и позволяет ему аутентифицировать пользователя, если это необходимо. [3]
SSH может использоваться в нескольких методологиях. В простейшем случае оба конца канала связи используют автоматически сгенерированные пары открытого и закрытого ключей для шифрования сетевого соединения, а затем используют пароль для аутентификации пользователя.
Когда пара открытого и закрытого ключей генерируется пользователем вручную, аутентификация по сути выполняется при создании пары ключей, и сеанс может быть открыт автоматически без запроса пароля. В этом сценарии открытый ключ размещается на всех компьютерах, которые должны разрешить доступ владельцу соответствующего закрытого ключа, который владелец хранит закрытым. Хотя аутентификация основана на закрытом ключе, ключ никогда не передается по сети во время аутентификации. SSH только проверяет, что тот же человек, который предлагает открытый ключ, также владеет соответствующим закрытым ключом.
Во всех версиях SSH важно проверять неизвестные открытые ключи , т.е. связывать открытые ключи с идентификаторами , прежде чем принимать их как действительные. Принятие открытого ключа злоумышленника без проверки авторизует неавторизованного злоумышленника как действительного пользователя.
В Unix-подобных системах список авторизованных открытых ключей обычно хранится в домашнем каталоге пользователя, которому разрешено входить в систему удаленно, в файле ~/.ssh/authorized_keys
. [4] Этот файл уважается SSH только в том случае, если он не доступен для записи никому, кроме владельца и root. Когда открытый ключ присутствует на удаленном конце, а соответствующий ему закрытый ключ присутствует на локальном конце, ввод пароля больше не требуется. Однако для дополнительной безопасности сам закрытый ключ может быть заблокирован с помощью парольной фразы.
Закрытый ключ можно также искать в стандартных местах, а его полный путь можно указать как параметр командной строки (опция -i
для ssh). Утилита ssh-keygen создает открытый и закрытый ключи, всегда парами.
SSH обычно используется для входа в оболочку удаленного компьютера или интерфейс командной строки (CLI) и для выполнения команд на удаленном сервере. Он также поддерживает механизмы туннелирования , переадресации портов TCP и соединений X11 , и его можно использовать для передачи файлов с использованием связанного протокола передачи файлов SSH (SFTP) или протокола безопасного копирования (SCP). [3]
SSH использует модель клиент-сервер . Клиентская программа SSH обычно используется для установления соединений с демоном SSH , таким как sshd, принимающим удаленные соединения. Оба обычно присутствуют в большинстве современных операционных систем , включая macOS , большинство дистрибутивов Linux , OpenBSD , FreeBSD , NetBSD , Solaris и OpenVMS . Примечательно, что версии Windows до Windows 10 версии 1709 не включают SSH по умолчанию, но проприетарные , бесплатные и версии с открытым исходным кодом различных уровней сложности и полноты существовали и существуют (см. Сравнение клиентов SSH ). В 2018 году Microsoft начала портировать исходный код OpenSSH в Windows [5] , и в Windows 10 версии 1709 теперь доступен официальный порт Win32 OpenSSH.
Файловые менеджеры для UNIX-подобных систем (например, Konqueror ) могут использовать протокол FISH для предоставления разделенного графического интерфейса с функцией перетаскивания. Программа Windows с открытым исходным кодом WinSCP [6] обеспечивает схожие возможности управления файлами (синхронизация, копирование, удаленное удаление) с использованием PuTTY в качестве бэкэнда. И WinSCP [7] , и PuTTY [8] доступны в упакованном виде для запуска непосредственно с USB-накопителя без необходимости установки на клиентской машине. Crostini на ChromeOS по умолчанию поставляется с OpenSSH. Настройка сервера SSH в Windows обычно включает включение функции в приложении «Настройки».
SSH важен в облачных вычислениях для решения проблем с подключением, избегая проблем безопасности, связанных с раскрытием облачной виртуальной машины непосредственно в Интернете. Туннель SSH может обеспечить безопасный путь через Интернет, через брандмауэр к виртуальной машине. [9]
IANA назначила TCP- порт 22, UDP -порт 22 и SCTP- порт 22 для этого протокола. [10] IANA включила стандартный TCP-порт 22 для SSH-серверов в список известных портов еще в 2001 году. [11] SSH также может работать с использованием SCTP вместо TCP в качестве протокола транспортного уровня, ориентированного на соединение. [12]
В 1995 году Тату Юлёнен , исследователь из Хельсинкского технологического университета в Финляндии, разработал первую версию протокола (теперь называемого SSH-1 ), вызванную атакой перехвата паролей в его университетской сети . [13] Целью SSH была замена более ранних протоколов rlogin , TELNET , FTP [14] и rsh , которые не обеспечивали ни строгой аутентификации, ни гарантии конфиденциальности. Он выбрал номер порта 22, поскольку он находится между telnet
(портом 23) и ftp
(портом 21). [15]
Юленен выпустил свою реализацию как бесплатное программное обеспечение в июле 1995 года, и инструмент быстро набрал популярность. К концу 1995 года база пользователей SSH выросла до 20 000 пользователей в пятидесяти странах. [ необходима цитата ]
В декабре 1995 года Илёнен основал SSH Communications Security для продвижения и разработки SSH. Первоначальная версия программного обеспечения SSH использовала различные части свободного программного обеспечения , такие как GNU libgmp , но более поздние версии, выпущенные SSH Communications Security, превратились во все более проприетарное программное обеспечение .
Было подсчитано, что к 2000 году число пользователей выросло до 2 миллионов. [16]
В 2006 году после обсуждения в рабочей группе под названием «secsh» [17] была принята в качестве стандарта пересмотренная версия протокола SSH, SSH-2 . [18] Эта версия предлагает улучшенную безопасность и новые функции, но несовместима с SSH-1. Например, она вводит новые механизмы обмена ключами, такие как обмен ключами Диффи–Хеллмана , улучшенную проверку целостности данных с помощью кодов аутентификации сообщений , таких как MD5 или SHA-1 , которые могут быть согласованы между клиентом и сервером. SSH-2 также добавляет более сильные методы шифрования, такие как AES , которые в конечном итоге заменили более слабые и скомпрометированные шифры из предыдущего стандарта, такие как 3-des . [19] [20] [18] Новые функции SSH-2 включают возможность запуска любого количества сеансов оболочки через одно соединение SSH. [21] Из-за превосходства и популярности SSH-2 над SSH-1 некоторые реализации, такие как libssh (v0.8.0+), [22] Lsh [23] и Dropbear [24], в конечном итоге поддерживали только протокол SSH-2.
В январе 2006 года, после того как была создана версия 2.1, RFC 4253 указал, что сервер SSH, поддерживающий 2.0, а также предыдущие версии, должен идентифицировать свою версию протокола как 1.99. [25] Этот номер версии не отражает историческую версию программного обеспечения, а является методом определения обратной совместимости .
В 1999 году разработчики, желая получить доступ к бесплатной версии программного обеспечения, возобновили разработку программного обеспечения с версии 1.2.12 оригинальной программы SSH, которая была последней, выпущенной под открытой лицензией . [26] Это послужило основой кода для программного обеспечения OSSH Бьёрна Грёнвалля. [27] Вскоре после этого разработчики OpenBSD разделили код Грёнвалля и создали OpenSSH , который был выпущен с выпуском 2.6 OpenBSD. Из этой версии была сформирована ветвь «переносимости» для переноса OpenSSH на другие операционные системы. [28]
По состоянию на 2005 год [update]OpenSSH был самой популярной реализацией SSH, являясь версией по умолчанию во многих дистрибутивах операционных систем. OSSH тем временем устарел. [29] OpenSSH продолжает поддерживаться и поддерживает протокол SSH-2, удалив поддержку SSH-1 из кодовой базы в выпуске OpenSSH 7.6.
SSH — это протокол, который может использоваться для многих приложений на многих платформах, включая большинство вариантов Unix ( Linux , BSD, включая macOS от Apple и Solaris ), а также Microsoft Windows . Некоторые из приведенных ниже приложений могут потребовать функций, которые доступны или совместимы только с определенными клиентами или серверами SSH. Например, использование протокола SSH для реализации VPN возможно, но в настоящее время только с реализацией сервера и клиента OpenSSH .
Протоколы Secure Shell используются в нескольких механизмах передачи файлов.
Протокол SSH имеет многоуровневую архитектуру с тремя отдельными компонентами:
Эта открытая архитектура обеспечивает значительную гибкость, позволяя использовать SSH для различных целей за пределами защищенной оболочки. Функциональность одного только транспортного уровня сопоставима с Transport Layer Security (TLS); уровень аутентификации пользователя легко расширяется с помощью настраиваемых методов аутентификации; а уровень соединения обеспечивает возможность мультиплексирования множества вторичных сеансов в одно соединение SSH, функция, сопоставимая с BEEP и недоступная в TLS.
В 1998 году в SSH 1.5 была описана уязвимость, которая позволяла несанкционированную вставку контента в зашифрованный поток SSH из-за недостаточной защиты целостности данных от CRC-32, используемой в этой версии протокола. [36] [37] Исправление, известное как SSH Compensation Attack Detector [38], было введено в большинство реализаций. Многие из этих обновленных реализаций содержали новую уязвимость переполнения целочисленных значений [39], которая позволяла злоумышленникам выполнять произвольный код с привилегиями демона SSH, обычно root.
В январе 2001 года была обнаружена уязвимость, позволяющая злоумышленникам изменять последний блок сеанса, зашифрованного с помощью IDEA . [40] В том же месяце была обнаружена еще одна уязвимость, позволяющая вредоносному серверу пересылать аутентификацию клиента на другой сервер. [41]
Поскольку SSH-1 имеет присущие ему недостатки дизайна, которые делают его уязвимым, в настоящее время он, как правило, считается устаревшим и его следует избегать, явно отключая откат к SSH-1. [41] Большинство современных серверов и клиентов поддерживают SSH-2. [42]
В ноябре 2008 года была обнаружена теоретическая уязвимость для всех версий SSH, которая позволяла восстановить до 32 бит открытого текста из блока шифртекста, который был зашифрован с использованием стандартного режима шифрования по умолчанию CBC . [43] Наиболее простым решением является использование CTR , режима счетчика, вместо режима CBC, поскольку это делает SSH устойчивым к атакам. [43]
28 декабря 2014 года Der Spiegel опубликовал секретную информацию [44], слитую осведомителем Эдвардом Сноуденом , которая предполагает, что Агентство национальной безопасности может быть способно расшифровать часть трафика SSH. Технические детали, связанные с таким процессом, не были раскрыты. Анализ хакерских инструментов ЦРУ BothanSpy и Gyrfalcon, проведенный в 2017 году, показал, что протокол SSH не был скомпрометирован. [45]
В 2023 году была обнаружена новая атака типа «человек посередине» против большинства текущих реализаций ssh. Ее первооткрыватели назвали ее атакой Terrapin . [46] [47] Однако риск смягчается требованием перехвата подлинного сеанса ssh, а также тем, что атака ограничена в своей области действия, что по счастливой случайности приводит в основном к сбоям соединений. [48] [49] Разработчики ssh заявили, что основным последствием атаки является ухудшение функций обфускации времени нажатия клавиш ssh. [49] Уязвимость была исправлена в OpenSSH 9.6, но для полной эффективности исправления требуется обновление как клиента, так и сервера.
Следующие публикации RFC рабочей группы IETF «secsh» документируют SSH-2 как предлагаемый стандарт Интернета .
Спецификации протокола были позднее обновлены следующими публикациями:
Кроме того, проект OpenSSH включает несколько спецификаций/расширений протоколов поставщиков:
В любом случае ossh устарел и неактуален, и я не рекомендую его использовать.