Ssh (безопасная оболочка) - Ssh (Secure Shell)

"SSH" перенаправляется сюда. Для использования в других целях см. SSH (значения).
Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

SSH или же Безопасная оболочка это криптографический сетевой протокол для безопасного управления сетевыми службами через незащищенную сеть.[1] Типичные приложения включают удаленное командная строка, авторизоваться, и удаленное выполнение команд, но любое сетевая служба можно защитить с помощью SSH.

SSH предоставляет безопасный канал по незащищенной сети с помощью клиент – сервер архитектура, соединяющая Клиент SSH приложение с SSH сервер.[2] В спецификации протокола различаются две основные версии, называемые SSH-1 и SSH-2. Стандарт Порт TCP для SSH - 22. SSH обычно используется для доступа Unix-подобный операционных систем, но его также можно использовать на Майкрософт Виндоус. Windows 10 использует OpenSSH по умолчанию Клиент SSH и SSH сервер.[3]

Несмотря на распространенное заблуждение, SSH не является реализацией Telnet с криптографией, предоставленной Уровень защищенных сокетов (SSL).

SSH был разработан как замена Telnet и для необеспеченный удаленный ракушка протоколы, такие как Беркли rsh и связанные rlogin и Rexec протоколы. Эти протоколы отправляют информацию, в частности пароли, в простой текст, делая их уязвимыми для перехвата и раскрытия с помощью анализ пакетов.[4] В шифрование используемый SSH, предназначен для обеспечения конфиденциальности и целостности данных в незащищенной сети, такой как Интернет.

Определение

SSH использует криптография с открытым ключом к аутентифицировать удаленного компьютера и при необходимости разрешите ему аутентифицировать пользователя.[2] Есть несколько способов использовать SSH; один из них - использовать автоматически сгенерированные пары открытого и закрытого ключей, чтобы просто зашифровать сетевое соединение, а затем использовать пароль аутентификация для входа в систему.

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

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

На Unix-подобный В системах список разрешенных открытых ключей обычно хранится в домашнем каталоге пользователя, которому разрешен удаленный вход, в файле ~ / .ssh / authorized_keys.[5] Этот файл поддерживается SSH только в том случае, если он не доступен для записи никому, кроме владельца и root. Когда открытый ключ присутствует на удаленном конце, а соответствующий закрытый ключ присутствует на локальном конце, ввод пароля больше не требуется. Однако для дополнительной безопасности сам закрытый ключ может быть заблокирован парольной фразой.

Секретный ключ также можно искать в стандартных местах, а полный путь к нему можно указать в параметрах командной строки (опция -я для ssh). В ssh-keygen Утилита создает открытый и закрытый ключи, всегда попарно.

SSH также поддерживает аутентификацию на основе пароля, которая шифруется автоматически сгенерированными ключами. В этом случае злоумышленник может имитировать легитимную часть сервера, запросить пароль и получить его (атака "человек посередине" ). Однако это возможно только в том случае, если обе стороны никогда раньше не аутентифицировались, поскольку SSH запоминает ключ, который ранее использовала сторона сервера. Клиент SSH выдает предупреждение перед принятием ключа нового, ранее неизвестного сервера. Парольную аутентификацию можно отключить.

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

SSH обычно используется для входа на удаленный компьютер и выполнения команд, но он также поддерживает туннелирование, пересылка TCP порты и X11 соединения; он может передавать файлы, используя связанный Передача файлов SSH (SFTP) или защищенная копия (SCP) протоколы.[2] SSH использует клиент-сервер модель.

SSH клиент программа обычно используется для установления соединений с SSH демон прием удаленных подключений. Оба обычно присутствуют на большинстве современных операционные системы, включая macOS, большинство дистрибутивов Linux, OpenBSD, FreeBSD, NetBSD, Солярис и OpenVMS. В частности, версии Windows до Windows 10 версии 1709 не включают SSH по умолчанию. Проприетарный, бесплатное ПО и Открытый исходный код (например. PuTTY,[6] и версия OpenSSH который является частью Cygwin[7]) существуют варианты разного уровня сложности и полноты. Файловые менеджеры для UNIX-подобных систем (например, Konqueror ) можно использовать РЫБЫ протокол для предоставления графического интерфейса с разделенной панелью с перетаскиванием. Программа для Windows с открытым исходным кодом WinSCP[8] предоставляет аналогичные возможности управления файлами (синхронизация, копирование, удаленное удаление) с использованием PuTTY в качестве серверной части. Оба WinSCP[9] и PuTTY[10] доступны в упаковке для запуска непосредственно с USB-накопителя без необходимости установки на клиентском компьютере. Настройка SSH-сервера в Windows обычно включает включение функции в приложении «Настройки». В Windows 10 версии 1709 доступен официальный порт OpenSSH для Win32.

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

В IANA назначил TCP порт 22, UDP порт 22 и SCTP порт 22 для этого протокола.[12] IANA указала стандартный TCP-порт 22 для серверов SSH как один из известные порты еще в 2001 году.[13] SSH также можно запустить с помощью SCTP а не TCP в качестве протокола транспортного уровня, ориентированного на соединение.[14]

История и развитие

Версия 1.x

В 1995 г. Тату Юлёнен, научный сотрудник Хельсинкский технологический университет, Финляндия, разработала первую версию протокола (теперь называется СШ-1) запрашивается пароль -нюхать атаковать его сеть университетов.[15] Целью SSH было заменить предыдущие rlogin, ТЕЛНЕТ, FTP[16] и rsh протоколы, которые не обеспечивали строгую аутентификацию и не гарантировали конфиденциальность. Илонен выпустил свою реализацию как бесплатное ПО в июле 1995 года, и инструмент быстро завоевал популярность. К концу 1995 года база пользователей SSH выросла до 20 000 пользователей в пятидесяти странах.

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

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

Версия 2.x

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

Версия 1.99

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

OpenSSH и OSSH

В 1999 году разработчики, желая, чтобы была доступна бесплатная версия программного обеспечения, вернулись к старому выпуску 1.2.12 исходной программы SSH, который был последним выпущенным под лицензией. лицензия с открытым исходным кодом. OSSH Бьёрна Грёнвалля был впоследствии разработан на основе этой кодовой базы. Вскоре после этого, OpenBSD Разработчики раздвоенный Код Грёнвалля и провел большую работу над ним, создав OpenSSH, который поставлялся с версией OpenBSD 2.6. Начиная с этой версии была сформирована ветвь «переносимости» для переноса OpenSSH на другие операционные системы.[24]

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

Использует

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

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

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

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

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

Архитектура

Схема бинарного пакета SSH-2.

Протокол SSH-2 имеет внутреннюю архитектуру (определенную в RFC 4251 ) с хорошо разделенными слоями, а именно:

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

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

Алгоритмы

Уязвимости

СШ-1

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

В январе 2001 года была обнаружена уязвимость, позволяющая злоумышленникам изменять последний блок ИДЕЯ -зашифрованная сессия.[36] В том же месяце была обнаружена еще одна уязвимость, позволяющая вредоносному серверу перенаправить аутентификацию клиента на другой сервер.[37]

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

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

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

Возможные уязвимости

28 декабря 2014 г. Der Spiegel опубликованная секретная информация[40] утечка разоблачителем Эдвард Сноуден что предполагает, что Национальное Агенство Безопасности может расшифровать некоторый трафик SSH. Технические детали, связанные с таким процессом, не разглашаются.

Анализ инструментов взлома BothanSpy и Gyrfalcon в 2017 году показал, что сам протокол SSH не был взломан.[41]

Документация по стандартам

Следующее RFC публикации IETF "секш" рабочая группа документ 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 - Diffie-Hellman Group Exchange для протокола транспортного уровня Secure Shell (SSH) (март 2006 г.)
  • RFC 4432 - Обмен ключами RSA для протокола транспортного уровня Secure Shell (SSH) (март 2006 г.)
  • RFC 4462 - Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol (май 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 г.)
  • draft-gerhards-syslog-transport-ssh-00 - отображение транспорта SSH для SYSLOG (июль 2006 г.)
  • draft-ietf-secsh-filexfer-13 - протокол передачи файлов SSH (июль 2006 г.)

В дополнение OpenSSH Проект включает в себя несколько спецификаций / расширений протокола поставщика:

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

Рекомендации

  1. ^ Т. Илонен; К. Лонвик (январь 2006 г.). Архитектура протокола Secure Shell (SSH). Сетевая рабочая группа IETF. Дои:10.17487 / RFC4251. RFC 4251.
  2. ^ а б c Сетевая рабочая группа IETF, январь 2006 г., RFC 4252, Протокол аутентификации Secure Shell (SSH)
  3. ^ «OpenSSH в Windows». Документы Microsoft. 7 января 2019.
  4. ^ «SSH укрепляет безопасную оболочку». Serverwatch.com. В архиве из оригинала от 23 декабря 2008 г.
  5. ^ «Как настроить авторизованные ключи». В архиве из оригинала от 10.05.2011.
  6. ^ «Загрузите PuTTY - бесплатный клиент SSH и telnet для Windows». Putty.org. В архиве из оригинала 27.05.2014. Получено 2014-04-28.
  7. ^ "Список пакетов Cygwin". Получено 5 января, 2016.
  8. ^ "Домашняя страница WinSCP". В архиве из оригинала от 17.02.2014.
  9. ^ "Страница WinSCP для PortableApps.com". В архиве из оригинала от 16.02.2014.
  10. ^ "Страница PuTTY для PortableApps.com". В архиве из оригинала от 16.02.2014.
  11. ^ Эмис, А; Wu, C F; Wang, G C; Кривети, М (2012). «Сеть в облаке». IBM developerWorks. В архиве из оригинала от 14.06.2013.
  12. ^ «Реестр имени службы и номера порта транспортного протокола».
  13. ^ «Реестр имени службы и номера порта транспортного протокола». iana.org. В архиве из оригинала от 04.06.2001.
  14. ^ Seggelmann, R .; Tuxen, M .; Ратгеб, Э. (18–20 июля 2012 г.). «SSH поверх SCTP - Оптимизация многоканального протокола путем его адаптации к SCTP». Системы связи, сети и цифровая обработка сигналов (CSNDSP), 8-й Международный симпозиум 2012 г.: 1–6. Дои:10.1109 / CSNDSP.2012.6292659. ISBN  978-1-4577-1473-3. S2CID  8415240.
  15. ^ Тату Юлёнен. «Новый каркасный ключ: изменение замков в вашей сетевой среде». В архиве из оригинала от 20.08.2017.
  16. ^ Тату Юлёнен. "Порт SSH". В архиве из оригинала от 03.08.2017.
  17. ^ Николас Росаско и Дэвид Ларошель. «Как и почему более безопасные технологии достигают успеха на устаревших рынках: уроки успеха SSH» (PDF). Цитирование Барретт и Сильверман, SSH, Secure Shell: The Definitive Guide, O'Reilly & Associates (2001).. Кафедра компьютерных наук, Univ. Вирджинии. В архиве (PDF) из оригинала от 25.06.2006. Получено 2006-05-19.
  18. ^ «Документы протокола Secsh». VanDyke Software, Inc. В архиве из оригинала от 13 января 2010 г.
  19. ^ «Часто задаваемые вопросы по SSH». В архиве с оригинала от 10.10.2004.
  20. ^ "libssh".
  21. ^ «Реализация протоколов Secure Shell GNU». В архиве из оригинала от 04.02.2012.
  22. ^ "Dropbear SSH". В архиве из оригинала от 14.10.2011.
  23. ^ "RFC 4253". Раздел 5. Совместимость со старыми версиями SSH. В архиве из оригинала от 04.07.2010., IETF
  24. ^ «OpenSSH: история проекта и кредиты». openssh.com. 2004-12-22. В архиве из оригинала от 24.12.2013. Получено 2014-04-27.
  25. ^ «Информация ОСШ для БУ №419241». В архиве из оригинала от 27.09.2007.
  26. ^ Собелл, Марк (2012). Практическое руководство по командам Linux, редакторам и программированию оболочки (3-е изд.). Река Аппер Сэдл, Нью-Джерси: Prentice Hall. С. 702–704. ISBN  978-0133085044.
  27. ^ RFC 8709
  28. ^ а б Стебила, Д .; Грин Дж. (Декабрь 2009 г.). «RFC5656 - Интеграция алгоритма эллиптической кривой на транспортном уровне защищенной оболочки». В архиве из оригинала 19 июля 2012 г.. Получено 12 ноября 2012. Цитировать журнал требует | журнал = (помощь)
  29. ^ Miller, D .; Валчев П. (3 сентября 2007 г.). «Использование UMAC в протоколе транспортного уровня SSH / draft-miller-secsh-umac-00.txt». В архиве из оригинала 19 августа 2014 г.. Получено 12 ноября 2012. Цитировать журнал требует | журнал = (помощь)
  30. ^ RFC 4253
  31. ^ RFC 5647
  32. ^ "Атака вставкой SSH". Основные технологии безопасности. В архиве из оригинала от 08.07.2011.
  33. ^ «Примечание об уязвимости VU № 13877 - слабый CRC позволяет вставлять пакеты в сеансы SSH, зашифрованные с помощью блочных шифров». США CERT. В архиве из оригинала 10.07.2010.
  34. ^ "Уязвимость детектора атаки компенсации SSH CRC-32". Безопасность. В архиве из оригинала от 25.07.2008.
  35. ^ «Примечание об уязвимости VU № 945216 - код обнаружения атаки SSH CRC32 содержит удаленное целочисленное переполнение». США CERT. В архиве из оригинала от 13.10.2005.
  36. ^ «Примечание об уязвимости VU № 315308 - Слабый CRC позволяет изменить последний блок зашифрованного IDEA пакета SSH без уведомления». США CERT. В архиве из оригинала от 11.07.2010.
  37. ^ а б «Примечание об уязвимости VU # 684820 - SSH-1 позволяет злоумышленнику перенаправить аутентификацию клиента на другой сервер». США CERT. В архиве из оригинала от 01.09.2009.
  38. ^ «Как использовать ключи SSH для аутентификации». Вверх по облаку. Получено 29 ноябрь 2019.
  39. ^ а б «Примечание об уязвимости VU № 958563 - уязвимость SSH CBC». США CERT. В архиве из оригинала от 22.06.2011.
  40. ^ «Любопытные глаза: изнутри войны АНБ с интернет-безопасностью». Spiegel Online. 28 декабря 2014 г. В архиве с оригинала от 24 января 2015 г.
  41. ^ Тату Илонен. "BothanSpy & Gyrfalcon - Анализ хакерских инструментов ЦРУ для SSH ", ssh.com, 3 августа 2017 г. Дата обращения 15 июля 2018 г.

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

внешняя ссылка