Secure Shell SSH англ Secure Shell безпечна оболонка мережевий протокол прикладного рівня що дозволяє проводити віддален

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

SSH
Дата створення / заснування	1995

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

Протокол SSH окрім основного призначення - безпечного віддаленого доступу до комп'ютера, та передачі файлів, володіє потужними можливостями тунелювання, через зашифрований канал SSH можна передавати інші дані, інкапсулюючи їх у TCP-з'єднання. Основні можливості це проксування локальних та віддалених TCP-портів (Port Forwarding), тунелювання дисплею для графічних застосунків при використанні X Window System (X Tunnelling). Можливо навіть передавати звук через шифрований канал, втім SSH може використовуватися для тунелювання будь-якого іншого мережевого протоколу, який може бути представлений у вигляді TCP-з'єднання.

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

Версія 1

Широкий розвиток сніферів створив проблему утиліт rlogin, telnet і rsh у зв'язку з тим що протокол телнет прозорий, що вимагало вирішення проблеми безпечного використання програмного забезпечення для віддаленого адміністрування.

Перша версія протоколу, SSH, була розроблена в 1995 році дослідником Тату Ілоненом з Технологічного університету Гельсінкі, Фінляндія. SSH був написаний для забезпечення більшої конфіденційності ніж telnet. Для свого проєкту він запросив у IANA tcp-порт 22, тому що той знаходиться між 21 для ftp та 23 для telnet.

Перша версія вийшла в реліз в липні 1996 як безкоштовне програмне забезпечення , та швидко отримала популярність. В грудні 1995 року Ілонен заснував SSH Communication Security (SCS) для розробки SSH. Оригінальна перша версія використовувала вільне програмне забезпечення, наприклад GNU libgmp, проте SSH Communication Security замінив такі бібліотеки щоб розробляти власницьке програмне забезпечення.

Протокол набув ще більшої популярності, і до 2000 року у нього було близько двох мільйонів користувачів.

Версія 2

В 1996 році SCS розробив версію протоколу SSH-2, яка містить нові алгоритми, та вирішувала деякі архітектурні проблеми першої версії SSH-1, проте SSH-2 була не була сумісна з версією SSH-1. Ілонен описує та пропонує SSH-1 інженерній групі з питань інтернету (IETF), а в 1996 SCS пропонує SSH2. У відповідь IETF створює робочу групу SECSH.

В 1998 році SCS випускає програмний продукт SSH Secure Shell (SSH2) на базі протоколу SSH-2, проте перехід відбувається повільно тому що користувачі не розуміють чим він краще, а також деяких користувачам заважають проприєтарні умови ліцензування програмного продукту. Проте коли проект OpenBSD реалізує версію протоколу SSH2 - OpenSSH під вільною ліцензією, то він портується на інші UNIX-подібні операційні системи та швидко завойовує популярність.

У 2006 році протокол SSH2 був затверджений робочою групою IETF як Інтернет-стандарт. Ця версія не сумісна з SSH-1, але має покращену безпеку та нові можливості. Дизайн протокол почав використовувати поліпшену багатошарову архітектуру, в якій протокол розділений на окремі рівні, подібно до протоколу ISO/OSI. Підтримуються нові механізми обміну ключами по протоколу Діффі-Геллмана, покращена цілісність, завдяки MAC-підписам. Нові можливості SSH-2 передбачають можливість отримувати декілька віртуальних терміналів на одному SSH з'єднанні.

Версія 1.99

У січні 2006 року, вже після затвердження та впровадження SSH-2 версії 2.1 був створений RFC 4253. Його мета забезпечення зворотної сумісності старим клієнтам для роботи з сервером, що підтримує протокол SSH-2, в такому випадку сервер себе позначає що версія протоколу 1.99.

OpenSSH і OSSH

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

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

У 1998 році була описана вразливість в SSH 1.5. Вона дозволяла несанкціоновану вставки даних в зашифрованому потоці SSH через недостатню цілісності даних захист від використовується в даній версії протоколу..

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

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

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

Сервери

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

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

(GNU/Linux), *BSD: , lsh-client, openssh-client, putty, ssh, Vinagre
MS Windows і Windows NT: PuTTY, SecureCRT, , , ZOC, , ,
MS Windows Mobile: PocketPuTTy, mToken, sshCE, PocketTTY, OpenSSH, PocketConsole
Mac OS: NiftyTelnet SSH
Symbian OS: PuTTY
Java: ,
J2ME:
iOS: , ssh (в комплекті з Terminal)
Android:
Blackberry: BBSSH
Maemo 5: OpenSSH

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

Приклади

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

$ ssh -p 30000 user@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

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

Secure Copy (SCP), реалізація через проткол SSH
Rsync - прикладний протокол та програмне забезпечення для копіювання файлів, з гнучкою системою синхронізації файлів та каталогів. Може використовувати SSH в якості аутентифікації та транспортного протоколу.
SSH File Transfer Protocol (SFTP) - безпечна альтернатива FTP (не плутати з (FTP через SSH))
fish - програма яка реалізує передачу файлів за допомогою оболонки через SSH (англ. Files transferred over shell protocol). Використовується в Midnight Commander та інших.

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:

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

Архітектура

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

Транспортний шар (RFC 4253). Цей шар обробляє початковий обмін ключами, автентифікує сервер, встановлює шифрування, стиснення і перевірку цілісності даних. Він надає у вищий шар інтерфейс для відправлення та отримання текстових пакетів розміром до 32768 байт кожен (цей розмір може бути збільшений в певній реалізації). Транспортний рівень також організовує повторний обмін ключами. Як правило, це відбувається після передачі 1 Гб даних або коли пройшла 1 година, що швидше настане.
Шар автентифікації користувача (RFC 4252). Цей шар обробляє перевірку автентичності клієнта і надає ряд методів автентифікації. Автентифікація є клієнто-орієнтованою: коли користувач отримує запит на введення пароля, то це може бути запит SSH клієнта, а не сервера. Сервер просто відповідає на запити клієнта про автентифікацію. Широко вживані методи автентифікації користувачів включають наступне:
- парольна автентифікація: Самий простий метод пароль автентифікації за допомогою перевірки пароля. Підтримується також механізм який дозволяє змінити пароль, але не всі клієнтські програми реалізовують цей механізм.
- публічний ключ: використовує криптографію з відкритим ключем. В якості криптографічних алгоритмів раніше використовувались DSA. RSA має проблеми але все ще залишається популярним на 2024 рік, хоча витісняється ecdsa, ed25519, ed448. Також існують реалізації що підтримують X.509 сертифікати.
- інтерактивний метод (RFC 4256): універсальний, схожий на парольний, метод, коли сервер запитує інформацію, а клієнт відповідає. В якості відповіді може бути одноразовий пароль автентифікації. Цей метод використовується в зв'язці з PAM, для додаткової автентифікації після успішного вводу пароля. (Багатофакторна автентифікація).
- GSS-API методи автентифікації: які забезпечують додаткові схеми для автентифікації з використанням зовнішніх механізмів, таких як Kerberos 5 або NTLM, забезпечуючи можливість Single Sign On на підприємстві.
Шар з'єднань (RFC 4254). Цей шар визначає поняття каналів, запитів для каналів та глобальних запитів. Одне з'єднання по SSH може включати декілька одночасних логічних каналів, в кожному з яких можна передавати дані в обох напрямках. Запити для каналів використовуються для передачі даних, специфічних для каналу, наприклад, зміни розміру буфера терміналу або коду завершення процесу на сервері. Кожен канал також керує потоком даних, використовуючи розмір буфера приймаючої сторони. Клієнт SSH може запросити перенаправлення порту на сервері через глобальний запит. Типи каналів:
- shell використовується для віддалених терміналів, SFTP та запитів на виконання команд (у тому числі SCP передач)
- direct-tcpip використовується для TCP-з'єднань що передаються з клієнта на сервер
- forwarded-tcpip використовується для TCP-з'єднань що передаються з сервера на клієнт

Відбитки публічного ключа

Окрім захисту сервера від неавторизованого користувача різноманітними методами аутентифікації, клієнт також має систему, яка запам'ятовує "відбитки публічних ключів" (ssh fingerprint) в файлі known_hosts, який містить адресу сервера, алгоритми ключа та SHA-1 хеш від публічного ключа.

Існує SSHFP DNS-запис (RFC 4255) пропонує перевіряти відбитки публічних ключів, також описує формат запису для зберігання в DNS.

Поліпшення

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

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

Примітки

Service Name and Transport Protocol Port Number Registry — IANA.
d:Track:Q30335969d:Track:Q242540
Amies A, Wu C F, Wang G C, Criveti M (2012). Networking on the cloud [ 14 червня 2013 у Wayback Machine.] IBM developerWorks, June 21.
The story of the SSH port is 22. www.ssh.com (англ.). Процитовано 8 квітня 2024.
History of SSH - SSH, The Secure Shell: The Definitive Guide, 2nd Edition [Book]. www.oreilly.com (англ.). Процитовано 8 квітня 2024.
Secure Shell (secsh). datatracker.ietf.org (англ.). Процитовано 8 квітня 2024.
O'Reily: Secure Shell, The Definitive Guide
. Архів оригіналу за 1 жовтня 2017. Процитовано 4 березня 2013.
RFC 4253, section 5. Compatibility With Old SSH Versions . Архів оригіналу за 1 березня 2018. Процитовано 13 травня 2022.{{}}: Обслуговування CS1: bot: Сторінки з посиланнями на джерела, де статус оригінального URL невідомий () Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (), IETF
. Архів оригіналу за 8 липня 2011. Процитовано 4.3.2013.
Weak CRC allows packet injection into SSH sessions encrypted with block ciphers [ 5 березня 2018 у Wayback Machine.], US-CERT
Weak CRC allows last block of IDEA-encrypted SSH packet to be changed without notice [ 5 березня 2018 у Wayback Machine.], US-CERT
SSH-1 allows client authentication to be forwarded by a malicious server to another server [ 31 грудня 2017 у Wayback Machine.], US-CERT
SSH CBC vulnerability [ 6 вересня 2017 у Wayback Machine.], US-CERT
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.
Stebila, D.; Green J. (December 2009). . Архів оригіналу за 19 липня 2012. Процитовано 12 листопада 2012.
Miller, D.; Valchev, P. (3 вересня 2007). . Архів оригіналу за 19 серпня 2014. Процитовано 12 листопада 2012.

Див. також

— доступ до SSH сервер за допомогою стандартних веббраузерів
— інструмент для підтримки постійного зв'язку SSH, його перезапуск при необхідності
^[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 4462 (англ.) — Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
RFC 4716 (англ.) — The Secure Shell (SSH) Public Key File Format
RFC 5656 (англ.) — Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer

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

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

[<span_class="wikidata_cite_citetype_Q2352616"_data-entity-id="Q30335969">[https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=ssh_Service_Name_and_Transport_Protocol_Port_Number_Registry]<span_class="wef_low_priority_links">_—_[[:IANA|IANA]].</span></span><div_style="display:none">[[d:Track:Q30335969]][[d:Track:Q242540]]</div>-1] Service Name and Transport Protocol Port Number Registry — IANA.
d:Track:Q30335969d:Track:Q242540

[Networking_on_the_cloud-2] Amies A, Wu C F, Wang G C, Criveti M (2012). Networking on the cloud [ 14 червня 2013 у Wayback Machine.] IBM developerWorks, June 21.

[3] The story of the SSH port is 22. www.ssh.com (англ.). Процитовано 8 квітня 2024.

[4] History of SSH - SSH, The Secure Shell: The Definitive Guide, 2nd Edition [Book]. www.oreilly.com (англ.). Процитовано 8 квітня 2024.

[5] Secure Shell (secsh). datatracker.ietf.org (англ.). Процитовано 8 квітня 2024.

[6] O'Reily: Secure Shell, The Definitive Guide

[7] . Архів оригіналу за 1 жовтня 2017. Процитовано 4 березня 2013.

[8] RFC 4253, section 5. Compatibility With Old SSH Versions . Архів оригіналу за 1 березня 2018. Процитовано 13 травня 2022.{{}}: Обслуговування CS1: bot: Сторінки з посиланнями на джерела, де статус оригінального URL невідомий () Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (), IETF

[9] . Архів оригіналу за 8 липня 2011. Процитовано 4.3.2013.

[10] Weak CRC allows packet injection into SSH sessions encrypted with block ciphers [ 5 березня 2018 у Wayback Machine.], US-CERT

[11] Weak CRC allows last block of IDEA-encrypted SSH packet to be changed without notice [ 5 березня 2018 у Wayback Machine.], US-CERT

[12] SSH-1 allows client authentication to be forwarded by a malicious server to another server [ 31 грудня 2017 у Wayback Machine.], US-CERT

[13] SSH CBC vulnerability [ 6 вересня 2017 у Wayback Machine.], 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.

[RFC5656-15] Stebila, D.; Green J. (December 2009). . Архів оригіналу за 19 липня 2012. Процитовано 12 листопада 2012.

[16] Miller, D.; Valchev, P. (3 вересня 2007). . Архів оригіналу за 19 серпня 2014. Процитовано 12 листопада 2012.

[1]