Блог

Какво е SSH и как работи?

Какво е SSH криптиране и как работи

С ecure Ш ell (SSH) е често прилаган протокол за сигурност с набор от различни приложения. Неговото най-известно приложение позволява на потребителите дасигурен достъп до отдалечени компютри и сървъри, но може да се използва и за тунелиране, препращане на портове, защитено прехвърляне на файлове и др.

В това ръководство ще разгледамекакво е SSH, за какво се използва, историята на протокола, неговите технически подробности, както ипроблеми със сигурносттакоито трябва да се вземат предвид.

SSH се състои от три отделни протокола:транспортния слой, слоя за удостоверяване и слоя за връзка. Заедно те служат за удостоверяване на другата страна във връзката, осигуряване на поверителност чрез криптиране и проверка на целостта на данните. Сега SSH най-често се прилага или като патентован SSH-2, или като итерация с отворен код, OpenSSH.

Използването на SSH

SSH е многофункционален протокол. Неговата структура и функции за сигурност му позволяват да бъде използван по различни начини, като например за отдалечен достъп, пренасочване на портове, тунелиране и защитено прехвърляне на файлове.

Отдалечен достъп

Отдалеченият достъп дава на потребителите начин давлизат в друг компютър или сървър от собствената си машина. Използва се за достъп до локалните файлове на целевата машина или за извършване на услуги върху нея, без да се налага физически да сте там.

Програми като Telnet и rlogin също имат тази функционалност, но им липсват функциите за сигурност на SSH. Мерките за криптиране и удостоверяване, включени в SSH, позволяват на потребителите да се свързват към друг сървър или компютър по защитен начин, дори през потенциално опасна междинна мрежа.

Отдалеченият достъп с SSH обикновено се прилага, така че служителите да могат да работят дистанционно или да позволят на ИТ отдела да изпълнява задачи, без да се налага физически да ходят до машината. Може да се използва за отдалечено администриране, управление на мрежова инфраструктура, за настройка на автоматизация, създаване на резервни копия и др.

Пренасочване на портове

Пренасочване на портове се използва за прехвърляне на заявки от един адрес и номер на порт към друг набор. Той прилага преобразуване на мрежови адреси (NAT) за пренасочване на портове между локална мрежа и отдалечен компютър, което ви позволява достъп до устройство извън мрежата.

Пренасочването на порт може да се извърши по три различни начина:

  • Местен пренасочване на портове – Пренасочването на локален порт ви позволява да свържете вашия локален клиент и външна мрежа. Може да бъде ефективен за извършване на неща като достъп до уебсайтове, които са блокирани локално, или за свързване към база данни, която е зад защитна стена.
  • Отдалечено пренасочване на портове – Този тип пренасочване позволява на сървърните приложения да имат достъп до услуги от страна на клиента. Пренасочването на отдалечен порт на SSH позволява на потребителите да се свързват сигурно с отдалечени сървъри през локалния си компютър, като пренасочват локален порт към отдалечен SSH сървър.
  • Динамичен пренасочване на портове – Това позволява на потребителите да изпращат своите данни през определен порт към отдалечен компютър или сървър, като използват няколко SSH сървъра, които действат като прокси сървъри.

Тунелиране

ssh-2

Протоколите за тунелиране използват капсулиране за преместване на данни между мрежите. Тунелите могат да бъдат разгърнати, за да позволят на чужди протоколи да работят през мрежи, които обикновено не ги поддържат. Друга често срещана употреба е заосигуряване на сигурност през опасна мрежа.

Протоколите за тунелиране обгръщат критичните пакети в полезния товар на друг пакет. SSH тунелирането позволява на потребителите да заобиколят сигурността на мрежата, да свържат устройства, използвайки нероден мрежов протокол, и да защитят данните, които се предават. Те често се използват за свързване на отдалечени потребители към онлайн ресурсите на тяхната организация по сигурен начин.

SFTP

Протоколът за прехвърляне на файлове SSH (FTP), понякога известен като протокол за прехвърляне на защитени файлове, предоставя безопасен начин за достъп, прехвърляне и управление на файлове. Това е сигурна алтернатива на FTP и използва SSH протокола за сигурно изпращане, получаване и администриране на файлове.

SCP

Протоколът за защитено копиране (SCP) е подобен на SFTP, но е по-ограничен в своя обхват. Той позволява само сигурни прехвърляния на файлове, а не пълния набор от функции, които позволяват SFTP да действа като протокол на отдалечена файлова система.

Платформи и приложения, които използват SSH

Собственият SSH или OpenSSH може да се използва на всички основни операционни системи. Предлага се на Unix-базирани платформи като OpenBSD, macOS, Linux и Solaris, докато потребителите на Windows могат да използват SSH през PowerShell .

Историята на SSH

SSH е разработен в Хелзинкския технологичен университет през 1995 г. от Тату Юльонен в отговор на атака с подслушване на парола в мрежата на университета. Той имаше за цел да предостави алтернатива на протоколи като FTP, TELNET, rsh и rlogin , което не гарантира поверителност или удостоверяване на потребителите по сигурен начин.

SSH беше пуснат безплатно за обществеността през 1995 г. и беше добре приет. На фона на бързото му приемане, Ylönen основа SSH Communications Security до края на същата година, за да продължи развитието и комерсиализиране на SSH.

През 1995 г. Ylönen също публикува интернет проект на Internet Engineering Task Force (IETF), койтодокументира протокола SSH-1. Скоро бяха открити ограничения в протокола и те не можеха да бъдат адресирани, без да се засегне обратната съвместимост. Решението беше нова версия на протокола и SSH-2 беше пуснат от компанията на Ylönen през 1996 г.

SSH-2 включваше нови алгоритми, което накара IETF да създаде работна група, която имаше за цел да стандартизира протокола. Групата беше наречена SECSH, за Разд уре Ш ell, и публикува първия си интернет проект за SSH-2 през 1997 г.

Софтуерът за SSH-2 беше издаден през 1998 г , но не беше незабавно приет по широко разпространен начин поради по-рестриктивното лицензиране.През 2006 г. променена версия на протокола беше превърната в стандарт от IETF. Това беше по-сигурно, използвайки кодове за удостоверяване на съобщенията за проверка на целостта и обмена на ключове Diffie-Hellman за удостоверяване.

През 1999 г. излиза проектът OpenBSD OpenSSH .OpenSSH е безплатна версия на протоколакойто се основава на модификации, направени от Björn Grönvall в SSH 1.1.12. Разработчиците се върнаха към тази по-стара версия и силно я промениха, тъй като това беше последната версия на SSH, която беше с напълно отворен код. OpenSSH вече е най-широко използваната опция и оттогава е внедрена в редица операционни системи, като Windows, macOS, Linux, Solaris и други.

SSH-1 срещу SSH-2 срещу OpenSSH

Както беше отбелязано по-горе, SSH-1 е първата версия на протокола, която първоначално беше пусната под anлиценз с отворен код. Счита се за несигурно и не трябва да се прилага. Това оставя патентованата версия, SSH-2, и свободно достъпната версия, OpenSSH, като жизнеспособни алтернативи.

SSH-2 и OpenSSH са по същество еднакви, що се отнася до тяхната архитектура и как работят. Основната разлика е, че патентованата версия идва с набор от опции за поддръжка, докато тези, които използват OpenSSH, трябва да разчитат на ресурсите, създадени свободно от общността.

SSH: Техническите подробности

SSH-1 функционира като единичен протокол, но няма да навлизаме в него тук, тъй като е остарял. Вместо това ще се съсредоточим върху SSH-2 и OpenSSH, които са съставени от три отделни протокола:

  • Транспортният протокол – Това установява връзката и осигурява основната сигурност.
  • Протоколът за удостоверяване – Този слой се използва за удостоверяване на клиента.
  • Протоколът за свързване – Този протокол управлява каналите, по които се предават данни.

Всеки от тези протоколи изпълнява уникална роля, която работи за установяване и осигуряване на връзка, удостоверяване на другата страна и прехвърляне на данни. Портът за TCP връзка по подразбиране е 22 и връзките се настройват между SSH клиент и SSH сървър по протежение наклиент-сървър модел.

Процесът на отдалечено влизане в SSH протича съгласно следната основна структура (с вариации в зависимост от конфигурацията), която ще разгледаме по-подробно по-късно:

  • Клиентът се свързва със SSH сървъра, за да започне връзката.
  • След това сървърът изпраща публичния си ключ на клиента, за да удостовери неговата самоличност.
  • Двете страни договарят параметрите за връзката, след което установяват защитен канал по тези линии.
  • След това потребителят влиза в операционната система на хоста на сървъра и вече може да администрира своите задачи дистанционно.

Транспортен протокол

Транспортният слой е протокол от ниско ниво, който се грижи за следните задачи.

  • Удостоверяване на хоста на сървъра
  • Размяна на ключове
  • Криптиране за поверителност на данните
  • Проверки за целостта, за да се провери дали данните не са променени
  • Създаване на идентификатор на сесия, който може да се използва в другите протоколи

Theтранспортният протокол удостоверява само сървъра, но не и клиента(удостоверяването на клиента се извършва в протокола за удостоверяване, ако е необходимо).

В транспортния слой връзката се инициира от клиента и двете страни след това преговарят как ще се обменят ключовете, кой алгоритъм за публичен ключ ще се използва, кой шифър със симетричен ключ ще криптира данните, кой алгоритъм за удостоверяване на съобщението ще се използва за проверка на данните и кой метод на компресия (ако има такъв) ще бъде приложен.

След като връзката започне, и сървърът, и клиентът трябва да изпратят идентификационен низ, който включва версията на протокола (2.0).

Алгоритъм за преговори

За да настроите параметрите на връзката, двете страни изпращат чрез пакет, съдържащ списък със следните опции:

байт SSH_MSG_KEXINIT

байт[16] бисквитка (произволни байтове)
списък с имена kex_algorithms
списък с имена server_host_key_algorithms
списък с имена криптиране_алгоритми_клиент_към_сървър
списък с имена encryption_algorithms_сървър_към_клиент
списък с имена mac_algorithms_client_to_server
списък с имена mac_algorithms_server_to_client
списък с имена компресия_алгоритми_клиент_към_сървър
списък с имена, компресия_алгоритми_сървър_към_клиент
списък с имена езици_клиент_към_сървър
списък с имена езици_сървър_към_клиент
булево first_kex_packet_follows
uint32 0 (запазено за бъдещи разширения)

Всяка страна изброява параметрите, които са готови да приемат във връзката, разделени със запетаи. Предпочитаният алгоритъм трябва да бъде посочен първи.

За обмен на ключове (kex_algorithms), първият алгоритъм, който двете страни поддържат, ще бъде избран за връзката (може да има и други фактори, които трябва да бъдат изпълнени, в зависимост от избрания алгоритъм). Ако двете страни не могат да намерят взаимно поддържан алгоритъм, който да отговаря на тези изисквания, тогава връзката е неуспешна.

Ключови алгоритми на сървърния хост са поддържаните алгоритми за хост ключа на сървъра. Сървърът определя алгоритмите, за които има ключове за хост, докато клиентът определя алгоритмите, които е готов да приеме. Изборът ще зависи от това дали методът за обмен на ключове, който е уреден, изисква хост ключ с възможност за криптиране или цифров подпис

И двете страни изброяват алгоритми със симетричен ключ които са склонни да приемат, като предпочитаните методи са в горната част. Трябва да се използва първата опция, която се появява в списъка на клиента, която се намира и в списъка на сървъра. Ако не може да се направи споразумение, връзката се проваля.

И двете MAC алгоритъм и на алгоритъм за компресия се договарят по същия начин.

Размяна на ключове

Обменът на ключове отговаря заудостоверяване на сървъра, и тонастройва ключовете, които ще се използват за защита на връзкатав следващите стъпки. Обикновено започва със страните, които изпращат своите списъци с поддържани алгоритми една на друга. Като алтернатива всяка страна може да познае предпочитания алгоритъм на другата страна и да изпрати пакет, който отговаря на параметрите на този алгоритъм в началото.

Ако предположението на едната страна е правилно, този пакет се използва като първи пакет за обмен на ключове. Ако нито едно предположение не е правилно, тогава всяка страна трябва да направи крачка назад и да изпрати своите списъци с предпочитани алгоритми. Ако съобщението за обмен на ключове включва цифровия подпис на сървъра като доказателство за легитимността на сървъра, се счита, че изрично удостоверяване на сървъра . Ако вместо това използва споделената тайна, тя се нарича имплицитно удостоверяване на сървъра .

Обменът на ключове също отговаря за установяването на споделена тайна и хеш. Хеш стойността от първоначалния обмен на ключове се превръща в уникален идентификатор за сесията и също така се използва като част от цифровите подписи, които доказват, че страната е истинският собственик на своя частен ключ.

Използваната хеш функция ще зависи от метода за обмен на ключове, избран при преговорите. Когато обменът на ключове приключи, всички бъдещи комуникации ще използват новия набор от ключове и алгоритми.

Според Internet Engineering Task Force (IETF) Интернет чернова , следните методи за обмен на ключове се считат за сигурни:

  • curve25519-sha256
  • curve448-sha512
  • diffie-hellman-group-exchange-sha256
  • diffie-hellman-group14-sha256
  • diffie-hellman-group15-sha512
  • diffie-hellman-group16-sha512
  • diffie-hellman-group17-sha512
  • diffie-hellman-group18-sha512
  • ecdh-sha2-nistp256
  • ecdh-sha2-nistp384
  • gss-group14-sha256
  • gss-group15-sha512
  • gss-group16-sha512
  • gss-group17-sha512
  • gss-group18-sha512
  • gss-nistp256-sha256
  • gss-nistp384-sha384
  • gss-nistp521-sha512
  • gss-крива 25519-sha256
  • gss-крива 448-sha512
  • rsa2048-sha256

Алгоритъм за ключ на сървърния хост

Тези алгоритми с публичен ключ се използват заудостоверяване на сървъра, както и за сигурно установяване на идентификатора на споделена сесия. Те могат също така да се използват по желание за удостоверяване на хоста. SSH е проектиран да работи с набор от алгоритми с публичен ключ, типове кодиране и формати:

  • Той използва алгоритми с публичен ключ за криптиране и/или цифрови подписи.
  • Могат да бъдат приложени редица методи за кодиране, позволяващи конфигуриране с различни формати на данни, запълване и ред на байтове.
  • Различните формати на ключове позволяват ключовете да бъдат кодирани по различни начини, както и набор от представяния на сертификати.

Алгоритмите по подразбиране включват следното, но има и други варианти, които също могат да бъдат приложени:

  • ssh-rsa
  • ssh-rsa-sha256
  • ssh-dss
  • ssh-dss-sha256
  • x509v3-знак-dss
  • x509v3-знак-dss-sha256
  • x509v3-знак-rsa
  • x509v3-sign-rsa-sha256

Алгоритми за криптиране

Алгоритмите със симетричен ключ се използват закриптиране на данните и осигуряване на поверителност.Параметрите и споделеният ключ, които се използват в процеса на криптиране, се установяват в по-ранните фази на връзката. Избраният алгоритъм криптира полезния товар, дължината на пакета, дължината на запълването и полетата за запълване.

В SSH се приемат редица различни алгоритми за криптиране, но за целите на сигурността е най-добре да се придържате към AES . Ключовете трябва да са минимум 128-битови, но се предпочитат по-големи ключове.

MAC алгоритми

Транспортният протоколпроверява целостта на данните чрез добавяне на код за удостоверяване на съобщение (MAC) към пакета.Този MAC се основава на споделената тайна (която се установява при обмена на ключове), поредния номер на пакета и съдържанието на пакета. Изчислява се преди криптирането.

Реализациите трябва да предложат независим алгоритъм за изпълнение във всяка посока, въпреки че е идеално, ако един и същ се използва от двете страни. Може да се приложи голямо разнообразие от алгоритми за удостоверяване на съобщенията, но SHA-256 и по-нови трябва да се използват в повечето ситуации, за да се осигури високо ниво на сигурност.

Компресия

Компресията не е задължителна в SSH протокола и нейните реализации трябва да позволяват връзките да продължават без компресия. Компресията може да се реализира само като опция, като се използват схеми като zlib . Ако се използва компресия, това засяга само полезния товар. След това MAC и полето за дължина на пакета се изчисляват въз основа на компресирания полезен товар.

Пакет транспортен протокол

Пакетът на транспортния протокол е форматиран така, че да включва следната информация (както и някои по-малко уместни подробности, които са пропуснати):

  • Дължината на пакета
  • Дължината на подложката
  • Полезният товар
  • Подложка
  • Код за удостоверяване на съобщение (MAC)

ssh-3

Протокол за удостоверяване

Този протокол се използва от сървъра заудостоверяване на клиента.Той може да направи това с множество различни механизми, много от които разчитат на идентификатора на сесията, установен в транспортния протокол. Някои използват криптирането и проверките за интегритет от транспортния протокол във връзка с идентификатора на сесията, докато други използват тези алгоритми сами.

Сървърът използва своята локална политика, за да реши кои методи за удостоверяване приема от отделен потребител. Тъй като сървърът вече е удостоверен в транспортния протокол,няма нужда да удостоверявате сървъра още веднъж.

Сигурността на протокола за удостоверяване зависи от транспортния протокол, върху който той работи. Ако протоколът за транспортиране не може да гарантира поверителността или да провери целостта на данните, това ограничава безопасното използване на протокола за удостоверяване.

Например, ако защитата на интегритета не се прилага от транспортния протокол, тогава заявки като промени на парола не трябва да се разрешават, защото това би оставило възможности на нападателите да се подправят с данните, без да бъдат забелязани.

Протоколът за удостоверяване използва удостоверяване с публичен ключ при предположението, че нито частният ключ на сървърния хост, нито ключът на клиентския хост са били компрометирани.Ако сървърът е бил компрометиран, това може да доведе до предоставяне на потребителското име и паролата на клиента на нападателя.

За да бъде сигурно базираното на хост удостоверяване, клиентът не трябва да бъде компрометиран. Ако това е възможно, тогава трябва да се добавят други методи за удостоверяване. Важно е да се отбележи, че процесът на удостоверяване е толкова силен, колкото и най-слабият метод за обмен, който сървърът приема.

Процесът на протокола за удостоверяване

Протоколът за удостоверяване започва, когато сървърът изпрати на клиента списък с приетите методи за удостоверяване. След това клиентът може да избира от тези методи в произволен ред. Този процес дава контрол на сървъра, но също така позволява достатъчно гъвкавост, така че клиентът да може да организира използването на най-удобния метод.

Най-често срещаните методи за удостоверяване на клиента включват:

  • Публичен ключ – Този метод използва алгоритми като RSA , DSA и ECDSA за удостоверяване на клиента чрез криптография с публичен ключ. Някои реализации също използват x.509 сертификати. Сървърът проверява цифровия подпис на клиента спрямо неговия публичен ключ, за да потвърди самоличността на клиента.
  • Парола – Паролите също могат да се използват за удостоверяване на клиента. Клиентът изпраща своята парола (която трябва да бъде криптирана от транспортния протокол). Ако паролата съвпада със съхранената стойност на сървъра, тя се приема и удостоверяването продължава напред.
  • GSSAPI – При този метод външни схеми като Kerberos могат да се използват за единично влизане.
  • Интерактивна клавиатура – Тази техника осигурява удостоверяване с еднократна парола, като сървърът подканва клиента за информация.

Протокол за свързване

Протоколът за свързване определякак множество канали за данни ще бъдат комбинирани върху защитения транспортен слой. Той също така се занимава с параметрите, които се използват за достъп до защитени подсистеми на хоста на сървъра, както и прокси пренасочване и достъп до обвивки.

Протоколът за свързване се намира над транспортния слой и протоколите за удостоверяване. Позволява дистанционно изпълнение на команди, както и пренасочени X11 и TCP/IP връзки. Ако сървърът или клиентът са били компрометирани, тогава протоколът за връзка не е защитен.

Канали

Каналите са основните пътища за комуникация и могат да бъдат отворени от всяка страна. Каналите могат да включват терминални сесии, пренасочени връзки и други форми на комуникация. Когато има няколко канала, те се мултиплексират в една връзка.

Отваряне на канали

Всеки канал е номериран от двата си края, въпреки че номерата потенциално могат да бъдат различни от двете страни. Когато едната страна поиска отваряне на канал, тя изпраща номера на своя канал като част от съобщението, както и информация за начален размер на прозореца и на максимален размер на пакета .

Първоначалният размер на прозореца показва колко данни може да получи страната, която отваря канала. Ако трябва да се изпратят повече данни, първо трябва да се коригира прозорецът. По същия начин максималният размер на пакета определя колко голям пакет може да бъде получен.

Когато едната страна поиска канал да бъде отворен, другата страна ще отвори канала, ако може да го приеме. Ако не, ще изпрати съобщение за грешка. Каналите може да не се отварят поради следните причини:

  • Забранено от администрацията
  • Неуспешна връзка
  • Неизвестен тип канал
  • Недостиг на ресурси

Ако някоя от страните на връзката иска да изпрати повече данни, отколкото позволява прозорецът в момента, те могат да изпратят съобщение с искане за добавяне на още байтове.

Затваряне на канали

След като едната страна на връзката завърши предаването на данни, тя трябва да изпрати съобщение, показващо, че е приключила с използването на канала. Въпреки това каналът остава отворен и данните все още могат да се изпращат от другата страна. Ако дадена страна иска напълно да прекрати канала, тя го прави с отделно съобщение за прекратяване.

SSH сигурност

Всяка от различните версии на SSH има свои собствени проблеми със сигурността, въпреки че текущите конфигурации наSSH-2 и OpenSSH се считат за много по-безопасни от SSH-1.

SSH-1

SSH-1 обикновено се счита за дефектен, с набор от различни уязвимости. Те включват грешка в SSH 1.5, която позволява на неоторизирани потребители да вмъкват съдържание в SSH потока от данни. Тази атака се възползва от минималната защита на целостта на данните на алгоритъма CRC-32.

Тази атака беше смекчена с SSH Compensation Attack Detector, който беше интегриран в повечето по-нови реализации. Тази корекция дойде с нова уязвимост, която имаше силата да изпълнява произволен код с root права.

Има и уязвимост, която позволява на противниците да променят последния блок в сесия, която използва IDEA-криптиране, както и такава, която позволява на компрометиран сървър да препрати процеса на удостоверяване на клиента към различен сървър.

Поради тези проблеми със сигурността вместо това трябва да се използва SSH-2. За да запазите внедряването си сигурно, трябва също забранете предоговарянето към SSH-1 , защото атаките могат да се възползват от това, за да получат достъп до вашите данни чрез по-слабото ниво на защита на SSH-1.

SSH-2

SSH-2 е уязвим на теоретична атака срещу неговия режим на криптиране по подразбиране, CBC. Той позволява на атакуващия да възстанови до 32 бита от обикновения текст от криптиран блок. Това може да бъде смекчено чрез използване на режим на брояч (CTR) и превръщане на блоковия шифър в поточен шифър вместо това.

В края на 2014г. Огледалото публикува документи на NSA, които намекват, че NSA понякога може да наруши SSH. Изтекъл PowerPoint на NSA се казва, че NSA може да „Потенциално възстановяване на потребителски имена и пароли“, въпреки че не се дават повече подробности. Не е известно какви методи е използвала агенцията, за да направи това, но изглежда малко вероятно тя да излъже за възможностите си в собствената си вътрешна документация.

През 2017 г Изтичане на Vault 7 , стана ясно, чеЦРУ разполагаше с два инструмента, които можеха да се използват за прихващане и кражба на SSH влизания и пароли. BothanSpy е насочен към Windows Xshell клиенти, докато Gyrfalcon е използван срещу OpenSSH клиента на редица различни Linux дистрибуции.

Тези инструменти са в състояние да откраднат идентификационни данни и след това да ги предадат обратно на сървър на ЦРУ. Нито една от тези атаки не може да наруши самия протокол; те просто използват други странични канални атаки, които могат да го заобиколят в определени реализации.

Въпреки тези атаки, SSH-2 се счита за сигурен в повечето ситуации, стига да е внедрен по подходящ начин. Целите с висока стойност или тези, които използват остарели или лоши реализации, трябва да обмислят други опции.

OpenSSH

В OpenSSH версия 2,ан атака беше открито, че се възползва от слабост в SSH двоичния пакет. Атаката позволи на изследователи от Лондонския университет да възстановят 14 бита от обикновен текст от криптиран блок. Това беше смекчено във версия 5.2, като накара протокола да прочете цялата невалидна дължина на пакет или код за удостоверяване на съобщение, вместо да прекратява връзката.

Във версии 6.8 и 6.9 Linux може да се използва за изпълнение на произволни команди на терминалите на други потребители. Това беше постигнато чрез уязвимост при ескалация на привилегии, която позволи на нападателите да инжектират знаци с контрола за вход/изход TIOCSTI.

Безопасен ли е SSH?

Въпреки че може да изглежда, че SSH има много проблеми със сигурността,относително еy нормално е да се открият редица уязвимости в различните реализации на протокола. Това не означава, че SSH протоколът не е безопасен. Вместо това, това просто означава товатрябва да се приложи правилно.

Стига да използвате едно от дветеSSH-2 или OpenSSH и е конфигуриран по начин, който е подходящ за вашата употреба, трябва да се чувствате уверени в защитата, която SSH осигурява на вашата връзка. Ето защо той все още е толкова често използван протокол, особено за целите на отдалечен достъп и тунелиране.

Вижте също: Обяснени са често срещаните типове криптиране

Технологичен фон на кибернетичната мрежа от TheDigitalArtist, лицензиран под CC0

^