SSH — основний спосіб доступу до VPS. За замовчуванням він працює на порту 22 і доступний для атак brute-force. Правильне налаштування знижує ризик злому до мінімуму.

Безпечний /etc/ssh/sshd_config

># Змінити стандартний порт (опційно, але рекомендується)
Port 2222

# Заборонити вхід під root
PermitRootLogin no

# Дозволити вхід тільки визначеним користувачам
AllowUsers deploy admin

# Вимкнути вхід за паролем (тільки ключі!)
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

# Вимкнути X11 forwarding
X11Forwarding no

# Таймаут неактивної сесії (5 хвилин)
ClientAliveInterval 300
ClientAliveCountMax 2

# Тільки IPv4 (якщо IPv6 не потрібен)
AddressFamily inet

# Протокол SSH 2 (застарілий 1 вже не використовується, але вкажемо явно)
Protocol 2

# Алгоритми шифрування (сучасні)
KexAlgorithms curve25519-sha256,diffie-hellman-group14-sha256
Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com

Застосувати зміни

# Перевірити синтаксис перед перезапуском!
sudo sshd -t

# Перезапустити SSH
sudo systemctl restart sshd

# Не закривайте поточну сесію — відкрийте нове вікно і перевірте вхід

⚠️ Не закривайте поточну SSH-сесію до перевірки нового входу. Якщо допустили помилку — можна втратити доступ до сервера. Завжди перевіряйте в новій вкладці.

Генерація і додавання SSH-ключів

# На клієнті — генерація ключа (Ed25519 — сучасний і безпечний)
ssh-keygen -t ed25519 -C "myserver" -f ~/.ssh/myserver

# Копіювати публічний ключ на сервер
ssh-copy-id -i ~/.ssh/myserver.pub user@server.example.com

# Вручну додати публічний ключ
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Fail2Ban — захист від brute-force

>sudo apt install fail2ban -y

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222          # ваш SSH порт
maxretry = 5         # спроб до бану
bantime = 3600       # бан на 1 годину
findtime = 600       # вікно в 10 хвилин

sudo systemctl enable --now fail2ban

# Переглянути забанені IP
sudo fail2ban-client status sshd

💡 Чекліст безпечного SSH:

✓ Вхід тільки за ключами (PasswordAuthentication no)
✓ PermitRootLogin no
✓ Нестандартний порт
✓ AllowUsers — тільки потрібні користувачі
✓ Fail2Ban активний
✓ UFW дозволяє тільки SSH з потрібних IP

Часті помилки під час hardening SSH

Більшість проблем із SSH після hardening діляться на «сервер не стартує» і «доступ втрачено» — важливо вміти відрізняти одне від іншого.

sshd: no hostkeys available -- exiting.

Служба не знаходить файли ключів хоста — типово після ручного видалення чи переміщення /etc/ssh/ssh_host_*_key. Створіть ключі заново: ssh-keygen -A, потім перезапустіть sshd.

Permission denied (publickey).

Саме ця помилка з'являється, якщо PasswordAuthentication no застосували раніше, ніж публічний ключ реально додано і перевірено в новій сесії. Різниця в порядку дій — між робочим сервером і втраченим доступом. Завжди перевіряйте вхід за ключем в окремому вікні ДО вимкнення пароля, як зазначено в інструкції нижче.

/etc/ssh/sshd_config line 27: Bad configuration option: Protocol

Директива Protocol 2 у прикладі конфігурації вище — спадок старих версій. Починаючи з OpenSSH 7.6 вона вважається застарілою, а в деяких збірках OpenSSH 8.0+ перевірка синтаксису взагалі відхиляє цей рядок. SSH-протокол версії 1 давно видалений з коду, версія 2 використовується за замовчуванням без явної вказівки — просто приберіть цей рядок із конфігу.

Методи автентифікації: порівняння

Метод	Стійкість до brute-force	Зручність	Ризик компрометації
Пароль	Низька	Висока (не потрібен файл)	Підбір, витік, фішинг
SSH-ключ (Ed25519)	Висока	Потрібен доступ до приватного ключа	Крадіжка файлу ключа
Ключ + passphrase	Дуже висока	Потрібно вводити passphrase	Мінімальний при крадіжці файлу
SSH-сертифікати (CA)	Дуже висока	Потребує інфраструктури CA	Мінімальний, є відкликання

Для одиночного VPS ключа Ed25519 достатньо. Для серверної інфраструктури від 10 машин і більше варто придивитися до SSH-сертифікатів — це звільняє від ручного додавання і відкликання ключів на кожному сервері окремо.

Коли жорсткий hardening не підходить

Зміна порту — це зниження шуму в логах від автоматичних сканерів, а не захист від цільової атаки: якщо зловмисник уже знає IP і мету конкретного сервера, сканування діапазону портів займає секунди. Не вважайте нестандартний порт заміною решти заходів. Вимкнення PermitRootLogin може зламати інсталятори застарілих панелей керування, які очікують прямого входу під root по SSH — перед hardening уточніть, чи не потребує використовуване ПЗ такого доступу під час першого встановлення або оновлення. Якщо сервером керує зовнішня команда з корпоративною політикою доступу за паролем через VPN — вимкнення PasswordAuthentication потребуватиме спершу узгодити перехід на ключі з усіма, хто входить на сервер.

Як перевірити результат

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

# Перевірити, що sshd слухає новий порт
sudo ss -tlnp | grep sshd

# Перевірити статус fail2ban для sshd
sudo fail2ban-client status sshd

# Детальний вивід при підключенні — покаже, який ключ використовується
ssh -v -p 2222 user@server.example.com

У виводі ssh -v шукайте рядок Authentication succeeded (publickey) — якщо замість нього сервер запитує пароль, значить PasswordAuthentication no ще не застосувався або ключ не доданий у authorized_keys користувача, під яким відбувається вхід.