SSH

SSH
Дата створення / заснування	1995
Похідна робота	SFTP, SCP і Ssh-keygen
Творець	Тату Ілонен
Ліцензія	GNU Lesser General Public License
Порт	22[1], 22[1] і 22[1]
SSH у Вікісховищі

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

Криптографічний захист протоколу 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

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

• GNU/Linux, *BSD: kdessh, lsh-client, openssh-client, putty, ssh, Vinagre
• MS Windows і Windows NT: PuTTY, SecureCRT, ShellGuard, Axessh, ZOC, SSHWindows, ProSSHD, XShell
• MS Windows Mobile: PocketPuTTy, mToken, sshCE, PocketTTY, OpenSSH, PocketConsole
• Mac OS: NiftyTelnet SSH
• Symbian OS: PuTTY
• Java: MindTerm, AppGate Security Server
• J2ME: MidpSSH
• iOS: i-SSH, ssh (в комплекті з Terminal)
• Android: connectBot
• Blackberry: BBSSH
• Maemo 5: OpenSSH

Використання

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

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

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

Приклади

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

$ ssh -p 30000 [email protected]

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

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

Вразливості

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

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

Архітектура

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

Примітки

Див. також

• Web-based SSH — доступ до SSH сервер за допомогою стандартних веббраузерів
• Autossh — інструмент для підтримки постійного зв'язку SSH, його перезапуск при необхідності
• Corkscrew^[en] — інструмент, який дозволяє користувачеві запускати SSH на HTTPS proxy servers
• Криптографія з відкритим ключем
• PuTTY
• Telnet
• Ssh-keygen
• OpenSSH

Посилання

• Стара домашня сторінка робочої групи «secsh» IETF [Архівовано 3 липня 2013 у Wayback Machine.]
• SSH протоколи [Архівовано 12 квітня 2018 у Wayback Machine.]

Стандарти

• 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

Тематичні сайти Quora · Zhihu Нормативний контроль Freebase: /m/0749d · GND: 4628726-7

Це незавершена стаття про програмне забезпечення. Ви можете допомогти проєкту, виправивши або дописавши її.

Це незавершена стаття про комп'ютерні мережі. Ви можете допомогти проєкту, виправивши або дописавши її.