SSH Hardening: безпечне налаштування сервера від злому

SSH — основний спосіб адміністрування Linux-серверів і головна мішень автоматизованих атак. Грамотний hardening знижує ризик злому на 95%.

Базова конфігурація /etc/ssh/sshd_config

Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowTcpForwarding no
AllowUsers deploy admin
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group14-sha256
Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

sshd -t && systemctl reload sshd

Не закривайте поточну сесію! Після зміни порту відкрийте нове з'єднання в іншій вкладці. Переконайтеся, що вхід працює, — і лише тоді закривайте стару сесію.

Генерація та налаштування SSH-ключів

ssh-keygen -t ed25519 -C "server-key-2026" -f ~/.ssh/myserver_ed25519
ssh-copy-id -i ~/.ssh/myserver_ed25519.pub -p 22 user@server

Двофакторна автентифікація (TOTP)

apt install libpam-google-authenticator -y
google-authenticator

Додати в /etc/pam.d/sshd: auth required pam_google_authenticator.so

У sshd_config: ChallengeResponseAuthentication yes і AuthenticationMethods publickey,keyboard-interactive

Чеклист SSH Hardening

Налаштування	Значення	Пріоритет
Нестандартний порт	2222 або інший	Середній
PermitRootLogin no	Обов'язково	Високий
PasswordAuthentication no	Після налаштування ключів	Високий
AllowUsers	Лише потрібні	Високий
MaxAuthTries 3	Обмежити спроби	Середній
fail2ban	Блокування IP-адрес атакуючих	Високий
2FA (TOTP)	Додатковий фактор	Середній

Моніторинг спроб входу

journalctl -u ssh --since "1 hour ago" | grep "Failed"
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -20
fail2ban-client status sshd

Максимальний захист: Не відкривайте SSH в інтернет взагалі. Використовуйте Cloudflare Access або WireGuard VPN як проміжний шар — SSH доступний лише через захищений тунель.

Типові помилки під час hardening

Помилка	Причина	Що робити
sshd: no hostkeys available -- exiting	Синтаксична помилка в конфігу або відсутні файли ключів хоста після перевстановлення	Перевірте конфіг: `sshd -t`, за потреби згенеруйте ключі: `ssh-keygen -A`
Permission denied (publickey)	Після вимкнення PasswordAuthentication публічний ключ не скопійовано або у ~/.ssh неправильні права	Перевірте права: `chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys`
Address already in use	Вказаний порт уже зайнятий іншим процесом або старим екземпляром sshd	Знайдіть процес: `ss -tlnp \| grep 2222` і зупиніть конфліктний сервіс
Connection refused на новому порту	Файрвол (ufw/iptables) не відкритий для нового порту SSH	Дозвольте порт: `ufw allow 2222/tcp` до перезапуску sshd
WARNING: UNPROTECTED PRIVATE KEY FILE! на клієнті	Права на файл приватного ключа на локальній машині надто відкриті	Виправте права: `chmod 600 ~/.ssh/myserver_ed25519`

Порівняння методів захисту SSH

Метод	Захищає від	Складність впровадження
Зміна порту	Автоматизованого сканування «за замовчуванням»	Низька, але не рятує від цільової атаки
fail2ban	Брутфорсу за логами невдалих спроб	Низька, налаштовується за 5 хвилин
2FA (TOTP)	Крадіжки або витоку приватного ключа	Середня, потрібен телефон у кожного адміністратора
Port knocking / SPA	Розвідки порту сканерами (порт узагалі не видно)	Висока, складніше діагностувати проблеми підключення

Коли hardening не врятує

0-day вразливість у самому OpenSSH — жодна конфігурація не закриє баг у коді демона
Скомпрометована робоча станція адміністратора з приватним ключем на диску — зловмисник отримає доступ, оминаючи всі налаштування сервера
Інсайдер із легітимним доступом і власним ключем — hardening захищає від зовнішніх атак, а не від зловживання правами
Слабкий пароль sudo за фізичного чи консольного доступу до сервера (наприклад, через панель провайдера) — SSH тут не єдина точка входу

Для захисту від брутфорсу додатково ставиться Fail2ban: захист SSH і Nginx від підбору паролів, а сильніший другий фактор розібрано у статті «Двофакторна автентифікація для SSH і веб-панелей».

Перевірка результату

Після налаштування перевірте, що всі параметри справді застосувалися:

# Показати активну (не файлову, а застосовану) конфігурацію
sshd -T | grep -Ei "permitrootlogin|passwordauthentication|port|maxauthtries"

# Переконатися, що вхід за паролем справді відхиляється
ssh -o PubkeyAuthentication=no -o PasswordAuthentication=yes user@server
# Очікуваний результат: "Permission denied (publickey)"

# Перевірити, що старий порт 22 закритий зовні
nmap -p 22,2222 server_ip

Якщо SSH потрібно взагалі сховати від сканерів, наступний крок — винести його за WireGuard VPN на VPS і відкривати порт лише всередині тунелю.

Часті питання

Що робити, якщо після збереження нової конфігурації підключення по SSH взагалі не встановлюється?

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

Чи безпечно використовувати один і той самий приватний ключ для доступу до кількох серверів?

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

Чи варто одразу вимикати пароль (PasswordAuthentication), якщо двофакторна автентифікація ще не налаштована?

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

Як відновити доступ до сервера, якщо AllowUsers вказано невірно і вхід закрився для всіх користувачів?

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