Як захистити SSH на VPS: ключі, Fail2ban і VPN

Чому SSH потрібно захищати насамперед

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

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

Крок 1: Спочатку переконайтеся, що автентифікація за ключем працює

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

На власному комп’ютері створіть ключ, якщо у вас його ще немає:

ssh-keygen -t ed25519

Скопіюйте публічну частину ключа на сервер:

ssh-copy-id user@your-server

Потім відкрийте новий SSH-сеанс. Якщо ви можете увійти без запиту пароля, ключ працює, і ви можете безпечно вимкнути автентифікацію за паролем. Якщо з’являється Permission denied (publickey), ця одна помилка може приховувати п’ять різних причин, а вивід ssh -v покаже, яка саме проблема виникла, перш ніж ви зміните щось інше. Якщо ви лише починаєте працювати з ключами або використовуєте кілька комп’ютерів, у матеріалі основи керування SSH-ключами описано всю модель: окремий ключ для кожного пристрою, дозволи, яких вимагає sshd, і спосіб відкликати ключ, якщо ноутбук загублено.

Крок 2: Посилення sshd за допомогою drop-in-файлу

Не редагуйте /etc/ssh/sshd_config безпосередньо. Ubuntu 24.04 читає drop-in-файли з /etc/ssh/sshd_config.d/. Невеликий файл у цьому каталозі має чистішу структуру, зберігається після оновлення пакетів і його легко видалити, якщо щось піде не так. Ім’я має значення: sshd зберігає перше прочитане значення кожного параметра, а cloud-образи Ubuntu постачають 50-cloud-init.conf із PasswordAuthentication yes у цьому каталозі. Назвіть файл 00-, щоб він сортувався перед ним і мав пріоритет. Файл 99- непомітно втрачає пріоритет. Створіть файл:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Додайте до нього:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Кожен рядок закриває окремий шлях доступу. PasswordAuthentication no — головний параметр: якщо паролі вимкнено, brute-force-атака не має що перебирати. KbdInteractiveAuthentication no закриває ще один шлях автентифікації через пароль. PermitRootLogin no означає, що зловмисник має знати ваше ім’я користувача та володіти вашим ключем, а не лише атакувати єдиний обліковий запис root, який існує на кожному сервері.

Крок 3: Перевірте конфігурацію, потім перезавантажте службу

Перед застосуванням перевірте конфігурацію на помилки. Так описка не зможе порушити роботу служби:

sudo sshd -t

Якщо команда нічого не виводить, конфігурація коректна. Перезавантажте SSH:

sudo systemctl reload ssh

Потім перевірте фактичні параметри, які використовує sshd. Це дасть змогу виявити drop-in-конфігурацію, яку перекрив інший файл:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

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

Крок 4: Необов’язковий нестандартний порт

Перенесення SSH з порту 22 на порт на кшталт 2222 не робить його по-справжньому безпечнішим, оскільки цілеспрямований зловмисник сканує всі порти. Це лише зменшує кількість шуму в журналі, адже більшість автоматизованих сканерів перевіряє тільки 22. Якщо це потрібно, додайте Port 2222 до drop-in-файлу, спочатку дозвольте новий порт у брандмауері, а потім виконайте sudo systemctl daemon-reload && sudo systemctl restart ssh.socket і підключіться за допомогою ssh -p 2222. В Ubuntu 24.04 за порт, що прослуховується, відповідає ssh.socket, тому звичайний reload ssh залишає sshd на порту 22; саме перезапуск socket застосовує новий порт. Розглядайте це як упорядкування конфігурації, а не як захист.

Крок 5: Додайте додаткові рівні захисту

Захищені SSH-ключі є основою. Над ними можна додати ще два рівні захисту.

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

Ще надійніший варіант — повністю прибрати SSH із публічного інтернету. Якщо розмістити SSH за WireGuard VPN і дозволити доступ до порту 22 лише через тунель, ніхто поза VPN не зможе навіть підключитися до SSH. Тоді перебір паролів стає неможливим, а не просто складнішим. Усе це передбачає використання брандмауера з політикою заборони доступу за замовчуванням. Його налаштування описано в матеріалі Налаштування UFW на VPS.

SSH — лише один пункт у ширшому списку перевірок. Матеріал перші 10 хвилин на новому VPS упорядковує ці кроки. Автоматичні оновлення безпеки в Ubuntu надалі підтримують систему в актуальному стані. Захист доступу до SSH не захищає сервіси за ним. Тому, якщо на цьому самому VPS працює сховище паролів, додаткове зміцнення Vaultwarden охоплює два компоненти, яких автентифікація за ключами не стосується: його токен адміністратора та файл резервної копії.

FAQ

Як вимкнути вхід за паролем для SSH в Ubuntu 24.04?

Створіть drop-in-файл у /etc/ssh/sshd_config.d/00-hardening.conf. Префікс 00 забезпечує його сортування перед 50-cloud-init.conf, параметр PasswordAuthentication yes якого інакше мав би пріоритет, оскільки sshd використовує перше прочитане значення. Додайте до файлу PasswordAuthentication no і KbdInteractiveAuthentication no, виконайте sudo sshd -t для перевірки, а потім sudo systemctl reload ssh. Підтвердьте, що вхід за ключем працює в новій сесії, перш ніж покладатися на нього. Редагування drop-in-файлу замість sshd_config зберігається після оновлення пакетів і його легко скасувати.

Чи потрібно вимикати вхід root через SSH?

Так. Установіть PermitRootLogin no, щоб ніхто не міг безпосередньо ввійти як root. Увійдіть під своїм звичайним користувачем і використовуйте sudo для адміністративних завдань. root існує на кожному Linux-сервері, тому доступний вхід під цим ім’ям дає зловмиснику відоме ім’я користувача для атак. Після вимкнення такого входу зловмисник має знати ім’я вашого облікового запису та мати ваш ключ.

Чи робить змінення SSH-порту сервер безпечнішим?

Не суттєво. Перехід з порту 22 приховує сервер від простих сканерів, які перевіряють лише 22, і зменшує кількість записів у журналі, але справжній зловмисник сканує всі порти й усе одно знайде його. Саме автентифікація лише за ключем фактично запобігає зламам. Якщо ви змінюєте порт, спочатку відкрийте новий порт у firewall, а потім виконайте sudo systemctl daemon-reload && sudo systemctl restart ssh.socket. В Ubuntu 24.04 сокет володіє listener, тому звичайне перезавантаження конфігурації залишає sshd на порту 22.

Чи потрібен Fail2ban, якщо я використовую SSH-ключі?

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

Як відновити доступ, якщо я заблокував собі доступ до SSH?

Скористайтеся вебконсоллю вашого провайдера. Вона підключається до сервера через serial або VNC-з’єднання, яке не проходить через SSH. Звідти ви можете ввійти, виправити drop-in-файл sshd і перезавантажити службу. Саме тому перед закриттям першої сесії потрібно перевірити нову конфігурацію SSH у другому терміналі. Автентифікація за ключем також має вже працювати до вимкнення входу за паролем.