SSH

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

Secure Shell, SSH (англ. Secure SHell — «безпечна оболонка» [1]) — мережевий протокол рівня застосунків, що дозволяє проводити віддалене управління комп'ютером і тунелювання TCP-з'єднань (наприклад, для передачі файлів). Схожий за функціональністю з протоколом Telnet і rlogin, проте шифрує весь трафік, в тому числі і паролі, що передаються.

Криптографічний захист протоколу SSH не фіксований, можливий вибір різних алгоритмів шифрування. Клієнти і сервери, що підтримують цей протокол, доступні для різних платформ. Крім того, протокол дозволяє не тільки використовувати безпечний віддалений shell на машині, але і туннелювати графічний інтерфейс — X Tunnelling (тільки для Unix-подібних ОС або застосунків, що використовують графічний інтерфейс X Window System). Так само ssh здатний передавати через безпечний канал (Port Forwarding) будь-який інший мережевий протокол, забезпечуючи (при належній конфігурації) можливість безпечної пересилки не тільки X-інтерфейсу, але і, наприклад, звуку.

Підтримка SSH реалізована у всіх UNIX системах, і на більшості з них в числі стандартних утиліт присутні клієнт і сервер ssh. Існує безліч реалізацій SSH-клієнтів і для не-UNIX ОС. Велику популярність протокол отримав після широкого розвитку сніферів, як альтернативне небезпечному телнету рішення для управління важливими вузлами.

Більшість хостинг-провайдерів за певну плату надають клієнтам доступ до їх домашнього каталогу по SSH. Це може бути зручно як для роботи в командному рядку, так і для віддаленого запуску програм (у тому числі графічних додатків).

Зараз відомо дві гілки версій — 1 і 2. Проте гілка 1 зупинена, оскільки в кінці 90-х в ній було знайдено багато вразливостей, деякі з яких досі накладають серйозні обмеження на її використання, тому перспективною (такою, що розвивається) і найбезпечнішою є версія 2.

Стандарти та програмні реалізації[ред.ред. код]

Перша версія протоколу, SSH-1, була розроблена в 1995 році дослідником Тату Улененом з Технологічного університету Хельсінкі, Фінляндія. SSH-1 був написаний для забезпечення більшої конфіденційності, ніж протоколи rlogin, telnet і rsh. У 1996 році була розроблена безпечніша версія протоколу, SSH-2, несумісна з SSH-1. Протокол набув ще більшої популярності, і до 2000 року у нього було близько двох мільйонів користувачів. В даний час під терміном «SSH» зазвичай мається на увазі саме SSH-2, тому що перша версія протоколу огляду істотних недоліків зараз практично не застосовується.

У 2006 році протокол був затверджений робочою групою IETF в якості Інтернет-стандарту.

Проте, в деяких країнах (Франція, Росія, Ірак і Пакистан) до сих пір потрібен спеціальний дозвіл у відповідних структурах для використання певних методів шифрування, включаючи SSH. Див закон Російської Федерації «Про федеральних органах урядового зв'язку і інформації» (закон втратив силу з 1 липня 2003 року у зв'язку з прийняттям федерального закону від 30.06.2003 № 86-ФЗ).

Поширені дві реалізації SSH: пропріетарна комерційна та безкоштовна вільна. Вільна реалізація називається OpenSSH. До 2006 року 80% комп'ютерів мережі Інтернет використовувало саме OpenSSH. Пропріетарна реалізація розробляється організацією SSH Inc., Вона безкоштовна для некомерційного використання. Ці реалізації містять практично однаковий набір команд.

Протокол SSH-2, на відміну від протоколу telnet, стійкий до атак прослуховування трафіку («сніфінг»), але нестійкий до атак «людина посередині». Протокол SSH-2 також стійкий до атак шляхом приєднання посередині (англ. session hijacking) - неможливо включитися у вже встановлену сесію або перехопити її.

Для запобігання атак «людина посередині» при підключенні до хосту, ключ якого ще не відомий клієнту, клієнтське ПО показує користувачеві "зліпок ключа" (key fingerprint). Рекомендується ретельно перевіряти показуваний клієнтським ПО "зліпок ключа" (key fingerprint) зі зліпком ключа сервера, бажано отриманим по надійним каналах зв'язку або особисто.

Підтримка SSH реалізована у всіх UNIX-подібних системах, і на більшості з них в числі стандартних утиліт присутні клієнт і сервер ssh. Існує безліч реалізацій SSH-клієнтів і для не-UNIX ОС. Велику популярність протокол отримав після широкого розвитку аналізаторів трафіку і способів порушення роботи локальних мереж, як альтернативне небезпечному протоколу Telnet рішення для управління важливими вузлами.

Для роботи по SSH потрібен SSH-сервер і SSH-клієнт. Сервер прослуховує з'єднання від клієнтських машин і при встановленні зв'язку виробляє аутентифікацію, після чого починає обслуговування клієнта. Клієнт використовується для входу на віддалену машину і виконання команд.

Для з'єднання сервер і клієнт повинні створити пари ключів - відкритих і закритих - і обмінятися відкритими ключами. Зазвичай використовується також і пароль.

SSH-сервери[ред.ред. код]

BSD 
OpenSSH
Linux
dropbear, lsh-server, openssh-server, ssh
Windows
freeSSHd, copssh, WinSSHD, KpyM Telnet / SSH Server, MobaSSH, OpenSSH через Cygwin

SSH-клієнти і оболонки[ред.ред. код]

Рекомендації щодо безпеки використання SSH[ред.ред. код]

  • Заборона віддаленого root-доступу.
  • Заборона підключення з порожнім паролем або відключення входу по паролю.
  • Вибір нестандартного порту для SSH-сервера.
  • Використання довгих SSH2 RSA-ключів (2048 біт і більше). Системи шифрування на основі RSA вважаються надійними, якщо довжина ключа не менше 1024 біт.
  • Обмеження списку IP-адрес, з яких дозволений доступ (наприклад, настроюванням файервола).
  • Заборона доступу з деяких потенційно небезпечних адрес.
  • Відмова від використання поширених або широко відомих системних логінів для доступу по SSH.
  • Регулярний перегляд повідомлень про помилки аутентифікації.
  • Установка систем виявлення вторгнень (IDS - Intrusion Detection System).
  • Використання пасток, підроблюють SSH-сервіс (honeypots).

Приклади використання SSH[ред.ред. код]

Команда підключення до локального SSH-сервера з командного рядка GNU / Linux або FreeBSD для користувача pacify (сервер прослуховує нестандартний порт 30000):

$ ssh -p 30000 pacify@127.0.0.1

Генерація пари ключів (в UNIX-подібних ОС) здійснюється командою

$ ssh-keygen

Генерація пари SSH-2 RSA-ключів довжиною 4096 біта програмою puttygen під UNIX-подібними ОС:

$ puttygen -t rsa -b 4096 -o sample

Деякі клієнти, наприклад, PuTTY, мають і графічний інтерфейс користувача.

Для використання SSH в Python існують такі модулі, як python-paramiko і python-twisted-conch.


SSH-тунелювання[ред.ред. код]

SSH-тунель - це тунель, який створюється за допомогою SSH-з'єднання і використовується для шифрування тунельованих даних. Використовується для того, щоб убезпечити передачу даних в Інтернеті (аналогічне призначення має IPsec). Особливість полягає в тому, що незашифрований трафік-якого протоколу шифрується на одному кінці SSH-з'єднання і розшифровується на іншому.

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

  • Створенням Socks-проксі для програм, які не вміють працювати через SSH-тунель, але можуть працювати через Socks-проксі
  • Використанням додатків, які вміють працювати через SSH-тунель.
  • Створенням VPN-тунелю, підходить практично для будь-яких додатків.

Якщо програма працює з одним певним сервером, можна налаштувати SSH-клієнт таким чином, щоб він пропускав через SSH-тунель TCP-з'єднання, що приходять на певний TCP-порт машини, на якій запущений SSH-клієнт. Наприклад, клієнти Jabber підключаються по замовчуванню на порт 443. Тоді, щоб налаштувати підключення до сервера Jabber через SSH-тунель, SSH-клієнт налаштовується на перенаправлення підключень з будь-якого порту локальної машини (наприклад, з порту 4430) на віддалений сервер (наприклад, jabber.example.com і порт 443):

$ ssh -L 4430:jabber.example.com:443 somehost

В даному випадку Jabber-клієнт налаштовується на підключення до порту 4430 сервера localhost (якщо ssh-клієнт запущений на тій же машині що і Jabber-клієнт).

Для створення ssh-тунелю необхідна машина з запущеним ssh-сервером і доступом до jabber.example.com. Така конфігурація може використовуватися у випадку, якщо з локальної машини доступ до jabber.example.com закритий файерволом, але є доступ до деякого ssh-серверу, у якого обмеження доступу в Інтернет відсутні.

Технічна інформація про протокол[ред.ред. код]

SSH - це протокол сеансового рівня. SSH-сервер зазвичай прослуховує з'єднання на TCP-порту 22. Специфікація протоколу SSH-2 міститься в RFC 4251. Для аутентифікації сервера в SSH використовується протокол аутентифікації сторін на основі алгоритмів електронно-цифрового підпису RSA або DSA. Для аутентифікації клієнта також може використовуватися ЕЦП RSA або DSA, але допускається також аутентифікація за допомогою пароля (режим зворотної сумісності з Telnet) і навіть ip-адреси хоста (режим зворотної сумісності з rlogin). Аутентифікація за паролем найбільш поширена, вона безпечна, тому що пароль передається по зашифрованому віртуального каналу. Аутентифікація по ip-адресою небезпечна, цю можливість найчастіше відключають. Для створення спільного секрету (сеансового ключа) використовується алгоритм Діффі - Хеллмана (DH). Для шифрування переданих даних використовується симетричне шифрування, алгоритми AES, Blowfish або 3DES. Цілісність переданих даних перевіряється за допомогою CRC32 в SSH1 або HMAC-SHA1/HMAC-MD5 в SSH2.

Для стиснення шифруючих даних може використовуватися алгоритм LempelZiv (LZ77), який забезпечує такий же рівень стиснення, що і архіватор ZIP. Стиснення SSH включається лише за запитом клієнта, і на практиці використовується рідко. [Правити] Див також b: Захист конфіденційних даних і анонімність в інтернеті в Вікіпідручник?

   SFTP
   SCP
   SSL
   TLS


Стандарти

   RFC 4250 (англ.) - The Secure Shell (SSH) Protocol Assigned Numbers
   RFC 4251 (англ.) - The Secure Shell (SSH) Protocol Architecture
   RFC 4252 (англ.) - The Secure Shell (SSH) Authentication Protocol
   RFC 4253 (англ.) - The Secure Shell (SSH) Transport Layer Protocol
   RFC 4254 (англ.) - The Secure Shell (SSH) Connection Protocol
   RFC 4255 (англ.) - Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
   RFC 4256 (англ.) - Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
   RFC 4335 (англ.) - The Secure Shell (SSH) Session Channel Break Extension
   RFC 4344 (англ.) - The Secure Shell (SSH) Transport Layer Encryption Modes
   RFC 4345 (англ.) - Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol
   RFC 4419 (англ.) - Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
   RFC 4432 (англ.) - RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
   RFC 4716 (англ.) - The Secure Shell (SSH) Public Key File Format

SSH-клієнти

   OpenSSH - вільна бібліотека і набір утиліт для шифрування
   PuTTY - популярний багатоплатформовий SSH-клієнт
   Порівняння SSH-клієнтів (англ.)
   MidpSSH (англ.) - SSH-клієнт для мобільних телефонів

Програми доступу до файлів

   FTP Commander Deluxe - популярна програма підтримує всі безпечні протоколи
   WinSCP - SFTP-клієнт для Microsoft Windows
   SftpDrive - SFTP-клієнт для Microsoft Windows
   SSH Filesystem - дозволяє підключити директорію, доступну на віддаленій машині по ssh, як локальну директорію в GNU / Linux 

Історія розвитоку[ред.ред. код]

SSH зазвичай використовується для входу на віддалену машину і виконувати команди, але він також підтримує тунельний протокол, портове експедирування TCP і UDP порт | TCP порти. він може передавати файли за допомогою відповідних SSH File Transfer Protocol | SSH File Transfer (SFTP) або Secure Copy (SCP) протоколів SSH використовує клієнт-сервер модель.

SSH програма зазвичай використовується для встановлення з'єднання з ухвалення віддалених підключень. І те й інше зазвичай присутнє на більшості сучасних операційні системи, включаючи Mac OS, більшість розподілів GNU / Linux, OpenBSD, FreeBSD, [[NetBSD] ], Solaris і OpenVMS. Відомо, що Windows є одним з небагатьох сучасних / серверних операційних систем, які не включають SSH за замовчуванням.

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

Версія 1.x[ред.ред. код]

У 1995 році Tatu Ylonen, дослідник Гельсінського технологічного університету, (Фінляндія), розробив першу версію протоколу (зараз він називається 'SSH-1'). Мета SSH повинен був замінити раніші Rlogin, TELNET і RSH протоколи, які не забезпечують надійну аутентифікацію, і не гарантують конфіденційність. Ylonen випустив свій протокол безкоштовно в липні 1995 року, і інструмент швидко завоював популярність. До кінця 1995 року база SSH користувачів виросло до 20.000 користувачів в п'ятдесяти країнах.

У грудні 1995 року заснував Ylonen SSH Communications Security. Оригінальна версія програмного забезпечення SSH використовували різні частини вільне програмне забезпечення, наприклад, GNU libgmp, але більш пізні версії випущена SSH Secure Communications перетворилася в більш пропрієтарне програмне забезпечення .

Вважається, що, Шаблон:Станом, було 2 мільйони користувачів SSH [3]

Відомі вразливості[ред.ред. код]

У 1998 році вразливість була описана в SSH 1.5, що дозволяло несанкціонованого вставки контенту в зашифрованому потоці SSH через недостатню цілісності даних захист від CRC-32 використовується в даній версії протоколу. [4][5].

У січні 2001 року була виявлена ​​уразливість, яка дозволяє зловмисникові змінювати останній блок IDEA. Зашифровані сесії [6] У тому ж місяці, інша уразливість була виявлена, що дозволяло шкідлививому серверу пересилання аутентифікації клієнта на інший сервер. [7]

Так як SSH-1 притаманні недоліки дизайну, які роблять його вразливим, в даний час він вважається застарілим і його слід уникати, відключивши повернення до SSH-1. Більшість сучасних серверів і клієнтів підтримують SSH-2.

Версія 1.99[ред.ред. код]

У січні 2006 року, після версії 2.1 був створений, RFC 4253, що означало, що сервер SSH, який підтримує як 2.0 так і попередні версії SSH повинні визначити свої версії як 1,99. [8] Це не фактичні версії, але метод ідентифікації зворотна сумісність.

OpenSSH і OSSH[ред.ред. код]

У 1999 році розробники, бажали повернутися до старої 1.2.12 релізовуючи оригінальну SSH програму, яка була останньою випущена під з відкритим вихідним кодом ліцензію. OSSH Björn Grönvall згодом почав розвиватися з цього коду.

Версія 2.x[ред.ред. код]

"Secsh" була офіційним [[Internet Engineering Task Force |] Internet Engineering Task Force автора]. (IETF) ім'я IETF робочої групи, відповідальної за версію 2 протоколу SSH [9] У 2006 році переглянуто версії протоколу, 'SSH-2' був прийнятий як стандарт. Ця версія несумісна з SSH-1. SSH-2 є функціями безпеки, так і функцією поліпшення в порівнянні з SSH-1. Краще безпеки, наприклад, приходить через Діффі-Хеллмана і сильне цілісності перевірка за допомогою Message Authentication Code с. Нові можливості SSH-2 включають в себе можливість запускати будь-яку кількість оболонкою. сесій по одному SSH з'єднанні. [10]

Вразливості[ред.ред. код]

У листопаді 2008 року теоретичну вразливість була виявлена ​​для всіх версій SSH, який дозволив відновлення до 32 біт відкритого тексту з блоку зашифрованого тексту, зашифрованого за допомогою тодішнього стандартного режиму шифрування за умовчанням [11].

Пізніше протокол SSH був змінений і розширений в наступних публікаціях.

  • RFC 4419, Діффі-Хеллмана Група обмін на Secure Shell (SSH) Transport Layer Protocol (березень 2006 р.)
  • RFC 4432, RSA Key Exchange для Secure Shell (SSH) Transport Layer Protocol (березень 2006 р.)
  • RFC 4462, Generic Security Service Application Program Interface (GSS-API) аутентифікації і обміну ключами для Secure Shell (SSH) Protocol (травень 2006 р.)
  • RFC 4716, Secure Shell (SSH) Public Key Формат файлу (листопад 2006)
  • RFC 5656, Еліптичні алгоритм інтегрування кривій в безпеці транспортного рівня Shell (грудень 2009 року)

Використання[ред.ред. код]

Example of tunneling an X11 application over SSH: the user 'josh' has SSHed from the local machine 'foofighter' to the remote machine 'tengwar' to run xeyes.
Logging into OpenWrt via SSH using PuTTY running on Windows.

SSH це протокол, який може бути використаний для багатьох додатків на різних платформах, включаючи самі Unix варіантів (Linux, BSD автора, включаючи від Apple OS X, і Solaris), а також Microsoft Windows. Деякі програми можуть зажадати нижче функції, які доступні тільки або сумісним з конкретними клієнтами SSH або серверів. Наприклад, з використанням протоколу SSH для реалізації VPN можна, але в даний час тільки з OpenSSH сервер і клієнт реалізації.

  • Для входу в оболонку на віддаленому хості (заміна Telnet і Rlogin)
  • Для виконання однієї команди на віддаленому хості (заміна RSH)
  • Безпечна передача файлів
  • У поєднанні з Rsync для резервного копіювання, скопіюйте та дзеркала файлів ефективно і безпечно
  • Для експедирування, доставка або тунельні порт (не плутати з VPN, які маршрутів пакети між різними мережами, або мости два широкомовний домен и в один).
  • Для використання в якості повноцінного зашифровані VPN. Зверніть увагу, що тільки OpenSSH сервер і клієнт підтримує цю функцію.
  • Для переадресації X з віддаленого хости (можливо через кілька проміжних хазяїв)
  • Для перегляду веб-сторінок через шифроване з'єднання з проксі SSH клієнти, які підтримують SOCKS протокол.
  • Для безпечного монтажу каталогу на віддаленому сервері [Файлова система [| файлова система]] на локальному комп'ютері за допомогою SSHFS.
  • Для автоматизованого дистанційного моніторингу та управління серверами через одну або більше механізмів, описаних вище.
  • Для розвитку на мобільні або вбудовані пристрої, які підтримують SSH.

Передача файлів з використанням SSH[ред.ред. код]

Є кілька механізмів передачі файлів за допомогою захищених протоколів Shell.

Архітектура[ред.ред. код]

Diagram of the SSH-2 binary packet.

SSH-2 протоколу має внутрішню архітектуру (визначено в RFC 4251) з чітко розділеними шарами. До них відносяться:

  • Транспортний шар (RFC 4253). Цей шар обробляє початковий обмін ключами, а також перевірки дійсності сервера і встановлює шифрування, стиснення і перевірку цілісності даних. Він надає у верхній шар інтерфейс для відправки та отримання тексту пакету з розміром до 32768 байт кожен (більше може бути вирішений шляхом реалізації). Транспортний рівень також організує ключові повторного обміну, як правило, після 1 Гб даних були передані або через 1 годину пройшов, що настане першим.
  • Шару автентичного користувача (RFC 4252). Цей шар обробляє перевірку автентичності клієнта і надає ряд методів аутентифікації. Перевірка справжності клієнт-орієнтованих: коли один запит на введення пароля, це може бути SSH клієнта запиту, а не на сервері. Сервер просто реагує на аутентифікацію клієнта запити. Широко використовуються методи аутентифікації користувачів, включають наступне:
    • Пароль: Метод простий пароль аутентифікації, в тому числі засіб, що дозволяє пароль, щоб бути змінені. Цей метод не реалізований всіма програмами.
    • з відкритим ключем: метод відкритого ключа перевірки автентичності на основі, як правило, підтримують принаймні, DSA або RSA пари ключів, з іншими реалізаціями також підтримує X.509 сертифікати.
    • Інтерактивний (RFC 4256): універсальний метод, коли сервер відправляє один або декілька запитів вводу інформації і клієнт відображає їх і відправляє назад відповідь введені в користувачем. Використовується для забезпечення одноразовий пароль аутентифікації, такі як S / Key або SecurID. Використовується деяких конфігураціях OpenSSH, коли PAM є основним постачальником хост аутентифікації для забезпечення ефективної аутентифікації по паролю, що іноді призводить до нездатності увійти в систему з клієнтом, який підтримує тільки прості пароль метод перевірки автентичності.
    • GSSAPI методи аутентифікації, які забезпечують розширюваної схеми для виконання SSH аутентифікації з використанням зовнішніх механізмів, таких як Kerberos 5 або NTLM, забезпечуючи [ [Single Sign On]] Можливість SSH сесій. Ці методи, як правило, здійснюються комерційними реалізаціями SSH для використання в організаціях, хоча OpenSSH дійсно є робоча реалізації GSSAPI.
  • Сполуки шарів (RFC 4254). Цей шар визначає поняття канали, канал запити і глобальний запитів за допомогою якої SSH послуги. Одне з'єднання SSH можна розмістити кілька каналів одночасно, кожна передача даних в обох напрямках. Канал запити використовуються для релейний вихід за смугу каналу конкретні дані, такі, як змінився розмір вікна термінала або код виходу з серверного процесу. SSH клієнт запитує сервер на стороні порту, який направлятиметься з використанням глобальної запитом. Стандартні типи каналів включають в себе:
    • Оболонка для терміналу, SFTP і Exec запитів (у тому числі SCP трансфертів)
    • Прямий TCP/IP для клієнт-сервер передаються з'єднання
    • Спрямований-TCP/IP для сервер-клієнт направляється з'єднань
  • SSHFP DNS-запис (RFC 4255) надає громадськості відбитки пальців ключа хоста для того, щоб допомогти в перевірці достовірності господаря.

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

Поліпшення[ред.ред. код]

Вони призначені для підвищення продуктивності продуктів SSH:

  • SSH-over-SCTP: підтримка SCTP, а не TCP, як зв'язок орієнтований протокол транспортного рівня [12]
  • ECDSA: підтримка еліптичної кривої DSA, а не DSA або RSA для підписання [13]
  • ECDH: підтримка для еліптичних кривих Діффі-Хеллмана, а не просто Діффі-Хеллмана для шифрування обміну ключами. [13]
  • UMAC: підтримка UMAC, а не HMAC для MAC / цілісності [14]

Див. також[ред.ред. код]

Література[ред.ред. код]

  1. Amies A, Wu C F, Wang G C, Criveti M (2012). Networking on the cloud IBM developerWorks, June 21.
  2. Amies A, Wu C F, Wang G C, Criveti M (2012). Networking on the cloud IBM developerWorks, June 21.
  3. Nicholas Rosasco and David Larochelle. «How and Why More Secure Technologies Succeed in Legacy Markets: Lessons from the Success of SSH». Quoting Barrett and Silverman, SSH, the Secure Shell: The Definitive Guide, O'Reilly & Associates (2001). Dept. of Computer Science, Univ. of Virginia. Архів оригіналу за 2013-06-25. Процитовано 2006-05-19. 
  4. SSH Insertion Attack
  5. Weak CRC allows packet injection into SSH sessions encrypted with block ciphers, US-CERT
  6. Weak CRC allows last block of IDEA-encrypted SSH packet to be changed without notice, US-CERT
  7. SSH-1 allows client authentication to be forwarded by a malicious server to another server, US-CERT
  8. RFC 4253, section 5. Compatibility With Old SSH Versions, IETF
  9. Secsh Protocol Documents, VanDyke Software, Inc.
  10. SSH Frequently Asked Questions
  11. SSH CBC vulnerability, US-CERT
  12. Seggelmann R., Tuxen, M.; Rathgeb, E.P. SSH over SCTP — Optimizing a multi-channel protocol by adapting it to SCTP // Communication Systems, Networks & Digital Signal Processing (CSNDSP), 2012 8th International Symposium on. — (18–20 July 2012) С. 1–6. DOI:10.1109/CSNDSP.2012.6292659.
  13. а б Stebila D., Green J. RFC5656 - Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer (December 2009). Процитовано 12 November 2012.
  14. Miller D., Valchev, P. The use of UMAC in the SSH Transport Layer Protocol / draft-miller-secsh-umac-00.txt (September 3, 2007). Процитовано 12 November 2012.

Посилання[ред.ред. код]

Шаблон:URI схеми

Див. також[ред.ред. код]