SSH: Сигурна обвивка

SSH означава Secure Shell. Известен е още като Secure Socket Shell. Криптографски мрежов протокол, наречен Secure Shell (SSH), се използва за безопасно управление на мрежови услуги в несигурни мрежи. Архитектурата на клиентския сървър е в основата на SSH приложенията, които свързват екземпляр на SSH клиент със SSH сървър.

Като наследник на Telnet и опасни отдалечени Unix shell протоколи като Berkeley Remote Shell (rsh) и свързаните с него протоколи rlogin и rexec, SSH е създаден за Unix-подобни операционни системи, които използват несигурна комуникация с токени за удостоверяване в обикновен текст.

Определение

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

sql подреждане по дата

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

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

Създаване

Tatu Ylönen, компютърен учен от Финландия, създаде SSH за първи път през 1995 г. По-нататъшното развитие на протоколния пакет се проведе в много групи разработчици, което доведе до различни повторения на внедряване. Има налични реализации за всички популярни операционни системи, включително вградени системи. OpenSSH, който създателите на OpenBSD направиха достъпен като софтуер с отворен код през 1999 г., е най-често използваният софтуерен стек.

Управление на OpenSSH ключове за удостоверяване

Списъкът с одобрени публични ключове обикновено се съхранява на Unix-подобни системи във файла ~/.ssh/authorized keys в домашната директория на потребителя, който има привилегии за отдалечено влизане. SSH зачита този файл само ако не може да бъде модифициран от никой друг освен собственика и root. Паролата вече не е необходима, когато присъстват както публичният ключ на отдалечения край, така и съответстващият частен ключ на локалния край. Но можем да използваме парола, за да заключим частния ключ за много по-голяма защита. Можем също така да търсим тайния код в често срещани местоположения и можем да използваме опция от командния ред, за да предоставим пълния му път (опция -i за ssh).

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

Използвайте

SSH използва парадигмата клиент-сървър. Обикновено SSH се използва за регистриране. Може също така да тунелира TCP портове, да препраща X11 връзки и да изпълнява команди на отдалечена система. Обикновено връзките към SSH демон, позволяващи отдалечени връзки, се правят с помощта на SSH клиентско приложение. И двете често се срещат в повечето съвременни операционни системи, като macOS, Linux дистрибуции, OpenBSD, FreeBSD, NetBSD, Solaris и OpenVMS. Някои версии са патентовани, безплатни и с отворен код с различна степен на сложност и изчерпателност (като PuTTY и версията на OpenSSH, включена в Cygwin и OpenSSH). Трябва да се отбележи, че SSH не е включен по подразбиране във версиите на Windows до Windows 10 версия 1709.

Подобна функция за управление на файлове (синхронизиране, копиране и отдалечено изтриване) се предлага от безплатното Windows приложение с отворен код WinSCP, което използва PuTTY като back-end. Без да е необходимо да бъдат инсталирани на клиентския компютър, WinSCP и PuTTY са налични пакетирани за работа директно от USB устройство. Активирането на функция в приложението за настройки често се изисква за настройка на SSH сървър в Windows.

За да се справи с проблемите с връзката и да предотврати рисковете за сигурността от директното излагане на облачна виртуална машина на интернет, SSH е от решаващо значение в облачните изчисления. Сигурна връзка през Интернет може да бъде възможна чрез SSH тунелен виртуален компютър чрез защитна стена. За този протокол IANA е определила TCP порт 22, UDP порт 22 и SCTP порт 22.

Още през 2001 г. IANA класифицира TCP порта по подразбиране 22 за SSH сървъри като един от добре познатите портове. Протоколът за транспортно ниво SCTP, ориентиран към връзката, може да се използва за изпълнение на SSH вместо TCP.

Историческа прогресия

Итерация 1

Нападение с парола срещу мрежата на неговата институция вдъхнови Тату Юльонен, изследовател от Хелзинкския технологичен университет във Финландия, който създаде първоначалната итерация на протокола (днес известен като SSH-1) през 1995 г.

SSH е проектиран да поеме ролята на предишни протоколи, включително rlogin, TELNET, FTP и rsh, на които липсваше стабилно удостоверяване и гаранции за секретност. Ylönen направи приложението си достъпно като безплатен софтуер. През юли 1995 г. устройството бързо се харесва. До края на 1995 г. имаше 20 000 SSH потребители в 50 различни нации.

За да популяризира и усъвършенства SSH, Ylönen създаде SSH Communications Security през декември 1995 г. Различни безплатни софтуерни компоненти, включително GNU libgmp, бяха използвани в първото издание на програмата SSH, но по-късните итерации, предоставени от SSH Communications Security, прераснаха във все по-собствен софтуер. Според оценки до 2000 г. е имало 2 милиона потребители.

Итерация 2

Internet Engineering Task Force (IETF) определи работната група, отговорна за създаването на SSH протокол версия 2 като „Secsh“ в своята официална документация.

SSH-2, подобрена итерация на протокола, стана стандарт през 2006 г. SSH-1 не е съвместим с тази версия. SSH-2 предлага функционалност и подобрения на сигурността спрямо SSH-1. Например обменът на ключове Diffie-Hellman и стабилната проверка на целостта чрез кодове за удостоверяване на съобщения осигуряват по-висока сигурност. Възможността за работа с неограничен брой сесии на обвивка през една SSH връзка е една от новите възможности на SSH-2. Тъй като SSH-2 е по-напреднал и широко използван от SSH-1, определени реализации, като libssh (v0.8.0+), Lsh и Dropbear, поддържат само SSH-2.

Итерация 1.99

RFC 4253 изисква SSH сървър, поддържащ 2.0, както и по-ранни версии, да посочва своята версия на протокола като 1.99 през януари 2006 г., много след разработката на версия 2.1. Този номер на версията се използва за посочване на обратна съвместимост, а не за представяне на предишна версия на софтуера.

java булев низ

OSSH и OpenSSH

Откакто последната версия на оригиналната SSH програма, версия 1.2.12, беше разпространена под лиценз с отворен код през 1999 г., разработчиците работят върху версия на безплатен софтуер. Това беше използвано като основа за OSSH програмата на Björn Grönvall. Скоро след това екипът на OpenBSD клонира работата на Grönvall, за да произведе OpenSSH, който беше включен в OpenBSD Release 2.6. Те създадоха клон за „преносимост“ от тази версия, за да прехвърлят OpenSSH към различни операционни системи.

Най-широко използваната реализация на SSH от 2005 г. беше OpenSSH, версията по подразбиране в много дистрибуции на операционни системи. След премахване на поддръжката на SSH-1 от кодовата база в изданието OpenSSH 7.6, OpenSSH все още се актуализира и поддържа протокола SSH-2. Междувременно OSSH вече не е от значение.

Употреби

Потребителят 'josh' 'SSHed' от локалния компютър 'foo fighter' към отдалечената машина 'tengwar', за да изпълни xeyes като пример за тунелиране на X11 програма през SSH. Хората използват Windows SSH клиент PuTTY за достъп до OpenWrt.

статичен в c

SSH е протокол, който работи с много системи, включително Microsoft Windows и повечето варианти на Unix (Linux, BSD, включително macOS на Apple и Solaris). Следните приложения може да се нуждаят от възможности, които са изключителни или съвместими с определени SSH клиенти или сървъри. Например, в момента е възможно само да се използва OpenSSH сървър и клиентска реализация на SSH протокола за изграждане на VPN.

• За достъп до обвивка на отдалечен хост (заместване на Telnet и rlogin)
• За изпълнение на отделна команда на отдалечен хост (заместване на rsh)
• За конфигуриране на автоматизирано влизане (без парола) на отдалечен сървър (например с помощта на OpenSSH)
• Като напълно функционален криптиран VPN имайте предвид, че само OpenSSH клиент и сървър поддържат тази възможност.
• За предаване на X от отдалечен хост (възможно чрез множество междинни хостове)
• За използване на SSH клиенти, които поддържат протокола SOCKS за сърфиране в интернет през криптирана прокси връзка.
• За безопасно монтиране на директория на отдалечен сървър като файлова система на локална машина, използваща SSHFS.
• Чрез една или повече от технологиите, споменати по-горе, за автоматично наблюдение и администриране на отдалечен сървър.
• За SSH-съвместима разработка на мобилни или вградени устройства.
• За защита на механизмите за прехвърляне на файлове.

Методи за прехвърляне на файлове

Няколко системи за прехвърляне на файлове използват протоколи Secure Shell, като напр

• През SSH, защитеното копиране (SCP) е разработено от протокола RCP.
• rsync, който се предполага, че е по-ефективен от SCP, често се управлява чрез SSH връзка.
• Алтернатива на FTP, която е безопасна, е SSH File Transfer Protocol (SFTP) (да не се бърка с FTP през SSH или FTPS)
• FISH, или файлове, прехвърлени през протокола на обвивката, беше въведен през 1998 г. и разработен от SSH през инструкции на обвивката на Unix.
• Aspera, известен също като бърз и сигурен протокол (FASP), използва SSH за команда и за пренос на данни, UDP портове.

Архитектура

Три отделни компонента съставляват многослойната архитектура на SSH протокола:

• Протоколът за контрол на предаването (TCP) на TCP/IP обикновено се използва от транспортния слой (RFC 4253), като порт номер 22 е отделен като порт за слушане на сървър. Този слой прилага криптиране, компресиране, проверка на целостта, първоначален обмен на ключове и удостоверяване на сървъра. Въпреки че всяка реализация може да позволи повече, тя излага на по-високия слой интерфейс за предаване и получаване на пакети с обикновен текст до 32 768 байта всеки. Обикновено, след като 1 GB данни бъдат транспортирани или след като измине един час, което от двете настъпи първо, транспортният слой организира повторен обмен на ключове.
  
• Удостоверяването на клиента се извършва чрез слоя за удостоверяване на потребителя (RFC 4252), който също предлага няколко техники за удостоверяване. Удостоверяването, управлявано от клиента, означава, че SSH клиентът, а не сървърът, може да поиска от потребителя парола. Само заявките на клиента за удостоверяване получават отговор от сървъра. Често се използват следните техники за удостоверяване на потребителя:
  Парола, проста техника за удостоверяване на парола, която включва възможност за промяна на паролата. Не всеки софтуер използва тази техника.
• Обикновено поддържа поне DSA, ECDSA или RSA ключови двойки, публичен ключ е техника за удостоверяване, базирано на публичен ключ. Други реализации допълнително приемат X.509 сертификати.
Клавиатура-интерактивна(RFC 4256) е гъвкава техника, при която сървърът предоставя една или повече подкани за въвеждане на информация, клиентът ги показва и след това изпраща обратно отговорите, които клиентът е въвел. Използва се от някои настройки на OpenSSH за ефективно предлагане на удостоверяване с парола, когато PAM е основният доставчик на удостоверяване на хост, който понякога може да попречи на влизането с клиент, който поддържа само техниката за удостоверяване с проста парола.
• Функционалността за единично влизане за SSH сесии се предоставя чрез GSSAPI техники за удостоверяване, които предлагат разширяема система за обработка на SSH удостоверяване с помощта на външни механизми като Kerberos 5 или NTLM. Въпреки че OpenSSH има функционална реализация на GSSAPI, комерсиалните SSH реализации често интегрират тези техники за използване в компании.
• Идеята за канали, които дефинират предлаганите SSH услуги, се определя от нивото на свързване (RFC 4254). Можем да мултиплексираме множество SSH връзки от една. И двете предават данни в двете посоки. Заявките за канал предават данни извън обхвата, специфични за даден канал, като код за изход на процес от страна на сървъра или промяна на размера на прозореца на терминала. Освен това, използвайки размера на прозореца за получаване, всеки канал контролира своя поток. SSH клиентът прави глобална заявка за препращане на порт от страната на сървъра. Типовете канали, които са често срещани, включват:
  • Обвивка за SFTP, exec и терминални обвивки (включително SCP трансфери)
  • Direct-TCPIP за пренасочени връзки от клиента към сървъра.
  • Пренасочени връзки от сървър към клиент с помощта на forwarded-tcpip
  • За да потвърди легитимността на хоста, SSHFP DNS записът (RFC 4255) предлага пръстови отпечатъци на публичния хост ключ.

Благодарение на отворения му дизайн, можем да използваме SSH за широк спектър от задачи в допълнение към осигуряването на черупки, което му придава голяма гъвкавост.

Уязвимости

SSH-1

Поради неадекватна защита на целостта на данните, осигурена от CRC-32 в тази версия на протокола, през 1998 г. беше идентифицирана уязвимост в SSH 1.5, която позволи неоторизирано вмъкване на материал в криптиран SSH поток. В повечето реализации те добавиха корекция, известна като SSH Compensation Attack Detector. Няколко от тези ревизирани реализации включваха нов недостатък на целочислено препълване, позволяващ на атакуващите да изпълняват произволен код с root или възможностите на SSH демона.

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

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

Възстановяване на обикновен текст за CBC

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

NSA заподозряно в декриптиране

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