SSH: відмінності між версіями

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
Інтерактивний перегляд історії
[перевірена версія][очікує на перевірку]
← Попереднє редагування
Вилучено вміст Додано вміст
ВізуальнийВікірозмітка
м →‎Версія 2.x: калька "у якості"
Виправлено джерел: 1; позначено як недійсні: 0.) #IABot (v2.0.9.5
 
(Не показані 7 проміжних версій 2 користувачів)
Рядок 4: Рядок 4:
<noinclude>{{поліпшити|1 листопада 2021}}</noinclude>
<noinclude>{{поліпшити|1 листопада 2021}}</noinclude>
{{Автопереклад|дата=листопад 2013}}
{{Автопереклад|дата=листопад 2013}}
'''Secure Shell''', '''SSH''' ({{lang-en|Secure Shell}}&nbsp;— «безпечна оболонка»<ref name="Networking on the cloud">Amies A, Wu C F, Wang G C, Criveti M (2012). [http://www.ibm.com/developerworks/cloud/library/cl-networkingtools/index.html Networking on the cloud] {{Webarchive|url=https://web.archive.org/web/20130614123106/http://www.ibm.com/developerworks/cloud/library/cl-networkingtools/index.html |date=14 червня 2013 }} ''IBM developerWorks'', June 21.</ref>)&nbsp;— [[мережевий протокол]] прикладного рівня, що дозволяє проводити [[віддалене адміністрування|віддалене управління]] [[комп'ютер]]ом і тунелювання [[TCP]]-з'єднань (наприклад, для передачі файлів). Схожий за функціональністю з протоколом [[Telnet]] і [[rlogin]], проте шифрує весь трафік, в тому числі і паролі, що передаються.
'''Secure Shell''', '''SSH''' ({{lang-en|Secure Shell}}&nbsp;— «безпечна оболонка»<ref name="Networking on the cloud">Amies A, Wu C F, Wang G C, Criveti M (2012). [http://www.ibm.com/developerworks/cloud/library/cl-networkingtools/index.html Networking on the cloud] {{Webarchive|url=https://web.archive.org/web/20130614123106/http://www.ibm.com/developerworks/cloud/library/cl-networkingtools/index.html |date=14 червня 2013 }} ''IBM developerWorks'', June 21.</ref>)&nbsp;— [[мережевий протокол]] прикладного рівня, що дозволяє проводити [[віддалене адміністрування|віддалене управління]] [[комп'ютер]]ом і тунелювання [[TCP]]-з'єднань (наприклад, для передачі файлів). Схожий за функціональністю з протоколом [[Telnet]] і [[rlogin]], проте шифрує весь трафік, , .


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


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


=== Версія 1 ===
Зараз відомо дві гілки версій&nbsp;— 1 і 2. Проте гілка 1 зупинена, оскільки наприкінці 90-х у ній було знайдено багато [[вразливість|вразливостей]], деякі з яких досі накладають серйозні обмеження на її використання, тому перспективною (такою, що розвивається) і найбезпечнішою є версія 2.
Широкий розвиток [[сніфер]]ів створив проблему утиліт rlogin, telnet і rsh у зв'язку з тим що протокол [[телнет]] прозорий, що вимагало вирішення проблеми безпечного використання програмного забезпечення для віддаленого адміністрування.


Перша версія протоколу, SSH, була розроблена в 1995 році дослідником [[Тату Ілонен]]ом з Технологічного університету [[Гельсінкі]], [[Фінляндія]]. SSH був напис��ний для забезпечення більшої конфіденційності ніж telnet. Для свого проєкту він запросив у IANA tcp-порт 22<ref>{{Cite web|url=https://www.ssh.com/academy/ssh/port|title=The story of the SSH port is 22.|website=www.ssh.com|language=en|access-date=2024-04-08}}</ref>, тому що той знаходиться між 21 для ftp та 23 для telnet.


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


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


=== Версія 2 ===
Перша версія протоколу, SSH-1, була розроблена в 1995 році дослідником [[Тату Ілонен]]ом з Технологічного університету [[Гельсінкі]], [[Фінляндія]]. SSH-1 був написаний для забезпечення більшої конфіденційності, ніж протоколи rlogin, telnet і rsh. У 1996 році була розроблена безпечніша версія протоколу, SSH-2, несумісна з SSH-1. Протокол набув ще більшої популярності, і до 2000 року у нього було близько двох мільйонів користувачів. В даний час під терміном «SSH» зазвичай мається на увазі саме SSH-2, тому що перша версія протоколу з огляду істотних недоліків зараз практично не застосовується.
В 1996 році SCS розробив версію протоколу SSH-2, яка містить нові алгоритми, та вирішувала деякі архітектурні проблеми першої версії SSH-1, проте SSH-2 була не була сумісна з версією SSH-1. Ілонен описує та пропонує SSH-1 інженерній групі з питань інтернету ([[IETF|IETF)]], а в 1996 SCS пропонує SSH2. У відповідь IETF створює робочу групу SECSH.


В 1998 році SCS випускає програмний продукт SSH Secure Shell (SSH2) на базі протоколу SSH-2, проте перехід відбувається повільно тому що користувачі не розуміють чим він краще, а також деяких користувачам заважають проприєтарні умови ліцензування програмного продукту. Проте коли проект [[OpenBSD]] реалізує версію протоколу SSH2 - OpenSSH під вільною ліцензією, то він портується на інші [[UNIX-подібні операційні системи]] та швидко завойовує популярність.<ref>{{Cite web|url=https://www.oreilly.com/library/view/ssh-the-secure/0596008953/ch01s05.html|title=History of SSH - SSH, The Secure Shell: The Definitive Guide, 2nd Edition [Book]|website=www.oreilly.com|language=en|access-date=2024-04-08}}</ref>
У 2006 році протокол був затверджений робочою групою [[IETF]] як Інтернет-стандарт.


У 2006 році протокол SSH2 був затверджений робочою групою [[IETF]] як Інтернет-стандарт<ref>{{Cite web|url=https://datatracker.ietf.org/wg/secsh/documents/|title=Secure Shell (secsh)|website=datatracker.ietf.org|language=en|access-date=2024-04-08}}</ref>. Ця версія не сумісна з SSH-1, але має покращену безпеку та нові можливості. Дизайн протокол почав використовувати поліпшену багатошарову архітектуру, в якій протокол розділений на окремі рівні, подібно до протоколу ISO/OSI<ref>[https://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_05.htm O'Reily: Secure Shell, The Definitive Guide]</ref>. Підтримуються нові механізми обміну ключами по [[Протокол Діффі-Геллмана|протоколу Діффі-Геллмана]], покращена [[Цілісність інформації|цілісність]], завдяки [[MAC-підпис|MAC-підписам]]. Нові можливості SSH-2 передбачають можливість отримувати декілька віртуальних терміналів на одному SSH з'єднанні<ref>{{Cite web|url=http://www.snailbook.com/faq/ssh-1-vs-2.auto.html|title=SSH Frequently Asked Questions|archive-url=https://web.archive.org/web/20171001041532/http://www.snailbook.com/faq/ssh-1-vs-2.auto.html|archive-date=1 жовтня 2017|accessdate=4 березня 2013}}</ref>.
Проте, в деяких країнах (Франція, Росія, Ірак і Пакистан) до сих пір потрібен спеціальний дозвіл у відповідних структурах для використання певних методів шифрування, включаючи SSH. Див закон Російської Федерації «Про федеральних органах урядового зв'язку і інформації» (закон втратив силу з 1 липня 2003 року у зв'язку з прийняттям федерального закону від 30.06.2003 №&nbsp;86-ФЗ).


=== Версія 1.99 ===
Поширені дві реалізації SSH: пропріетарна комерційна та безкоштовна вільна. Вільна реалізація називається OpenSSH. До 2006 року 80&nbsp;% комп'ютерів мережі Інтернет використовувало саме OpenSSH. Пропріетарна реалізація розробляється організацією SSH Inc., Вона безкоштовна для некомерційного використання. Ці реалізації містять практично однаковий набір команд.
У січні 2006 року, вже після затвердження та впровадження SSH-2 версії 2.1 був створений RFC 4253. Його мета забезпечення [[зворотна сумісність|зворотної сумісності]] старим клієнтам для роботи з сервером, що підтримує протокол SSH-2, в такому випадку сервер себе позначає що версія протоколу 1.99.<ref>[[rfc:4253#section-5.1|RFC 4253, section 5. Compatibility With Old SSH Versions]] {{Cite web |url=https://tools.ietf.org/html/rfc4253 |title=Архівована копія |access-date=2022-05-13 |archive-date=2018-03-01 |archive-url=https://web.archive.org/web/20180301045430/https://tools.ietf.org/html/rfc4253 |url-status=bot: unknown }}, IETF</ref>


=== OpenSSH і OSSH ===
Протокол SSH-2, на відміну від протоколу telnet, стійкий до атак прослуховування трафіку («сніфінг»). Протокол SSH-2 також стійкий до атак шляхом приєднання посередині ({{lang-en|session hijacking}})&nbsp;— неможливо включитися у вже встановлену сесію або перехопити її.
У 1999 році розробники, бажали повернутися до старої 1.2.12 реалізовуючи оригінальну SSH програму, яка була останньою випущена під [[Відкрите програмне забезпечення|з відкритим вихідним кодом]] ліцензію. OSSH Björn Grönvall згодом почав розвиватися з цього коду.


==== Відомі вразливості ====
Для запобігання атак «людина посередині» при підключенні до хосту, ключ якого ще не відомий клієнту, клієнтське ПО показує користувачеві «зліпок ключа» (key fingerprint). Рекомендується ретельно перевіряти показуваний клієнтським ПО «зліпок ключа» (key fingerprint) зі зліпком ключа сервера, бажано отриманим по надійним каналах зв'язку або особисто.
У 1998 році була описана вразливість в SSH 1.5. Вона дозволяла несанкціоновану вставки даних в зашифрованому потоці SSH через недостатню цілісності даних захист від [[CRC-32]] використовується в даній версії протоколу.<ref>{{Cite web|url=http://www.coresecurity.com/content/ssh-insertion-attack|title=SSH Insertion Attack|archive-url=https://web.archive.org/web/20110708192336/http://www.coresecurity.com/content/ssh-insertion-attack|archive-date=2011-07-08|accessdate=4.3.2013}}</ref><ref>[http://www.kb.cert.org/vuls/id/13877 Weak CRC allows packet injection into SSH sessions encrypted with block ciphers] {{Webarchive|url=https://web.archive.org/web/20180305035139/https://www.kb.cert.org/vuls/id/13877|date=5 березня 2018}}, US-CERT</ref>.


У січні 2001 року була виявлена ​​уразливість, яка дозволяє зловмисникові змінювати останній блок [[International Data Encryption Algorithm|IDEA.]] Зашифровані сесії<ref>[http://www.kb.cert.org/vuls/id/315308 Weak CRC allows last block of IDEA-encrypted SSH packet to be changed without notice] {{Webarchive|url=https://web.archive.org/web/20180305020549/https://www.kb.cert.org/vuls/id/315308|date=5 березня 2018}}, US-CERT</ref> У тому ж місяці, інша уразливість була виявлена, що дозволяло шкідлививому серверу пересилання автентифікації клієнта на інший сервер.<ref>[http://www.kb.cert.org/vuls/id/684820 SSH-1 allows client authentication to be forwarded by a malicious server to another server] {{Webarchive|url=https://web.archive.org/web/20171231230128/http://www.kb.cert.org/vuls/id/684820|date=31 грудня 2017}}, US-CERT</ref>
Підтримка SSH реалізована у всіх UNIX-подібних системах, і на більшості з них в числі стандартних утиліт присутні клієнт і сервер ssh. Існує безліч реалізацій SSH-клієнтів і для не-UNIX ОС. Велику популярність протокол отримав після широкого розвитку аналізаторів трафіку і способів порушення роботи локальних мереж, як альтернативне небезпечному протоколу Telnet ��ішення для управління важливими вузлами.


Так як SSH-1 притаманні недоліки дизайну, які роблять його вразливим, в даний час він вважається застарілим і його слід уникати, відключивши повернення до SSH-1. Більшість сучасних серверів і клієнтів підтримують SSH-2.
Для роботи по SSH потрібен SSH-сервер і SSH-клієнт. Сервер прослуховує з'єднання від клієнтських машин і при встановленні зв'язку виробляє [[Автентифікація|автентифікацію]], після чого починає обслуговування клієнта. Клієнт використовується для входу на віддалену машину і виконання команд.


У листопаді 2008 року теоретичну вразливість була виявлена ​​для всіх версій SSH, який дозволив відновлення до 32 біт відкритого тексту з блоку зашифрованого тексту, зашифрованого за допомогою тодішнього стандартного режиму шифрування за умовчанням<ref>[http://www.kb.cert.org/vuls/id/958563 SSH CBC vulnerability] {{Webarchive|url=https://web.archive.org/web/20170906023057/http://www.kb.cert.org/vuls/id/958563|date=6 вересня 2017}}, US-CERT</ref>.
Для з'єднання сервер і клієнт повинні створити пари ключів&nbsp;— відкритих і закритих&nbsp;— і обмінятися відкритими ключами. Зазвичай використовується також і пароль.


=== Сервери ===
=== Сервери ===
Рядок 54: Рядок 61:
== Використання ==
== Використання ==
{{section-stub}}
{{section-stub}}

=== Передача файлів з використанням SSH ===
Є кілька механізмів передачі файлів за допомогою захищених протоколів Shell.
* [[Secure Copy]] (SCP), який відбувся від [[РКП (Unix)|RCP]] Протокол по SSH
* [[Rsync]], повинен бути більш ефективним, ніж SCP
* [[SSH File Transfer Protocol]] (SFTP), безпечна альтернатива [[File Transfer Protocol|FTP]] (не плутати з [[File Transfer Protocol#FTP over SSH .28not SFTP.29|FTP через SSH]])
* [[Файли передаються по протоколу оболонки]] (так званий FISH), випущений в 1998 році, який перетворився з команди [[Командна оболонка Unix|командної оболонки Unix]] через SSH


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


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

$ ssh -p 30000 pacify@127.0.0.1


Генерація пари ключів (в UNIX-подібних ОС) здійснюється командою
Генерація пари ключів (в UNIX-подібних ОС) здійснюється командою
Рядок 80: Рядок 79:
Для використання SSH в Python існують такі модулі, як python-paramiko і python-twisted-conch.
Для використання SSH в Python існують такі модулі, як python-paramiko і python-twisted-conch.


=== Передача файлів з використанням SSH ===
=== Безпека застосування ===
Є кілька механізмів передачі файлів за допомогою захищених протоколів Shell.

* [[Secure Copy]] (SCP), реалізація [[РКП (Unix)|RCP]] через проткол SSH
Поради щодо безпеки використання SSH:
* [[Rsync]] - прикладний протокол та програмне забезпечення для копіювання файлів, з гнучкою системою синхронізації файлів та каталогів. Може використовувати SSH в якості аутентифікації та транспортного протоколу.
* Заборона віддаленого root-доступу.
* [[SSH File Transfer Protocol]] (SFTP) - безпечна альтернатива [[File Transfer Protocol|FTP]] (не плутати з [[File Transfer Protocol#FTP over SSH .28not SFTP.29|FTP через SSH]])
* Заборона підключення з порожнім паролем або відключення входу по паролю.
* fish - програма яка реалізує передачу файлів за допомогою оболонки через SSH ({{lang-en|'''Fi'''les transferred over '''sh'''ell protocol}}). Використовується в [[Midnight Commander]] та інших.
* Вибір нестандартного порту для SSH-сервера.
* Використання довгих SSH2 RSA-ключів (2048 біт і більше). Системи шифрування на основі RSA вважаються надійними, якщо довжина ключа не менше 1024 біт.
* Обмеження списку IP-адрес, з яких дозволений доступ (наприклад, настроюванням фаєрвола).
* Заборона доступу з деяких потенційно небезпечних адрес.
* Відмова від використання пош��рених або широко відомих системних логінів для доступу по SSH.
* Регулярний перегляд повідомлень про помилки автентифікації.
* Установка систем виявлення вторгнень (IDS&nbsp;— Intrusion Detection System).
* Використання пасток, підроблюють SSH-сервіс ([[honeypot]]s).

== SSH-тунелювання ==


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


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


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


=== Безпека застосування ===
== Технічна інформація про протокол ==


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

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

* Використання довгих SSH2 RSA-ключів (2048 біт і більше). Системи шифрування на основі RSA вважаються надійними, якщо довжина ключа не менше 1024 біт.
== Історія розвитку ==
* Обмеження списку IP-адрес, з яких дозволений доступ (наприклад, настроюванням фаєрвола).

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

* Регулярний перегляд повідомлень про помилки автентифікації.
SSH програма зазвичай використовується для встановлення з'єднання з ухвалення віддалених підключень. І те й інше зазвичай присутнє на більшості сучасних [[операційні системи]], включаючи [[Mac OS]], більшість розподілів [[Gnu/Linux]], [[OpenBSD]], [[FreeBSD]], [[NetBSD]], [[Solaris (операційна система)|Solaris]] і [[OpenVMS.]] Відомо, що [[Windows]] є одним з небагатьох сучасних / серверних операційних систем, які не включають SSH за замовчуванням.
* Установка систем виявлення вторгнень (IDS&nbsp;— Intrusion Detection System).

* Використання пасток, підроблюють SSH-сервіс ([[honeypot]]s).
SSH відіграє важливу роль в обчислень для вирішення проблем з підключенням, уникаючи питань безпеки, піддаючи віртуальну машину безпосередньо до Інтернету. Тунель SSH може забезпечити безпечний шлях через Інтернет, через брандмауер на віртуальній машині.<ref name="Networking on the cloud"/>

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

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

Вважається, що, {{Станом | 2000 | lc=on}}, було 2 мільйони користувачів SSH<ref name="Nicholas Rosasco and David Larochelle">{{cite web
|author=Nicholas Rosasco and David Larochelle
|title=How and Why More Secure Technologies Succeed in Legacy Markets: Lessons from the Success of SSH
|publisher=Dept. of Computer Science, Univ. of Virginia
|date=
|work=Quoting [[Daniel J. Barrett|Barrett]] and Silverman, ''SSH, the Secure Shell: The Definitive Guide,'' O'Reilly & Associates (2001)
|url=http://www.cs.virginia.edu/~drl7x/sshVsTelnetWeb3.pdf
|accessdate=2006-05-19
|archivedate=2013-06-25
|archiveurl=https://www.webcitation.org/6HdXoPerg?url=http://www.cs.virginia.edu/~drl7x/sshVsTelnetWeb3.pdf
|url-status=live
}}</ref>

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

У 1998 році вразливість була описана в SSH 1.5, що дозволяло несанкціонованого вставки контенту в зашифрованому потоці SSH через недостатню цілісності даних захист від [[CRC-32]] використовується в даній версії протоколу.<ref>{{Cite web |url=http://www.coresecurity.com/content/ssh-insertion-attack |title=SSH Insertion Attack |accessdate=4.3.2013 |archive-date=2011-07-08 |archive-url=https://web.archive.org/web/20110708192336/http://www.coresecurity.com/content/ssh-insertion-attack }}</ref><ref>[http://www.kb.cert.org/vuls/id/13877 Weak CRC allows packet injection into SSH sessions encrypted with block ciphers] {{Webarchive|url=https://web.archive.org/web/20180305035139/https://www.kb.cert.org/vuls/id/13877 |date=5 березня 2018 }}, US-CERT</ref>.

У січні 2001 року була виявлена ​​уразливість, яка дозволяє зловмисникові змінювати останній блок [[International Data Encryption Algorithm|IDEA.]] Зашифровані сесії<ref>[http://www.kb.cert.org/vuls/id/315308 Weak CRC allows last block of IDEA-encrypted SSH packet to be changed without notice] {{Webarchive|url=https://web.archive.org/web/20180305020549/https://www.kb.cert.org/vuls/id/315308 |date=5 березня 2018 }}, US-CERT</ref> У тому ж місяці, інша уразливість була виявлена, що дозволяло шкідлививому серверу пересилання автентифікації клієнта на інший сервер.<ref>[http://www.kb.cert.org/vuls/id/684820 SSH-1 allows client authentication to be forwarded by a malicious server to another server] {{Webarchive|url=https://web.archive.org/web/20171231230128/http://www.kb.cert.org/vuls/id/684820 |date=31 грудня 2017 }}, US-CERT</ref>

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

=== Версія 1.99 ===
У січні 2006 року, після версії 2.1 був створений, RFC 4253, що означало, що сервер SSH, який підтримує як 2.0 так і попередні версії SSH повинні визначити свої версії як 1,99.<ref>[http://tools.ietf.org/html/rfc4253#section-5.1 RFC 4253, section 5. Compatibility With Old SSH Versions] {{Webarchive|url=https://web.archive.org/web/20180301045430/https://tools.ietf.org/html/rfc4253#section-5.1 |date=1 березня 2018 }}, IETF</ref> Це не фактичні версії, але метод ідентифікації [[зворотна сумісність]].

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

=== Версія 2.x ===
У 2006 році переглянута версія протоколу, що отримала назву SSH-2, була прийнята як новий стандарт. Ця версія не сумісна з SSH-1, але має покращену безпеку та нові можливості порівняно з SSH-1. Наприклад, вона вводить нові механізми обміну ключами і має поліпшену структуру протоколу, в якій протокол розділений на окремі рівні, подібно до протоколу ISO/OSI<ref>[https://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_05.htm O'Reily: Secure Shell, The Definitive Guide]</ref>. Краща захищеність, проявляється у використанні [[Протокол Діффі-Геллмана|протоколу Діффі-Геллмана]] і сильнішій [[Цілісність інформації|цілісності]], коли перевірка відбувається за допомогою [[MAC-підпис]]ів. Нові можливості SSH-2 передбачають можливість запускати будь-яку кількість [[Командна оболонка Unix|оболонок]] сесій на одному SSH з'єднанні<ref>{{Cite web |url=http://www.snailbook.com/faq/ssh-1-vs-2.auto.html |title=SSH Frequently Asked Questions |accessdate=4 березня 2013 |archive-date=1 жовтня 2017 |archive-url=https://web.archive.org/web/20171001041532/http://www.snailbook.com/faq/ssh-1-vs-2.auto.html }}</ref>. Через переваги SSH-2 над SSH-1 та більшу популярність, такі реалізації SSH-2 як libssh (v0.8.0+),<ref>{{cite web|url=https://www.libssh.org/2018/08/10/libssh-0-8-0/|title=libssh|accessdate=23 липня 2019|archive-date=23 липня 2019|archive-url=https://web.archive.org/web/20190723153034/https://www.libssh.org/2018/08/10/libssh-0-8-0/}}</ref> {{Нп|Lsh|||}}<ref>{{cite web|url=http://www.lysator.liu.se/~nisse/lsh/|title=A GNU implementation of the Secure Shell protocols|deadurl=no|archive-url=https://web.archive.org/web/20120204035753/http://www.lysator.liu.se/~nisse/lsh/|archive-date=2012-02-04}}</ref> and {{Нп|Dropbear|||Dropbear (software)}}<ref>{{cite web|url=https://matt.ucc.asn.au/dropbear/dropbear.html|title=Dropbear SSH|deadurl=no|archive-url=https://web.archive.org/web/20111014091250/http://matt.ucc.asn.au/dropbear/dropbear.html|archive-date=2011-10-14}}</ref> підтримують тільки протокол SSH-2.

==== Вразливості ====
У листопаді 2008 року теоретичну вразливість була виявлена ​​для всіх версій SSH, який дозволив відновлення до 32 біт відкритого тексту з блоку зашифрованого тексту, зашифрованого за допомогою тодішнього стандартного режиму шифрування за умовчанням<ref>[http://www.kb.cert.org/vuls/id/958563 SSH CBC vulnerability] {{Webarchive|url=https://web.archive.org/web/20170906023057/http://www.kb.cert.org/vuls/id/958563 |date=6 вересня 2017 }}, US-CERT</ref>.

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


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


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


=== Відбитки публічного ключа ===
Це відкрита архітектура забезпечує значну гнучкість, дозволяючи SSH, який буде використовуватися для різних цілей, крім безпечної оболонки. Функціональність транспортного рівня тільки порівнянна з [[Transport Layer Security]] (TLS); шар автентифікації користувачів вельми розширюваної за допомогою користувальницьких методів автентифікації і з'єднання шарів забезпечує можливість мультиплексування багатьох середніх сесій в одне з'єднання SSH, функція порівнянна з [[BEEP]] і не доступні в TLS.
Окрім захисту сервера від неавторизованого користувача різноманітними методами аутентифікації, клієнт також має систему, яка запам'ятовує "відбитки публічних ключів" (ssh fingerprint) в файлі known_hosts, який містить адресу сервера, алгоритми ключа та SHA-1 хеш від публічного ключа.

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


== Поліпшення ==
== Поліпшення ==
Рядок 215: Рядок 163:
* [http://www.snailbook.com/protocols.html SSH протоколи] {{Webarchive|url=https://web.archive.org/web/20180412201410/http://www.snailbook.com/protocols.html |date=12 квітня 2018 }}
* [http://www.snailbook.com/protocols.html SSH протоколи] {{Webarchive|url=https://web.archive.org/web/20180412201410/http://www.snailbook.com/protocols.html |date=12 квітня 2018 }}


=== Стандарти ===
== Стандарти ==

* RFC 4250 {{ref-en}}&nbsp;— The Secure Shell (SSH) Protocol Assigned Numbers
* RFC 4250 {{ref-en}}&nbsp;— The Secure Shell (SSH) Protocol Assigned Numbers
* RFC 4251 {{ref-en}}&nbsp;— The Secure Shell (SSH) Protocol Architecture
* RFC 4251 {{ref-en}}&nbsp;— The Secure Shell (SSH) Protocol Architecture
Рядок 229: Рядок 176:
* RFC 4419 {{ref-en}}&nbsp;— Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
* RFC 4419 {{ref-en}}&nbsp;— Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
* RFC 4432 {{ref-en}}&nbsp;— RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
* RFC 4432 {{ref-en}}&nbsp;— RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
* RFC 4462 {{ref-en}}&nbsp;— Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
* RFC 4716 {{ref-en}}&nbsp;— The Secure Shell (SSH) Public Key File Format
* RFC 4716 {{ref-en}}&nbsp;— The Secure Shell (SSH) Public Key File Format
* RFC 5656 {{ref-en}}&nbsp;— Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
{{бібліоінформація}}
{{бібліоінформація}}
{{Команди Unix}}
{{Команди Unix}}

Поточна версія на 00:25, 13 червня 2024

SSH
Дата створення / заснування 1995
Зображення
Похідна робота SFTP, SCP і Ssh-keygen
Творець Тату Ілонен
Ліцензія GNU Lesser General Public License
Порт 22[1], 22[1] і 22[1]
CMNS: SSH у Вікісховищі
Модель TCP/IP (RFC 1122)
Прикладний рівень
Транспортний рівень
Мережевий рівень
Канальний рівень
Цей шаблон:
Протоколи безпеки
Інтернет
Керування ключами
Рівень застосувань
Система доменних імен
Рівень Інтернет
Ця стаття потребує істотної переробки. Можливо, її необхідно доповнити, переписати або вікіфікувати. Пояснення причин та обговорення — на сторінці Вікіпедія: Статті, що необхідно поліпшити.
Тому, хто додав шаблон: зважте на те, щоб повідомити основних авторів статті про необхідність поліпшення, додавши до їхньої сторінки обговорення такий текст:
{{subst:поліпшити автору|SSH|1 листопада 2021}} ~~~~,
а також не забудьте описати причину номінації на підсторінці Вікіпедія:Статті, що необхідно поліпшити за відповідний день. (1 листопада 2021)
Ця стаття є сирим перекладом з іншої мови. Можливо, вона створена за допомогою машинного перекладу або перекладачем, який недостатньо володіє обома мовами. Будь ласка, допоможіть поліпшити переклад. (листопад 2013)

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

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

Версія 1.99

[ред. | ред. код]

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

OpenSSH і OSSH

[ред. | ред. код]

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

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

[ред. | ред. код]

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

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

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

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

Сервери

[ред. | ред. код]
BSD
OpenSSH
Linux
dropbear, lsh-server, openssh-server, ssh
Windows
freeSSHd, copssh, WinSSHD, KpyM Telnet / SSH Server, MobaSSH, OpenSSH через Cygwin, DenWer

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

[ред. | ред. код]

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

[ред. | ред. код]
Цей розділ потребує доповнення.

Приклади

[ред. | ред. код]

Команда підключення до локального 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), реалізація RCP через проткол 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).

Архітектура

[ред. | ред. код]
Diagram of the SSH-2 binary packet.

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

Примітки

[ред. | ред. код]
  1. ↑ а б в Service Name and Transport Protocol Port Number Registry — IANA.
  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. ↑ SSH Frequently Asked Questions. Архів оригіналу за 1 жовтня 2017. Процитовано 4 березня 2013.
  8. ↑ RFC 4253, section 5. Compatibility With Old SSH Versions Архівована копія. Архів оригіналу за 1 березня 2018. Процитовано 13 травня 2022.{{cite web}}: Обслуговування CS1: bot: Сторінки з посиланнями на джерела, де статус оригінального URL невідомий (посилання) Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (посилання), IETF
  9. ↑ SSH Insertion Attack. Архів оригіналу за 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.
  15. ↑ а б Stebila, D.; Green J. (December 2009). RFC5656 - Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer. Архів оригіналу за 19 липня 2012. Процитовано 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. Архів оригіналу за 19 серпня 2014. Процитовано 12 листопада 2012.

Див. також

[ред. | ред. код]

Посилання

[ред. | ред. код]

Стандарти

[ред. | ред. код]
  • 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
Перегляд цього шаблону
  Тематичні сайти
Нормативний контроль
UNIX-команди, що запускаються в режимі командного рядка
Файлові системи:
Файли і каталоги:
Процеси:
Користувачі:
Мережа:
Тексти:
Командний рядок:
Друк:
Пошук:
Різне:
Схеми URI
Офіційні
aaa: • aaas: • acap[en]: • cap: • cid: • crid[en]: • data[en]: • dav: • dict: • dns: • fax: • file[en]: • ftp: • go: • gopher: • h323: • http: • https: • im: • imap: • ldap: • mailto: • mid: • news: • nfs: • nntp: • pop: • pres: • rtsp: • sip: • sips: • snmp: • tel: • telnet: • urn: • wais: • xmpp:
Неофіційні
about:[en] • aim: • bolo: • btc: • bzr: • callto: • chrome: • cvs: • daap: • ed2k: • ed2kftp: • feed[en]: • fish: • git: • gizmoproject: • iax2: • irc: • ircs: • itms: • lastfm: • ldaps: • magnet: • mms: • msnim: • psyc: • rsync: • secondlife: • skype: • ssh: • svn: • sftp: • smb: • sms: • soldat: • steam: • unreal: • ut2004: • view-source[en]: • webcal: • xfire: • ymsgr:
Програмне забезпечення Це незавершена стаття про програмне забезпечення.
Ви можете допомогти проєкту, виправивши або дописавши її.
{{{alt}}} Це незавершена стаття про комп'ютерні мережі.
Ви можете допомогти проєкту, виправивши або дописавши її.
Ця стаття містить текст, що не відповідає енциклопедичному стилю. Будь ласка, допоможіть удосконалити цю статтю, погодивши стиль викладу зі стилістичними правилами Вікіпедії. Можливо, сторінка обговорення містить зауваження щодо потрібних змін. (вересень 2012)
Ця стаття є сирим перекладом з іншої мови. Можливо, вона створена за допомогою машинного перекладу або перекладачем, який недостатньо володіє обома мовами. Будь ласка, допоможіть поліпшити переклад. (листопад 2013)
Цю статтю потрібно повністю переписати відповідно до стандартів якості Вікіпедії. Ви можете допомогти, переробивши її. Можливо, сторінка обговорення містить зауваження щодо потрібних змін. (липень 2017)
Отримано з https://uk.wikipedia.org/w/index.php?title=SSH&oldid=42791729