Що таке SSH і як працює захищене з’єднання

Що таке SSH?

SSH (secure shell) — це протокол для входу на віддалений комп’ютер і виконання команд через зашифроване з’єднання. Введені команди надходять на віддалену машину, її вивід повертається назад, а ніхто, хто перехоплює мережевий трафік між ними, не може прочитати ні команди, ні результат. Орендований Linux-сервер не має підключених до нього екрана та клавіатури, тому SSH є основним способом роботи з такою машиною.

Ця назва охоплює два поняття. SSH — це протокол, описаний у RFC 4251–RFC 4254. OpenSSH — програма, яка його реалізує. Саме її фактично використовують майже всі Linux-сервери та майже всі ноутбуки. Коли кажуть «підключитися до сервера через SSH», мають на увазі, що клієнтська програма ssh на локальній машині обмінюється даними із серверною програмою sshd на іншому кінці з’єднання.

Проблема, яку мав вирішити SSH

Віддалений вхід з’явився задовго до SSH. Telnet відкривав звичайне TCP-з’єднання з портом 23 і надсилав кожен байт саме в тому вигляді, у якому ви його вводили. Нічого не шифрувалося, зокрема й пароль. Будь-хто, хто міг бачити мережевий трафік, міг його прочитати: людина в тій самій офісній мережі або оператор будь-якого маршрутизатора на цьому шляху. Сімейство rlogin мало таку саму вразливість. Крім того, воно довіряло клієнтській машині за її ім’ям, тобто фактично довіряло будь-якому значенню, яке мережа називала цим ім’ям.

Tatu Ylönen написав першу версію SSH у 1995 році в Helsinki University of Technology після атаки з перехопленням паролів у мережі університету. SSH зберігає корисну частину Telnet — потік байтів між вашим терміналом і віддаленою оболонкою — і додає те, на що Telnet не має відповіді: шифрування потоку та підтвердження, що сервер на іншому кінці з’єднання є саме тим сервером, до якого ви хотіли підключитися.

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

Як працює модель клієнт–сервер

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

• Сервер читає /etc/ssh/sshd_config. Саме тут вимикається вхід за паролем і задається порт, на якому сервер приймає підключення.
• Клієнт спочатку читає /etc/ssh/ssh_config із системними параметрами за замовчуванням, а потім ~/.ssh/config з вашими власними параметрами для кожного хоста.

У Debian та Ubuntu unit сервісу називається ssh. У RHEL, Rocky та Fedora він називається sshd. У нових версіях Ubuntu сервіс запускається через socket activation. Тому systemctl status ssh може повідомляти inactive (dead), хоча машина доступна. Це відбувається тому, що ssh.socket приймає підключення, а потім запускає сервіс за потреби.

Клієнтом не обов’язково має бути OpenSSH. PuTTY у Windows, Termius на телефоні та вбудовані в редактори засоби віддаленої підтримки використовують той самий протокол і підключаються до того самого sshd. У Windows 10 і 11 також є клієнт OpenSSH, тому ssh you@server працює в PowerShell без додаткового встановлення.

Чому SSH використовує порт 22?

Порт — це номер, який повідомляє ядру, якій програмі, що прослуховує порт, належить вхідне з’єднання. Порти в Linux працюють однаково для всіх сервісів. SSH використовує 22, тому що IANA призначила цей номер у 1995 році. Ylönen запросив вільний номер поруч із протоколами, які мав замінити SSH: 21 використовував FTP, 23 — telnet, а 22 був вільним.

Оскільки 22 є портом за замовчуванням, його використовують усі. Віддалений репозиторій Git, скрипт резервного копіювання та панель керування провайдера спочатку намагаються підключитися до 22. Так само робить кожен автоматизований сканер в інтернеті. Новий сервер із увімкненим входом за паролем починає отримувати такі рядки у /var/log/auth.log вже через кілька хвилин після завантаження:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

Такий трафік є постійним і не спрямований особисто на вас. Перенесення sshd на порт 2222 прибирає більшість таких рядків, оскільки сканери перебирають увесь інтернет на порту 22, а не вивчають саме ваш сервер. Це не ускладнює злам для того, хто справді перевіряє сервер. Розглядайте зміну порту лише як зменшення шуму.

Ви можете побачити відповідь сервера ще до входу:

nc 203.0.113.10 22

В Ubuntu 24.04 ця команда виводить щось на кшталт SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. Банер надсилається у відкритому вигляді, до встановлення шифрування, оскільки обидві сторони мають узгодити версію протоколу. Натисніть Ctrl+C, щоб закрити з’єднання.

Що відбувається в мережі під час підключення

Наведена нижче послідовність описує дії одного ssh you@server до появи запрошення.

1. Клієнт визначає IP-адресу за іменем хоста, а потім відкриває TCP-з’єднання з портом 22.
2. Обидві сторони надсилають банер версії у відкритому вигляді.
3. Обидві сторони надсилають списки підтримуваних алгоритмів: обміну ключами, шифрування, автентифікації повідомлень і стиснення. Дані все ще передаються у відкритому вигляді. Вибирається найнадійніший варіант, який підтримують обидві сторони.
4. Виконується обмін ключами. Поточний OpenSSH надає перевагу curve25519-sha256. Обидві сторони отримують той самий спільний секрет, але сам секрет ніколи не передається мережею. Тому той, хто записав усю розмову, не зможе відновити його пізніше.
5. Сервер підписує результат обміну своїм приватним ключем хоста. Клієнт перевіряє підпис за допомогою публічного ключа хоста, який збережено локально. Саме цей крок не дає машині посередині видати себе за ваш сервер.
6. Починається шифрування. chacha20-poly1305@openssh.com — шифр за замовчуванням у поточній версії OpenSSH.
7. Лише після цього клієнт автентифікує вас за допомогою пароля або ключа. Ім’я користувача та пароль передаються всередині зашифрованого каналу.
8. Клієнт відкриває канал і запитує оболонку.

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

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

Ключ хоста та запит із відбитком під час першого підключення

Коли встановлено openssh-server, він генерує пари ключів хоста для машини та записує їх у /etc/ssh/, наприклад ssh_host_ed25519_key і ssh_host_ed25519_key.pub. Приватна частина ніколи не залишає сервер. Публічна частина є ідентичністю сервера. Саме з нею перевіряють підпис на кроці 5.

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

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Відбиток — це хеш публічного ключа хоста SHA256, надрукований у base64. Тому його зручно порівнювати візуально. Введення yes записує цей ключ у ~/.ssh/known_hosts на вашій машині. Під час кожного наступного підключення до тієї самої адреси клієнт порівнює ключ, який пропонує сервер, зі збереженим ключем. Якщо вони збігаються, нічого не виводиться, і ви одразу переходите до командного рядка.

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

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Ця команда виводить той самий рядок SHA256:, який показано в запиті. Варіант [fingerprint] у запиті призначено саме для цього: вставте очікуваний відбиток, і клієнт продовжить роботу лише в разі його збігу з відбитком, який надав сервер.

У Debian і Ubuntu known_hosts за замовчуванням хешується, тому файл містить рядки, що починаються з |1|, а не зрозумілі імена хостів. Виконайте ssh-keygen -F 203.0.113.10, щоб знайти запис для потрібного хоста.

Чому SSH повідомляє, що ключ вузла змінився?

Рано чи пізно ви побачите такий великий блок тексту:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Він закінчується повідомленням Host key verification failed., після чого клієнт відмовляється підключатися. Також виводиться Password authentication is disabled to avoid man-in-the-middle attacks., оскільки введення пароля на невідомій машині — саме та шкода, якій має запобігати ця перевірка.

Повідомлення виглядає як аварійне попередження, але зазвичай ним не є. Найпоширеніші причини:

• Ви перебудували або перевстановили сервер, тому sshd під час першого завантаження згенерував нові ключі вузла. Це найпоширеніша причина.
• Ви видалили один VPS і створили інший, а провайдер призначив новій машині стару IP-адресу.
• Ви підключаєтеся через переадресацію або балансувальник навантаження, який тепер передає запит на іншу бекенд-машину.
• Хтось справді перехоплює з’єднання.

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

ssh-keygen -R 203.0.113.10

Під час наступного підключення знову з’явиться запит із відбитком ключа. Це дасть змогу ще раз порівняти його з відбитком у консолі провайдера.

Автентифікація за паролем і за ключем

Автентифікація за паролем передає ваш пароль усередині вже зашифрованого каналу, а sshd перевіряє його в базі даних облікових записів, зазвичай через PAM (pluggable authentication modules). Підготовка не потрібна, тому провайдер може надати вам новий сервер лише з паролем root.

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

Автентифікація за відкритим ключем працює інакше. Ви створюєте пару ключів на власному комп’ютері. Відкритий ключ записується у ~/.ssh/authorized_keys вашого облікового запису на сервері. Приватний ключ залишається на вашому ноутбуці й ніколи не передається. Під час входу клієнт підписує фрагмент даних, що містить ідентифікатор сеансу з обміну ключами, а сервер перевіряє цей підпис за допомогою відкритого ключа, який уже зберігає. Оскільки підписані дані пов’язані саме з цим сеансом, перехоплений підпис непридатний для будь-якого іншого сеансу.

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

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

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

Клієнт повідомляє лише Permission denied (publickey). Це саме повідомлення може відповідати десятку різних причин, тому варто заздалегідь навчитися правильно читати помилки publickey, щоб не втратити доступ. Практичні дії зі створення ключів, захисту їх passphrase і завантаження в agent описано в розділі Керування ключами SSH. Вимкнення входу за паролем без втрати доступу описано в розділі Посилення захисту SSH на VPS.

SFTP, scp і перенаправлення портів використовують одне з’єднання

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

• Віддалена оболонка. ssh you@server відкриває канал сеансу та запитує інтерактивну оболонку.
• Одна команда. ssh you@server uptime відкриває канал, виконує одну команду, виводить результат і завершує роботу.
• SFTP. Клієнт просить sshd запустити підсистему sftp, а передавання файлів відбувається в межах того самого з’єднання. SFTP — це протокол передавання файлів, який працює через SSH, і він не має спільної архітектури з FTP. Протокол, що є FTP із доданим шифруванням, називається FTPS і не пов’язаний із SFTP.
• scp. Копіює файли з використанням того самого входу. Починаючи з OpenSSH 9.0, випущеного у 2022, scp за замовчуванням використовує протокол SFTP під капотом.
• Перенаправлення портів. ssh -L 8080:localhost:80 you@server перетворює порт 8080 на вашому ноутбуці на доступ до порту 80 на сервері через зашифроване з’єднання. -R переспрямовує з’єднання у зворотному напрямку, а -D 1080 перетворює сеанс на SOCKS-проксі.
• Git. Віддалений репозиторій на кшталт git@github.com:user/repo.git — це вхід через SSH, на віддаленому боці якого замість оболонки працює обробник команд.
• rsync і Ansible також є SSH-клієнтами. Вони відкривають канал, виконують певну дію та зчитують результат.

Кожен пункт у цьому списку використовує той самий порт, ту саму перевірку ключа хоста та ті самі облікові дані. Тому одноразове налаштування автентифікації за ключем одразу виправдовує витрачені зусилля: кожен із цих інструментів успадковує це налаштування. Саме тому той самий файл ~/.ssh/config, який скорочує команди входу, стає особливо корисним, коли ви керуєте кількома Linux-серверами з одного ноутбука.

Що SSH не робить

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

Куди рухатися далі

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

FAQ

Що означає SSH?

SSH означає secure shell. Це протокол для входу на віддалений комп’ютер і виконання на ньому команд через зашифроване з’єднання, визначений у RFC 4251–RFC 4254. OpenSSH — реалізація, яку використовує майже кожен: клієнт ssh на вашому комп’ютері та сервер sshd на віддаленому. SSH замінив telnet, який передавав мережею все, зокрема паролі, у відкритому тексті.

Чому SSH використовує порт 22?

IANA призначила SSH порт 22 у 1995 році, поруч із FTP на порту 21 і telnet на порту 23 — протоколами, які SSH мав замінити. Це число не є обов’язковим: Port у /etc/ssh/sshd_config змінює його на сервері, а ssh -p вибирає інший порт на клієнті. Оскільки 22 є портом за замовчуванням, автоматизовані сканери постійно звертаються до нього. Тому /var/log/auth.log нового сервера швидко заповнюється рядками Failed password for invalid user. Зміна порту зменшує цей шум, але не забезпечує реального захисту.

Що робити, якщо SSH повідомляє, що ключ вузла змінився?

Спочатку з’ясуйте причину, а вже потім видаляйте збережений ключ. Зазвичай причина нешкідлива: сервер перебудували, тому sshd згенерував нові ключі вузла, або стару IP-адресу призначили новій машині. Якщо ви знаєте, що машину перебудували, виконайте ssh-keygen -R <host>, щоб видалити збережений ключ, повторно підключіться та порівняйте відбиток ключа, який буде показано, з відбитком у консолі вашого провайдера. Якщо з вашого боку нічого не змінювалося, не підключайтеся і не вводьте пароль. OpenSSH уже відмовляється від автентифікації за паролем у такому стані саме з цієї причини.

Чи відрізняються SFTP і scp від SSH?

Вони працюють поверх SSH. Після автентифікації SSH-з’єднання може передавати кілька каналів, а shell є лише одним із них. SFTP — протокол передавання файлів, який використовує підсистему sftp сервера sshd через те саме з’єднання, а scp використовує протокол SFTP під ним починаючи з OpenSSH 9.0. Перенаправлення портів і Git через SSH також працюють як канали того самого з’єднання. Усі вони використовують той самий порт, ту саму перевірку ключа вузла та той самий обліковий запис для входу. Зверніть увагу: SFTP — це не FTP із доданим шифруванням. Такий протокол називається FTPS і є окремим протоколом.

Чи справді автентифікація за ключем краща за пароль?

Так, для будь-якого сервера, доступного з інтернету. Пароль — це короткий секрет, який ви передаєте серверу під час кожного входу, а порт 22 постійно перевіряють автоматизовані клієнти. У парі ключів приватна частина ніколи не залишає ваш комп’ютер: клієнт підписує дані, пов’язані з поточним сеансом, а сервер перевіряє цей підпис за відкритим ключем у ~/.ssh/authorized_keys. Записаний підпис не можна повторно використати для автентифікації на іншому сервері. Захистіть приватний ключ парольною фразою, оскільки файл ключа без парольної фрази дає змогу увійти будь-кому, хто його скопіює.