SSH: безпечна оболонка

SSH означає Secure Shell. Він також відомий як Secure Socket Shell. Криптографічний мережевий протокол під назвою Secure Shell (SSH) використовується для безпечної роботи мережевих служб у незахищених мережах. Архітектура клієнт-сервера є основою програм SSH, які зв’язують примірник клієнта SSH із сервером SSH.

Як наступник протоколів Telnet і небезпечних віддалених протоколів оболонки Unix, таких як Berkeley Remote Shell (rsh) і пов’язаних з ним протоколів rlogin і rexec, SSH було створено для Unix-подібних операційних систем, які використовують незахищений обмін токеном автентифікації в відкритому вигляді.

Визначення

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

історія в java

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

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

Створення

Тату Юленен, комп’ютерний вчений із Фінляндії, вперше створив SSH у 1995 році. Подальший розвиток набору протоколів відбувався багатьма групами розробників, що призвело до різноманітних ітерацій впровадження. Є реалізації, доступні для всіх популярних операційних систем, включаючи вбудовані системи. OpenSSH, який творці OpenBSD зробили доступним як програмне забезпечення з відкритим кодом у 1999 році, є найбільш часто використовуваним програмним стеком.

Керування ключами OpenSSH для автентифікації

Схвалений список відкритих ключів зазвичай зберігається в Unix-подібних системах у файлі ~/.ssh/authorized keys у домашньому каталозі користувача, який має права віддаленого входу. SSH поважає цей файл, лише якщо його не може змінити ніхто, крім власника та кореня. Пароль більше не потрібен, якщо присутні як відкритий ключ віддаленої сторони, так і відповідний закритий ключ локальної сторони. Але ми можемо використовувати парольну фразу для блокування закритого ключа для більшого захисту. Ми також можемо шукати секретний код у звичайних місцях, і ми можемо використовувати параметр командного рядка, щоб надати його повний шлях (параметр -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.

Подібні функції керування файлами (синхронізація, копіювання та віддалене видалення) пропонуються безкоштовною програмою WinSCP із відкритим кодом для Windows, яка використовує PuTTY як серверну частину. Без необхідності встановлення на клієнтському комп’ютері 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, Юленен заснував SSH Communications Security у грудні 1995 року. У першому випуску програми SSH використовувалися різноманітні компоненти вільного програмного забезпечення, включаючи GNU libgmp, але пізніші ітерації, надані SSH Communications Security, перетворилися на все більш пропрієтарне програмне забезпечення. За оцінками, до 2000 року було 2 мільйони користувачів.

Ітерація 2

Інженерна робоча група Інтернету (IETF) у своїй офіційній документації назвала робочу групу, відповідальну за створення протоколу SSH версії 2, «Secsh».

SSH-2, вдосконалена ітерація протоколу, стала стандартом у 2006 році. SSH-1 несумісний із цією версією. SSH-2 пропонує оновлення функціональності та безпеки порівняно з SSH-1. Наприклад, обмін ключами Діффі-Хеллмана та надійна перевірка цілісності за допомогою кодів автентифікації повідомлень забезпечують вищий рівень безпеки. Можливість працювати з необмеженою кількістю сеансів оболонки через одне з’єднання 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. Цей номер версії використовується для позначення зворотної сумісності, а не для представлення попередньої версії програмного забезпечення.

10 степень 6

OSSH і OpenSSH

Оскільки остання версія оригінальної програми SSH, версія 1.2.12, була розповсюджена за ліцензією з відкритим кодом у 1999 році, розробники працюють над безкоштовною версією програмного забезпечення. Це було використано як основу для програми OSSH Бйорна Грьонвалля. Незабаром після цього команда OpenBSD клонувала роботу Грьонвалла для створення OpenSSH, який був включений у випуск OpenBSD 2.6. Вони створили гілку «переносимості» з цієї версії, щоб перенести OpenSSH на різні операційні системи.

Найпоширенішою реалізацією SSH на 2005 рік був OpenSSH, версія за замовчуванням у багатьох дистрибутивах операційних систем. Після видалення підтримки SSH-1 із кодової бази у випуску OpenSSH 7.6 OpenSSH усе ще оновлюється та підтримує протокол SSH-2. Тим часом ОСШ вже не актуальний.

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

Користувач 'josh' 'SSHed' від локального комп'ютера 'foo fighter' до віддаленої машини 'tengwar', щоб запустити xeyes як приклад тунелювання програми X11 через SSH. Люди використовують клієнт Windows SSH PuTTY для доступу до OpenWrt.

як центрувати зображення на css

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

• Щоб отримати доступ до оболонки на віддаленому хості (замінюючи Telnet і rlogin)
• Для виконання одиночної команди на віддаленому хості (заміна rsh)
• Для налаштування автоматичного (без пароля) входу на віддалений сервер (наприклад, за допомогою OpenSSH)
• Оскільки це повнофункціональна зашифрована VPN, майте на увазі, що лише клієнт і сервер OpenSSH підтримують цю можливість.
• Для передачі X від віддаленого хоста (можливо через кілька проміжних хостів)
• Для використання клієнтів SSH, які підтримують протокол SOCKS, для перегляду Інтернету через зашифроване проксі-з’єднання.
• Для безпечного монтування каталогу віддаленого сервера як файлової системи на локальній машині за допомогою SSHFS.
• За допомогою однієї або кількох згаданих вище технологій для автоматичного віддаленого моніторингу й адміністрування сервера.
• Для розробки мобільних або вбудованих пристроїв, сумісних із SSH.
• Для захисту механізмів передачі файлів.

Методи передачі файлів

Кілька систем передачі файлів використовують протоколи Secure Shell, такі як

• Через SSH, Secure Copy (SCP) розроблено на основі протоколу RCP.
• rsync, який має бути більш ефективним, ніж SCP, часто працює через з’єднання SSH.
• Безпечною альтернативою FTP є протокол передачі файлів SSH (SFTP) (не плутати з FTP через SSH або FTPS)
• FISH, або файли, що передаються через протокол оболонки, був представлений у 1998 році та розроблений на основі інструкцій оболонки SSH через Unix.
• Aspera, також відомий як швидкий і безпечний протокол (FASP), використовує SSH для команд і для транспортування даних, порти UDP.

Архітектура

Три різні компоненти складають багаторівневу архітектуру протоколу SSH:

• Протокол керування передачею (TCP) TCP/IP зазвичай використовується на транспортному рівні (RFC 4253), з портом номер 22, виділеним як порт прослуховування сервера. Цей рівень реалізує шифрування, стиснення, перевірку цілісності, початковий обмін ключами та автентифікацію сервера. Хоча кожна реалізація може дозволяти більше, вона надає вищому рівню інтерфейс для передачі та отримання пакетів відкритого тексту розміром до 32 768 байт кожен. Зазвичай після транспортування 1 ГБ даних або через годину, залежно від того, що станеться раніше, транспортний рівень організовує повторний обмін ключами.
  
• Автентифікація клієнта здійснюється через рівень автентифікації користувача (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
  • Щоб підтвердити легітимність хоста, запис DNS SSHFP (RFC 4255) пропонує відбитки пальців загальнодоступного ключа хоста.

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

Вразливі місця

SSH-1

Через неадекватний захист цілісності даних, який забезпечує CRC-32 у цій версії протоколу, у 1998 році в SSH 1.5 було виявлено вразливість, яка дозволяла несанкціоноване вставлення матеріалу в зашифрований потік SSH. У більшості реалізацій вони додали патч, відомий як SSH Compensation Attack Detector. Кілька з цих переглянутих реалізацій включали нову помилку переповнення цілого числа, яка дозволяла зловмисникам запускати довільний код з root або можливостями демона SSH.

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

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

Відновлення відкритого тексту для CBC

У листопаді 2008 року в усіх версіях SSH було виявлено теоретичну вразливість, яка дозволяла отримати до 32 біт відкритого тексту з блоку зашифрованого тексту, зашифрованого за допомогою стандартного методу шифрування того часу, CBC. Найпростішим виправленням є перехід на CTR, лічильник замість режиму CBC, який робить SSH захищеним від атаки.

АНБ підозрюють у розшифровці

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