Безопасная оболочка
Криптографический сетевой протокол
Безопасная оболочка
Стек протоколов
Цельбезопасное соединение, удаленный доступ
Разработчик(и)Тату Юленен, Рабочая группа по проектированию Интернета (IETF)
Введение1995
уровень OSIТранспортный уровень через прикладной уровень
Порт(ы)22
Запрос(ы) предложений (RFC)RFC 4250, RFC 4251, RFC 4252, RFC 4253, RFC 4254
набор интернет-протоколов
Уровень приложений
Транспортный уровень
Интернет-слой
Связующий слой

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

Аутентификация: управление ключами OpenSSH

В 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]

Историческое развитие

Версия 1

В 1995 году Тату Юлёнен , исследователь из Хельсинкского технологического университета в Финляндии, разработал первую версию протокола (теперь называемого SSH-1 ), вызванную атакой перехвата паролей в его университетской сети . [13] Целью SSH была замена более ранних протоколов rlogin , TELNET , FTP [14] и rsh , которые не обеспечивали ни строгой аутентификации, ни гарантии конфиденциальности. Он выбрал номер порта 22, поскольку он находится между telnet(портом 23) и ftp(портом 21). [15]

Юленен выпустил свою реализацию как бесплатное программное обеспечение в июле 1995 года, и инструмент быстро набрал популярность. К концу 1995 года база пользователей SSH выросла до 20 000 пользователей в пятидесяти странах. [16]

В декабре 1995 года Илёнен основал SSH Communications Security для продвижения и разработки SSH. Первоначальная версия программного обеспечения SSH использовала различные части свободного программного обеспечения , такие как GNU libgmp , но более поздние версии, выпущенные SSH Communications Security, превратились во все более проприетарное программное обеспечение .

Было подсчитано, что к 2000 году число пользователей выросло до 2 миллионов. [17]

Версия 2

В 2006 году после обсуждения в рабочей группе под названием «secsh» [18] была принята в качестве стандарта пересмотренная версия протокола SSH, SSH-2 . [19] Эта версия предлагает улучшенную безопасность и новые функции, но несовместима с SSH-1. Например, она вводит новые механизмы обмена ключами, такие как обмен ключами Диффи–Хеллмана , улучшенную проверку целостности данных с помощью кодов аутентификации сообщений , таких как MD5 или SHA-1 , которые могут быть согласованы между клиентом и сервером. SSH-2 также добавляет более сильные методы шифрования, такие как AES , которые в конечном итоге заменили более слабые и скомпрометированные шифры из предыдущего стандарта, такие как 3-des . [20] [21] [19] Новые функции SSH-2 включают возможность запуска любого количества сеансов оболочки через одно соединение SSH. [22] Из-за превосходства и популярности SSH-2 над SSH-1 некоторые реализации, такие как libssh (v0.8.0+), [23] Lsh [24] и Dropbear [25], в конечном итоге поддерживали только протокол SSH-2.

Версия 1.99

В январе 2006 года, после того как была создана версия 2.1, RFC  4253 указал, что сервер SSH, поддерживающий 2.0, а также предыдущие версии, должен идентифицировать свою версию протокола как 1.99. [26] Этот номер версии не отражает историческую версию программного обеспечения, а является методом определения обратной совместимости .

OpenSSH и OSSH

В 1999 году разработчики, желая получить доступ к бесплатной версии программного обеспечения, возобновили разработку программного обеспечения с версии 1.2.12 оригинальной программы SSH, которая была последней, выпущенной под открытой лицензией . [27] Это послужило основой кода для программного обеспечения OSSH Бьёрна Грёнвалля. [28] Вскоре после этого разработчики OpenBSD разделили код Грёнвалля и создали OpenSSH , который был выпущен с выпуском 2.6 OpenBSD. Из этой версии была сформирована ветвь «переносимости» для переноса OpenSSH на другие операционные системы. [29]

По состоянию на 2005 год [update]OpenSSH был самой популярной реализацией SSH, являясь версией по умолчанию во многих дистрибутивах операционных систем. OSSH тем временем устарел. [30] OpenSSH продолжает поддерживаться и поддерживает протокол SSH-2, удалив поддержку SSH-1 из кодовой базы в выпуске OpenSSH 7.6.

Будущее

В 2023 году аспирант Франсуа Мишель и профессор Оливье Бонавентура предложили альтернативу традиционному SSH под названием SSH3 [31] [32] [33] , и ее код был открыт. [34] Эта новая версия реализует оригинальный протокол соединения SSH, но работает поверх HTTP/3 , который работает на QUIC . Он предлагает множество функций, таких как:

  • Более быстрое установление сеанса, сокращение количества задержек приема-передачи с 5-7 до 3.
  • Высокая безопасность: в то время как SSHv2 использует собственные протоколы, SSH3 использует TLS 1.3 , QUIC и HTTP .
  • Переадресация UDP-портов
  • Сертификаты X.509
  • OpenID-подключение

Однако название SSH3 находится в стадии обсуждения, и проект намерен переименовать себя в более подходящее имя. [35] Обсуждение вызвано тем фактом, что эта новая реализация значительно изменяет протокол SSH, что предполагает, что его не следует называть SSH3.

Использует

Пример туннелирования приложения X11 через SSH: пользователь «josh» подключился по SSH с локальной машины «foofighter» к удаленной машине «tengwar» для запуска xeyes .
Вход в OpenWrt через SSH с помощью PuTTY , работающего на Windows .

SSH — это протокол, который может использоваться для многих приложений на многих платформах, включая большинство вариантов Unix ( Linux , BSD, включая macOS от Apple и Solaris ), а также Microsoft Windows . Некоторые из приведенных ниже приложений могут потребовать функций, которые доступны или совместимы только с определенными клиентами или серверами SSH. Например, использование протокола SSH для реализации VPN возможно, но в настоящее время только с реализацией сервера и клиента OpenSSH .

  • Для входа в оболочку на удаленном хосте (замена Telnet и rlogin )
  • Для выполнения одной команды на удаленном хосте (замена rsh )
  • Для настройки автоматического (безпарольного) входа на удаленный сервер (например, с помощью OpenSSH [36] )
  • В сочетании с rsync для эффективного и безопасного резервного копирования, копирования и зеркалирования файлов
  • Для переадресации порта
  • Для туннелирования (не путать с VPN , который маршрутизирует пакеты между различными сетями или объединяет два широковещательных домена в один).
  • Для использования в качестве полноценного зашифрованного VPN. Обратите внимание, что только сервер и клиент OpenSSH поддерживают эту функцию.
  • Для пересылки X с удаленного хоста (возможно через несколько промежуточных хостов)
  • Для просмотра веб-страниц через зашифрованное прокси-соединение с SSH-клиентами, поддерживающими протокол SOCKS .
  • Для безопасного монтирования каталога на удаленном сервере в качестве файловой системы на локальном компьютере с использованием SSHFS .
  • Для автоматизированного удаленного мониторинга и управления серверами с помощью одного или нескольких механизмов, рассмотренных выше.
  • Для разработки на мобильном или встраиваемом устройстве, поддерживающем SSH.
  • Для защиты протоколов передачи файлов.

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

Протоколы Secure Shell используются в нескольких механизмах передачи файлов.

Архитектура

Схема двоичного пакета SSH-2.

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

  • Транспортный уровень ( RFC  4253) обычно использует протокол управления передачей (TCP) TCP/IP , резервируя порт номер 22 в качестве порта прослушивания сервера. Этот уровень обрабатывает начальный обмен ключами, а также аутентификацию сервера и устанавливает шифрование, сжатие и проверку целостности. Он предоставляет верхнему уровню интерфейс для отправки и получения пакетов открытого текста размером до 32 768 байт каждый, но каждая реализация может разрешить больше. Транспортный уровень также организует повторный обмен ключами, обычно после передачи 1 ГБ данных или по истечении одного часа, в зависимости от того, что произойдет раньше.
  • Уровень аутентификации пользователя ( RFC  4252) обрабатывает аутентификацию клиента и предоставляет набор алгоритмов аутентификации. Аутентификация управляется клиентом : когда запрашивается пароль, это может быть запрос клиента SSH, а не сервера. Сервер просто отвечает на запросы аутентификации клиента. Широко используемые методы аутентификации пользователя включают в себя следующее:
    • пароль : метод прямой аутентификации по паролю, включая возможность изменения пароля. Не все программы реализуют этот метод.
    • publickey : метод аутентификации на основе открытого ключа , обычно поддерживающий как минимум пары ключей DSA , ECDSA или RSA , а также другие реализации, поддерживающие сертификаты X.509 .
    • keyboard-interactive ( RFC  4256): универсальный метод, при котором сервер отправляет одно или несколько приглашений для ввода информации, а клиент отображает их и отправляет обратно ответы, введенные пользователем. Используется для предоставления аутентификации с одноразовым паролем, например S/Key или SecurID . Используется некоторыми конфигурациями OpenSSH, когда PAM является базовым поставщиком аутентификации хоста для эффективного предоставления аутентификации с помощью пароля, что иногда приводит к невозможности входа с помощью клиента, который поддерживает только метод аутентификации с помощью простого пароля .
    • Методы аутентификации GSSAPI , которые предоставляют расширяемую схему для выполнения аутентификации SSH с использованием внешних механизмов, таких как Kerberos 5 или NTLM , обеспечивая возможность единого входа для сеансов SSH. Эти методы обычно реализуются коммерческими реализациями SSH для использования в организациях, хотя OpenSSH имеет работающую реализацию GSSAPI.
  • Уровень соединения ( RFC  4254) определяет концепцию каналов, запросов каналов и глобальных запросов, которые определяют предоставляемые службы SSH. Одно соединение SSH может быть мультиплексировано в несколько логических каналов одновременно, каждый из которых передает данные в двух направлениях. Запросы каналов используются для ретрансляции внеполосных данных, специфичных для канала, таких как измененный размер окна терминала или код выхода процесса на стороне сервера. Кроме того, каждый канал выполняет собственное управление потоком, используя размер окна приема. Клиент SSH запрашивает переадресацию порта на стороне сервера с помощью глобального запроса. Стандартные типы каналов включают:
    • оболочка для терминальных оболочек, SFTP и exec-запросов (включая передачи SCP)
    • direct-tcpip для перенаправления соединений клиент-сервер
    • forwarded-tcpip для перенаправленных соединений сервер-клиент
  • Запись DNS SSHFP (RFC 4255) предоставляет отпечатки открытого ключа хоста для проверки подлинности хоста.

Эта открытая архитектура обеспечивает значительную гибкость, позволяя использовать SSH для различных целей за пределами защищенной оболочки. Функциональность одного только транспортного уровня сопоставима с Transport Layer Security (TLS); уровень аутентификации пользователя легко расширяется с помощью настраиваемых методов аутентификации; а уровень соединения обеспечивает возможность мультиплексирования множества вторичных сеансов в одно соединение SSH, функция, сопоставимая с BEEP и недоступная в TLS.

Алгоритмы

Уязвимости

СШ-1

В 1998 году в SSH 1.5 была описана уязвимость, которая позволяла несанкционированную вставку контента в зашифрованный поток SSH из-за недостаточной защиты целостности данных от CRC-32, используемой в этой версии протокола. [42] [43] Исправление, известное как SSH Compensation Attack Detector [44], было введено в большинство реализаций. Многие из этих обновленных реализаций содержали новую уязвимость целочисленного переполнения [45], которая позволяла злоумышленникам выполнять произвольный код с привилегиями демона SSH, обычно root.

В январе 2001 года была обнаружена уязвимость, позволяющая злоумышленникам изменять последний блок сеанса, зашифрованного с помощью IDEA . [46] В том же месяце была обнаружена еще одна уязвимость, позволяющая вредоносному серверу пересылать аутентификацию клиента на другой сервер. [47]

Поскольку SSH-1 имеет присущие ему недостатки дизайна, которые делают его уязвимым, в настоящее время он, как правило, считается устаревшим и его следует избегать, явно отключая откат к SSH-1. [47] Большинство современных серверов и клиентов поддерживают SSH-2. [48]

Восстановление открытого текста CBC

В ноябре 2008 года была обнаружена теоретическая уязвимость для всех версий SSH, которая позволяла восстановить до 32 бит открытого текста из блока шифртекста, который был зашифрован с использованием стандартного режима шифрования по умолчанию CBC . [49] Наиболее простым решением является использование CTR , режима счетчика, вместо режима CBC, поскольку это делает SSH устойчивым к атакам. [49]

Подозреваемая расшифровка со стороны АНБ

28 декабря 2014 года Der Spiegel опубликовал секретную информацию [50], слитую осведомителем Эдвардом Сноуденом , которая предполагает, что Агентство национальной безопасности может быть способно расшифровать часть трафика SSH. Технические детали, связанные с таким процессом, не были раскрыты. Анализ хакерских инструментов ЦРУ BothanSpy и Gyrfalcon, проведенный в 2017 году, показал, что протокол SSH не был скомпрометирован. [51]

Атака черепахи

В 2023 году была обнаружена новая атака «man-in-the-middle» против большинства текущих реализаций ssh. Ее первооткрыватели назвали ее атакой Terrapin . [52] [53] Однако риск смягчается требованием перехвата подлинного сеанса ssh, а также тем, что атака ограничена в своих масштабах, что по счастливой случайности приводит в основном к сбоям соединений. [54] [55] Разработчики ssh заявили, что основным последствием атаки является ухудшение функций обфускации времени нажатия клавиш ssh. [55] Уязвимость была исправлена ​​в OpenSSH 9.6, но для полной эффективности исправления требуется обновление как клиента, так и сервера.

Стандарты документации

Следующие публикации RFC рабочей группы IETF «secsh» документируют SSH-2 как предлагаемый стандарт Интернета .

  • RFC  4250 – Назначенные номера протокола Secure Shell (SSH)
  • RFC  4251 – Архитектура протокола Secure Shell (SSH)
  • RFC  4252 – Протокол аутентификации Secure Shell (SSH)
  • RFC  4253 – Протокол транспортного уровня Secure Shell (SSH)
  • RFC  4254 – Протокол соединения Secure Shell (SSH)
  • RFC  4255 – Использование DNS для безопасной публикации отпечатков ключей Secure Shell (SSH)
  • RFC  4256 – Общая аутентификация обмена сообщениями для протокола Secure Shell (SSH)
  • RFC  4335 – Расширение прерывания сеанса канала Secure Shell (SSH)
  • RFC  4344 – Режимы шифрования транспортного уровня Secure Shell (SSH)
  • RFC  4345 – Улучшенные режимы Arcfour для протокола транспортного уровня Secure Shell (SSH)

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

  • RFC  4419 – Групповой обмен Диффи-Хеллмана для протокола транспортного уровня Secure Shell (SSH) (март 2006 г.)
  • RFC  4432 – Обмен ключами RSA для протокола транспортного уровня Secure Shell (SSH) (март 2006 г.)
  • RFC  4462 – Аутентификация и обмен ключами универсального интерфейса прикладного программирования служб безопасности (GSS-API) для протокола Secure Shell (SSH) (май 2006 г.)
  • RFC  4716 – Формат файла открытого ключа Secure Shell (SSH) (ноябрь 2006 г.)
  • RFC  4819 – Подсистема открытого ключа Secure Shell (март 2007 г.)
  • RFC  5647 – Режим счетчика Галуа AES для протокола транспортного уровня Secure Shell (август 2009 г.)
  • RFC  5656 – Интеграция алгоритма эллиптических кривых в транспортный уровень Secure Shell (декабрь 2009 г.)
  • RFC  6187 – Сертификаты X.509v3 для аутентификации Secure Shell (март 2011 г.)
  • RFC  6239 – Криптографические наборы Suite B для Secure Shell (SSH) (май 2011 г.)
  • RFC  6594 – Использование алгоритма SHA-256 с RSA, алгоритмом цифровой подписи (DSA) и DSA на основе эллиптических кривых (ECDSA) в записях ресурсов SSHFP (апрель 2012 г.)
  • RFC  6668 – Проверка целостности данных SHA-2 для протокола транспортного уровня Secure Shell (SSH) (июль 2012 г.)
  • RFC  7479 – Ed25519 Записи ресурсов SSHFP (март 2015 г.)
  • RFC  5592 – Модель безопасной оболочки для простого протокола управления сетью (SNMP) (июнь 2009 г.)
  • RFC  6242 – Использование протокола NETCONF через Secure Shell (SSH) (июнь 2011 г.)
  • RFC  8332 – Использование ключей RSA с SHA-256 и SHA-512 в протоколе Secure Shell (SSH) (март 2018 г.)
  • draft-gerhards-syslog-transport-ssh-00 – отображение транспорта SSH для SYSLOG (июль 2006 г.)
  • draft-ietf-secsh-filexfer-13 – Протокол передачи файлов SSH (июль 2006 г.)

Кроме того, проект OpenSSH включает несколько спецификаций/расширений протоколов поставщиков:

  • Обзор протокола OpenSSH
  • Обзор сертификата/ключа OpenSSH
  • draft-miller-ssh-agent-04 - Протокол агента SSH (декабрь 2019 г.)

Смотрите также

Ссылки

  1. ^ ab T. Ylonen; C. Lonvick (январь 2006 г.). Архитектура протокола Secure Shell (SSH). IETF Trust. doi : 10.17487/RFC4251 . RFC 4251.
  2. ^ «Миссурийский университет S&T: Безопасный Telnet».
  3. ^ abc T. Ylonen; C. Lonvick (январь 2006 г.). Протокол аутентификации Secure Shell (SSH). IETF Trust. doi : 10.17487/RFC4252 . RFC 4252.
  4. ^ "Как настроить авторизованные ключи". Архивировано из оригинала 2011-05-10.
  5. ^ Win-32 OpenSSH
  6. ^ "Домашняя страница WinSCP". Архивировано из оригинала 2014-02-17.
  7. ^ "Страница WinSCP для PortableApps.com". Архивировано из оригинала 2014-02-16.
  8. ^ "Страница PuTTY для PortableApps.com". Архивировано из оригинала 2014-02-16.
  9. ^ Эмис, А.; Ву, К. Ф.; Ван, Г. Ч.; Кривети, М. (2012). «Сети в облаке». IBM developerWorks . Архивировано из оригинала 14.06.2013.
  10. ^ «Реестр имен служб и номеров портов транспортных протоколов».
  11. ^ "Реестр имен служб и номеров портов транспортных протоколов". iana.org . Архивировано из оригинала 2001-06-04.
  12. ^ Seggelmann, R.; Tuxen, M.; Rathgeb, EP (18–20 июля 2012 г.). SSH через SCTP — Оптимизация многоканального протокола путем адаптации его к SCTP . 8-й Международный симпозиум по системам связи, сетям и цифровой обработке сигналов (CSNDSP). стр.  1– 6. doi :10.1109/CSNDSP.2012.6292659. ISBN 978-1-4577-1473-3. S2CID  8415240.
  13. ^ Тату Юлёнен. "Новый скелетный ключ: смена замков в вашей сетевой среде". Архивировано из оригинала 20-08-2017.
  14. ^ Тату Юлёнен. "SSH Port". Архивировано из оригинала 2017-08-03.
  15. ^ Илёнен, Тату. «История порта SSH — 22». www.ssh.com . Получено 30.11.2023 .
  16. ^ Барретт, Дэниел Дж.; Сильверман, Ричард Э. (2001). SSH, безопасная оболочка: полное руководство (1-е изд.). Кембридж [Массачусетс]: O'Reilly. стр. 11. ISBN 978-0-596-00011-0.
  17. ^ Николас Росаско и Дэвид Ларошель. «Как и почему более безопасные технологии добиваются успеха на устаревших рынках: уроки успеха SSH» (PDF) . Цитата из Барретта и Сильвермана, SSH, безопасная оболочка: полное руководство, O'Reilly & Associates (2001) . Кафедра компьютерных наук, Университет Вирджинии. Архивировано (PDF) из оригинала 25-06-2006 . Получено 19-05-2006 .
  18. ^ IETF (Internet Engineering Task Force): трекер данных для secsh
  19. ^ ab RFC4252: Протокол аутентификации Secure Shell (SSH), январь 2006 г.
  20. ^ О'Рейли: Secure Shell, Полное руководство
  21. ^ RFC4250: Протокол Secure Shell (SSH): Назначенные имена, январь 2006 г., стр. 16
  22. ^ "SSH Frequently Asked Questions". Архивировано из оригинала 2004-10-10.
  23. ^ "libssh".
  24. ^ "Реализация протоколов Secure Shell в GNU". Архивировано из оригинала 2012-02-04.
  25. ^ "Dropbear SSH". Архивировано из оригинала 2011-10-14.
  26. ^ Ylonen, T.; Lonvick, C. «Старый клиент, новый сервер». Протокол транспортного уровня Secure Shell (SSH). IETF. раздел 5.1. doi : 10.17487/RFC4253 . RFC 4253.
  27. ^ ssh-1.2.13 теперь доступен: политика копирования изменена (теперь требуется разрешение для коммерческой продажи ssh, использование по-прежнему разрешено для любых целей)
  28. ^ Источники OSSH
  29. ^ "OpenSSH: История проекта и кредиты". openssh.com. 2004-12-22. Архивировано из оригинала 2013-12-24 . Получено 2014-04-27 .
  30. ^ "OSSH Information for VU#419241". CERT Coordination Center . 2006-02-15. Архивировано из оригинала 2007-09-27. В любом случае ossh устарел и неактуален, и я не рекомендую его использовать.
  31. ^ "Удаленный терминал через соединения HTTP/3". datatracker.ietf.org . 2024-08-01.
  32. ^ «Безопасная оболочка через соединения HTTP/3». www.ietf.org . 2024-02-28.
  33. ^ «На пути к SSH3: как HTTP/3 улучшает защищенные оболочки». arxiv.org . 2023-12-12.
  34. ^ "ssh3". github.com . 12 июля 2024 г.
  35. ^ "Безопасная оболочка через соединения HTTP/3". datatracker.ietf.org . 2024-02-28.
  36. ^ Собелл, Марк (2012). Практическое руководство по командам, редакторам и программированию оболочки Linux (3-е изд.). Upper Saddle River, NJ: Prentice Hall. стр.  702–704 . ISBN 978-0133085044.
  37. ^ Харрис, Б.; Велвиндрон, Л. (февраль 2020 г.). Ed25519 и Ed448 Алгоритмы открытого ключа для протокола Secure Shell (SSH). doi : 10.17487/RFC8709 . RFC 8709.
  38. ^ ab Stebila, D.; Green, J. (декабрь 2009 г.). Интеграция алгоритма эллиптической кривой в транспортный уровень Secure Shell. doi : 10.17487/RFC5656 . RFC 5656 . Получено 12 ноября 2012 г. .
  39. ^ Миллер, Д.; Валчев, П. (3 сентября 2007 г.). Использование UMAC в протоколе транспортного уровня SSH. ID draft-miller-secsh-umac-00.
  40. ^ Илонен, Т.; Лонвик, К. Протокол транспортного уровня Secure Shell (SSH). IETF. doi : 10.17487/RFC4253 . RFC 4253.
  41. ^ Иго, К.; Солинас, Дж. (август 2009 г.). Режим счетчика Галуа AES для протокола транспортного уровня Secure Shell. doi : 10.17487/RFC5647 . RFC 5647.
  42. ^ "SSH Insertion Attack". Core Security Technologies . Архивировано из оригинала 2011-07-08.
  43. ^ "Заметка об уязвимости VU#13877 — Слабый CRC позволяет внедрять пакеты в сеансы SSH, зашифрованные блочными шифрами". US CERT . Архивировано из оригинала 2010-07-10.
  44. ^ "SSH CRC-32 Compensation Attack Detector Vulnerability". SecurityFocus . Архивировано из оригинала 2008-07-25.
  45. ^ "Заметка об уязвимости VU#945216 - Код обнаружения атаки SSH CRC32 содержит удаленное целочисленное переполнение". US CERT . Архивировано из оригинала 2005-10-13.
  46. ^ "Заметка об уязвимости VU#315308 — Слабый CRC позволяет изменять последний блок зашифрованного IDEA пакета SSH без уведомления". US CERT . Архивировано из оригинала 2010-07-11.
  47. ^ ab "Заметка об уязвимости VU#684820 - SSH-1 позволяет вредоносному серверу пересылать аутентификацию клиента на другой сервер". US CERT . Архивировано из оригинала 2009-09-01.
  48. ^ "Как использовать ключи SSH для аутентификации". Up Cloud . 17 сентября 2015 г. Получено 29 ноября 2019 г.
  49. ^ ab "Заметка об уязвимости VU#958563 - уязвимость SSH CBC". US CERT . Архивировано из оригинала 2011-06-22.
  50. ^ "Prying Eyes: Inside the NSA's War on Internet Security". Spiegel Online . 28 декабря 2014 г. Архивировано из оригинала 24 января 2015 г.
  51. ^ Ylonen, Tatu (3 августа 2017 г.). «BothanSpy & Gyrfalcon — Анализ инструментов взлома ЦРУ для SSH». ssh.com . Получено 15 июля 2018 г. .
  52. ^ "Terrapin Attack". terrapin-attack.com . Получено 20.12.2023 .
  53. ^ Джонс, Коннор. «SSH потрясен, но не взволнован уязвимостью понижения версии Terrapin». www.theregister.com . Получено 20.12.2023 .
  54. ^ Джонс, Коннор. «SSH потрясен, но не взволнован уязвимостью понижения версии Terrapin». www.theregister.com . Получено 20.12.2023 .
  55. ^ ab "Заметки о выпуске OpenSSH 9.6". openssh.com . 2023-12-18.

Дальнейшее чтение

  • Барретт, Дэниел Дж .; Сильверман, Ричард Э.; Бирнс, Роберт Г. (2005). SSH: The Secure Shell (The Definitive Guide) (2-е изд.). O'Reilly. ISBN 0-596-00895-3.
  • Станке, Майкл (2005). Про OpenSSH . Апресс. ISBN 1-59059-476-2.
  • Тату Юленен (12 июля 1995 г.). «Объявление: программа удаленного входа в систему Ssh (Secure Shell)» . комп.security.unix.Первоначальное объявление Ssh
  • Двиведи, Химансю (2003). Реализация SSH . Wiley. ISBN 978-0-471-45880-7.
На Викискладе есть медиафайлы по теме SSH .
В Wikibooks есть книга по теме: Интернет-технологии/SSH
  • SSH-протоколы
  • M. Joseph; J. Susoy (ноябрь 2013 г.). Подсистема открытых ключей Secure Shell P6R. doi : 10.17487/RFC7076 . RFC 7076.
  • Оригинальный исходный файл SSH tarball
Retrieved from "https://en.wikipedia.org/w/index.php?title=Secure_Shell&oldid=1273081877"