Що таке SSH і як він працює?

Secure Шell (SSH) – це широко реалізований протокол безпеки, що має різноманітне використання. Його найвідоміший додаток дозволяє користувачам безпечно отримувати доступ до віддалених комп’ютерів та серверів, але він також може бути використаний для тунелювання, переадресації портів, безпечної передачі файлів тощо.

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

SSH складається з трьох окремих протоколів: транспортний шар, рівень аутентифікації та шар з’єднання. Разом вони служать для аутентифікації іншої сторони у з’єднанні, надання конфіденційності за допомогою шифрування та перевірки цілісності даних. Зараз SSH найчастіше реалізується як власний SSH-2, або як ітерація з відкритим кодом, OpenSSH.

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

SSH – універсальний протокол. Його структура та функції безпеки дозволяють використовувати його різними способами, наприклад, для віддаленого доступу, переадресації портів, тунелювання та безпечної передачі файлів.

Віддалений доступ

Віддалений доступ дає користувачам можливість увійдіть на інший комп’ютер або сервер з власної машини. Він використовується для доступу до локальних файлів цільової машини або для виконання служб на ній, не потребуючи фізичного перебування там.

Такі програми, як Telnet і rlogin, також мають цю функціональність, але їм відсутні функції безпеки SSH. Заходи шифрування та аутентифікації, що беруть участь у SSH, дозволяють користувачам захищати підключення до іншого сервера чи комп’ютера навіть через потенційно небезпечну проміжну мережу.

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

Експедиція портів

Переадресація портів використовується для передачі запитів з однієї адреси та номера порту на інший набір. Він застосовує трансляцію мережевих адрес (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 був розроблений в Гельсінському технологічному університеті в 1995 році Тату Іллонен у відповідь на атаку обнюху паролем в мережі університету. Він мав на меті надати альтернативу подібним протоколам FTP, TELNET, rsh і rlogin, які не забезпечили конфіденційність та не підтвердили автентифікацію користувачів безпечним способом.

SSH був випущений безкоштовно для публіки в 1995 році і був добре сприйнятий. На тлі швидкого прийняття до кінця того ж року Іллонен заснував SSH Communications Security, щоб продовжити розвиток та комерціалізувати SSH.

У 1995 році Ylönen також опублікував проект проекту Internet Internet 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 є першою версією протоколу, яка спочатку була випущена у версії ліцензія з відкритим кодом. Це вважається незахищеним, і його не слід застосовувати. Це залишає власну версію, 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] cookie (випадкові байти)
список імен 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
булева first_kex_packet_follow
uint32 0 (зарезервовано для майбутнього розширення)

Кожна сторона перераховує параметри, які вони готові прийняти у зв’язку, розділені комами. Переважний алгоритм слід вказати першим.

Для обмін ключами (kex_algorithms), перший алгоритм, який підтримують обидві сторони, буде обраний для з’єднання (можуть бути й інші фактори, які потрібно задовольнити, залежно від того, який алгоритм був обраний). Якщо дві сторони не можуть знайти алгоритм, що підтримується взаємно, що задовольняє цим вимогам, то з’єднання не вдається.

Алгоритми хост-сервера ключів – це підтримувані алгоритми для ключа хоста сервера. Сервер викладає алгоритми, для яких є хост-ключі, а клієнт визначає алгоритми, які він готовий прийняти. Вибір буде залежати від того, чи потрібен метод обміну ключами, який було встановлено, хост-ключ, здатний шифрувати, або цифровий підпис

Обидві сторони перераховують алгоритми симетричного ключа що вони готові прийняти, з кращими методами вгорі. Перший варіант, який з’являється у списку клієнтів, який також є у списку сервера, повинен бути використаний. Якщо домовленості неможливо укласти, з’єднання не вдасться.

І те, і інше MAC алгоритм і алгоритм стиснення узгоджуються однаково.

Обмін ключами

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

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

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

Хеш-функція, яка буде використовуватися, буде залежати від методу обміну ключами, визначеного в ході переговорів. Коли обмін клавішами завершений, усі майбутні комунікації використовуватимуть новий набір ключів та алгоритмів.

Згідно з проектом Internet Internet Task Force (IETF), такі ключові методи обміну вважаються безпечними:

• крива25519-sha256
• крива448-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-curve25519-sha256
• gss-curve448-sha512
• rsa2048-sha256

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

Ці алгоритми відкритого ключа використовуються для автентифікація сервера, а також надійне встановлення ідентифікатора спільного сеансу. Вони також можуть бути додатково використані для аутентифікації хоста. SSH призначений для роботи з низкою алгоритмів відкритих ключів, типів і форматів кодування:

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

Алгоритми за замовчуванням включають наступне, однак є деякі інші варіанти, які також можна реалізувати:

• шш-рса
• 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, і його реалізація повинна дозволяти з’єднанням проходити без стиснення. Стиснення можна реалізувати лише як варіант, використовуючи такі схеми зліб. Якщо використовується стиснення, це впливає лише на корисне навантаження. Потім MAC і поле довжини пакета обчислюються на основі стисненого корисного навантаження.

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

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

• Довжина пакета
• Довжина оббивки
• Корисне навантаження
• Прокладки
• Код автентифікації повідомлення (MAC)

Протокол аутентифікації

Цей протокол використовується сервером для аутентифікувати клієнта. Це можна зробити за допомогою різних механізмів, багато з яких покладаються на ідентифікатор сеансу, встановлений у транспортному протоколі. Одні використовують перевірку шифрування та цілісності з транспортного протоколу спільно з ідентифікатором сеансу, а інші використовують ці алгоритми самостійно.

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

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

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

Протокол аутентифікації використовує аутентифікацію відкритого ключа за умови, що ні приватний ключ хоста сервера, ні ключ хоста клієнта не були порушені. Якщо сервер був порушений, це може призвести до того, що ім’я користувача та пароль клієнта будуть звільнені до зловмисника.

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

Процес протоколу аутентифікації

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

Найпоширеніші методи аутентифікації клієнтів включають:

• Публічний ключ – Цей метод використовує алгоритми, такі як RSA, DSA та ECDSA для аутентифікації клієнта за допомогою криптографії відкритого ключа. У деяких реалізаціях також використовуються сертифікати x.509. Сервер перевіряє цифровий підпис клієнта відповідно до їх відкритого ключа, щоб перевірити його особу.
• Пароль – Паролі також можна використовувати для автентифікації клієнта. Клієнт надсилає свій пароль (який повинен бути зашифрований транспортним протоколом). Якщо пароль відповідає збереженому значенню сервера, він приймається і автентифікація рухається вперед.
• GSSAPI – За цим методом зовнішні схеми, такі як Kerberos, можуть використовуватися для одноразового входу.
• Клавіатура інтерактивна – Ця методика забезпечує одноразову автентифікацію пароля за допомогою сервера підказувати клієнту інформацію.

Протокол підключення

Визначається протокол з’єднання як декілька каналів даних будуть об’єднані через захищений транспортний рівень. Він також стосується параметрів, які використовуються для доступу до захищених підсистем на хості сервера, а також для переадресації проксі та доступу до оболонок.

Протокол з’єднання розташований поверх транспортного рівня та протоколів аутентифікації. Це дозволяє віддалене виконання команд, а також переадресовані X11 і TCP / IP з’єднання. Якщо сервер чи клієнт були порушені, протокол з’єднання не захищений.

Канали

Канали – це основні шляхи спілкування, і їх може відкривати будь-яка сторона. Канали можуть включати термінальні сеанси, переадресовані з’єднання та інші форми зв’язку. Коли є кілька каналів, вони мультиплексуються в одне з’єднання.

Відкриття каналів

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

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

Коли одна сторона вимагає відкриття каналу, інша сторона відкриє канал, якщо зможе вмістити його. Якщо ні, він надсилатиме повідомлення про помилку. Не вдалося відкрити канали з наступних причин:

• Заборонено адміністрацією
• Помилка з’єднання
• Невідомий тип каналу
• Нестача ресурсів

Якщо будь-яка сторона з’єднання хоче надіслати більше даних, ніж це дозволяє вікно, вони можуть надіслати повідомлення з проханням додати більше байтів.

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

Після того, як одна сторона з’єднання завершить передачу даних, вона повинна надіслати повідомлення, яке вказує, що воно закінчило використання каналу. Незважаючи на це, канал залишається відкритим, а дані все ще можуть надсилати інші сторони. Якщо сторона хоче повністю припинити канал, це робить це окремим повідомленням про припинення.

Безпека SSH

У кожної з різних версій SSH були свої проблеми безпеки, хоча поточні конфігурації SSH-2 і OpenSSH вважаються набагато безпечнішими, ніж SSH-1.

СШ-1

SSH-1, як правило, вважається помилковим, з низкою різних вразливостей. Сюди входить помилка в SSH 1.5, яка дозволила стороннім користувачам вставляти вміст у потік даних SSH. Ця атака скористалася мінімальним захистом цілісності даних алгоритму CRC-32.

Ця атака була пом’якшена за допомогою детектора атаки компенсації SSH, який був інтегрований у більшість нових реалізацій. Це виправлення отримало нову вразливість, яка мала право виконувати довільний код з привілеями root.

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

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

СШ-2

SSH-2 вразливий до теоретичної атаки проти режиму шифрування за замовчуванням CBC. Це дозволяє зловмиснику відновити до 32 біт простого тексту з зашифрованого блоку. Це можна зменшити, використовуючи режим лічильника (CTR) та перетворивши блоковий шифр на потоковий шифр.

Наприкінці 2014 року Дер Шпігель опублікував документи АНБ, які передбачали, що НСА може іноді зламати СШ. Цей витік NSA PowerPoint стверджує, що АНБ може “Потенційно відновити імена користувачів та паролі, Хоча більше деталей не наводиться. Невідомо, якими методами користувалося це агентство, але здається малоймовірним, що він би лежав про свої можливості у власній внутрішній документації.

У 2023 році витік Vault 7 було виявлено, що ЦРУ мала два інструменти, які можна було використовувати для перехоплення та викрадення SSH логінів та паролів. BothanSpy орієнтований на клієнтів Windows Xshell, а Gyrfalcon використовувався проти клієнта OpenSSH у ряді різних дистрибутивів Linux.

Ці інструменти здатні красти дані та потім передавати їх назад на сервер ЦРУ. Жодна з цих атак не може порушити сам протокол; вони просто використовують інші атаки бічних каналів, які можуть обійти його в певних реалізаціях.

Незважаючи на ці напади, 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