SSH

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

Модель TCP/IP (RFC 1122)
Прикладний рівень
Транспортний рівень
Мережевий рівень
Канальний рівень

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

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

Зараз відомо дві гілки версій — 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-клієнт. Сервер прослуховує з'єднання від клієнтських машин і при встановленні зв'язку виробляє аутентифікацію, після чого починає обслуговування клієнта. Клієнт використовується для входу на віддалену машину і виконання команд.

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

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

Клієнти та оболонки

Використання
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.

  • Secure Copy (SCP), який відбувся від RCP Протокол по SSH
  • Rsync, повинен бути більш ефективним, ніж SCP
  • SSH File Transfer Protocol (SFTP), безпечна альтернатива FTP (не плутати з FTP через SSH)
  • Файли передаються по протоколу оболонки (так званий FISH), випущений в 1998 році, який перетворився з Unix Shell команди через 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:

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

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 включається лише за запитом клієнта, і на практиці використовується рідко.

Історія розвитку

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 може забезпечити безпечний шлях через Інтернет, через брандмауер на віртуальній машині.[1]

Версія 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[2]

Відомі вразливості

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

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

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

Версія 1.99

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

OpenSSH і OSSH

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

Версія 2.x

«Secsh» була офіційним ім'ям робочої групи IETF, відповідальної за версію 2 протоколу SSH[8]. У 2006 році переглянуто версії протоколу і SSH-2 був прийнятий як стандарт. Ця версія несумісна з SSH-1. SSH-2 порівняно з SSH-1 має кращі функції безпеки, так і інші поліпшення. Краща захищеність, проявляється у використанні протоколу Діффі-Геллмана і сильнішій цілісності, коли перевірка відбувається за допомогою MAC-підписів. Нові можливості SSH-2 передбачають можливість запускати будь-яку кількість оболонок сесій на одному SSH з'єднанні[9]. Через переваги SSH-2 над SSH-1 та більшу популярність, такі реалізації SSH-2 як libssh (v0.8.0+),[10] Lsh[11] and Dropbear[12] підтримують тільки протокол SSH-2.

Вразливості

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

Пізніше протокол 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 року)

Архітектура
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, як зв'язок орієнтований протокол транспортного рівня[14]
  • ECDSA: підтримка еліптичної кривої DSA, а не DSA або RSA для підписання[15]
  • ECDH: підтримка для еліптичних кривих Діффі-Хеллмана, а не просто Діффі-Хеллмана для шифрування обміну ключами.[15]
  • UMAC: підтримка UMAC, а не HMAC для MAC / цілісності[16]

Примітки
  1. Amies A, Wu C F, Wang G C, Criveti M (2012). Networking on the cloud IBM developerWorks, June 21.
  2. 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. Архів оригіналу за 25 червня 2013. Процитовано 19 травня 2006.
  3. SSH Insertion Attack
  4. Weak CRC allows packet injection into SSH sessions encrypted with block ciphers, US-CERT
  5. Weak CRC allows last block of IDEA-encrypted SSH packet to be changed without notice, US-CERT
  6. SSH-1 allows client authentication to be forwarded by a malicious server to another server, US-CERT
  7. RFC 4253, section 5. Compatibility With Old SSH Versions, IETF
  8. Secsh Protocol Documents Архівовано 8 липня 2017 у Wayback Machine., VanDyke Software, Inc.
  9. SSH Frequently Asked Questions
  10. libssh.
  11. A GNU implementation of the Secure Shell protocols. Архів оригіналу за 4 лютого 2012.
  12. Dropbear SSH. Архів оригіналу за 14 жовтня 2011.
  13. SSH CBC vulnerability, US-CERT
  14. Seggelmann, R.; Tuxen, M.; Rathgeb, E.P. (18–20 July 2012). 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: 1–6. doi:10.1109/CSNDSP.2012.6292659.
  15. Stebila, D.; Green J. (December 2009). RFC5656 - Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer. Процитовано 12 листопада 2012.
  16. Miller, D.; Valchev, P. (3 вересня 2007). The use of UMAC in the SSH Transport Layer Protocol / draft-miller-secsh-umac-00.txt. Процитовано 12 листопада 2012.

Див. також
  • Web-based SSH — доступ до SSH сервер за допомогою стандартних веббраузерів
  • Autossh — інструмент для підтримки постійного зв'язку SSH, його перезапуск при необхідності
  • Corkscrew — інструмент, який дозволяє користувачеві запускати SSH на HTTPS proxy servers
  • Public-key cryptography
  • PuTTY
  • Telnet
  • Ssh-keygen
  • OpenSSH

Посилання

Стандарти
  • 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


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.