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

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

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

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

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

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

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

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

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

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

Препращане на порт

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

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

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

Тунели

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

Протоколите за тунелиране обвиват критични пакети вътре в полезния товар на друг пакет. 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 публикува и интернет чернова на IETF (Internet Engineering Task Force) документира протокола SSH-1. Ограниченията скоро бяха открити в протокола и те не могат да бъдат адресирани, без това да засегне съвместимостта назад. Решението беше нова версия на протокола, а SSH-2 беше лансиран от компанията на Ylönen през 1996г.

SSH-2 представи нови алгоритми, които подтикнаха IETF да създаде работна група, която имаше за цел да стандартизира протокола. Групата получи прякор SECSH, за секундаЧасовници Shell, и тя публикува първия си Интернет проект за 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 е първата версия на протокола, която първоначално беше пусната под лиценз с отворен код. Счита се за несигурен и не трябва да се прилага. Това оставя патентованата версия, SSH-2 и свободно достъпната версия, OpenSSH, като приложими алтернативи.

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

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

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

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

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

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

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

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

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

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

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

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

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

Преговаряне на алгоритъм

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

байт SSH_MSG_KEXINIT

байт [16] бисквитка (произволни байтове)
списък с имена kex_algorithms
списък с имена server_host_key_algorithms
списък с имена encryption_algorithms_client_to_server
списък с имена encryption_algorithms_server_to_client
списък с имена mac_algorithms_client_to_server
списък с имена mac_algorithms_server_to_client
списък с имена compression_algorithms_client_to_server
списък с имена compression_algorithms_server_to_client
списък с имена languages_client_to_server
списък с имена languages_server_to_client
boolean first_kex_packet_follow
uint32 0 (запазено за бъдещо разширение)

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

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

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

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

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

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

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

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

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

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

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

• curve25519-SHA256
• curve448-sha512
• Diffie-Hellman-група-обмен-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-curve25519-SHA256
• GSS-curve448-например sha512
• rsa2048-SHA256

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

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

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

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

• SSH-RSA
• SSH-RSA-SHA256
• SSH-DSS
• SSH-DSS-SHA256
• x509v3-знак-DSS
• x509v3-знак-DSS-SHA256
• x509v3-знак-RSA
• x509v3-знак-RSA-SHA256

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

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

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

MAC алгоритми

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

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

компресия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Публичен ключ – Този метод използва алгоритми като 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 бита от незабележимия текст от криптиран блок. Това може да бъде смекчено чрез използване на режим Counter (CTR) и превръщането на блоковия шифър в поточен шифър вместо това.

В края на 2014 г. Der Spiegel пусна документите на NSA, които предполагаха, че НСА понякога може да счупи SSH. Това изтече NSA PowerPoint гласи, че NSA може да “Възможно възстановяване на потребителски имена и пароли, Въпреки че не са дадени повече подробности. Не е известно какви методи е използвала агенцията за това, но изглежда малко вероятно тя да се крие за възможностите си в собствената си вътрешна документация.

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

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

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

OpenSSH

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

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

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

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

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

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

Технология на кибер мрежата от TheDigitalArtist, лицензиран съгласно CC0