Безпека SSH у 2026: ключі, Fail2Ban, hardening — повний гайд

Безпека SSH досі критична у 2026 році

Давайте ми вам пояснимо чому з саме таких слів ми розпочинаємо цю статтю: середній Linux-сервер отримує сотні спроб брутфорсу SSH щодня. Не на тиждень — щодня. А під час активних атак це число може злетіти до тисяч.

Якщо ви хоч раз заглядали в /var/log/auth.log на свіжому VPS(Cloud), то знаєте, про що мова. Через кілька годин після запуску ваш сервер вже під прицілом. Автоматизовані боти постійно сканують діапазони IP, шукаючи сервери зі слабкими паролями, стандартними портами та дозволеним root-логіном. Вони не якісь надзвичайні, бо це їм і не потрібно — так як занадто багато серверів досі працюють із безпекою рівня "двері без замка".

Хороша новина: SSH — один із найбезпечніших протоколів, коли-небудь створених.

Погана новина: більшість людей ніколи не налаштовують його правильно.

Парольна автентифікація: час рухатись далі

Отже, давайте чесно — паролі зручні. Їх можна запам'ятати (іноді), ввести з будь-якого пристрою, і вони не потребують особливого налаштування. Але у 2026 році покладатися на парольну автентифікацію для SSH — це як закривати банківське сховище на навісний замок.

Математика безжальна. Навіть "сильний" 12-символьний пароль з різним регістром, цифрами та символами має близько 72 біт ентропії. SSH-ключ? 4096 біт криптографічної випадковості. Це не просто краще — це зовсім інший всесвіт безпеки.

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

Перевага ключів

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

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

Генерація SSH-ключів: як зробити правильно

Не всі SSH-ключі однакові. У 2026 році у вас є кілька варіантів, і вибір має значення більше, ніж здається.

*256-бітний ключ Ed25519 забезпечує безпеку, еквівалентну ~3000-бітному RSA завдяки ефективності еліптичної криптографії.

Створення ключа Ed25519 (рекомендовано)

На вашій локальній машині (не на сервері) відкрийте термінал і виконайте:

ssh-keygen -t ed25519 -C "your_email@example.com"

Вас попросять вказати розташування файлу та passphrase. Завжди використовуйте надійний passphrase. Так, це означає вводити його щоразу при підключенні — але ssh-agent може безпечно кешувати його, а сам passphrase забезпечує критичний захист, якщо хтось отримає ваш файл приватного ключа.

Для старих систем: RSA 4096

Деякі старі системи не підтримують Ed25519. У таких випадках використовуйте RSA з максимальним розміром ключа:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Параметр -b 4096 критичний. RSA-ключі за замовчуванням часто 2048 біт — технічно ще безпечні, але з меншим запасом на майбутнє. Якщо створюєте ключі сьогодні, немає причин не використовувати 4096.

Розгортання ключів на сервері

Ви згенерували ключі. Тепер їх потрібно доставити на сервер — а точніше, публічний ключ. Приватний ключ залишається на вашій машині. Крапка.

Простий спосіб: ssh-copy-id

Якщо ви ще можете залогінитись паролем, це найшвидший метод:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server-ip

Ця команда автоматично створює директорію ~/.ssh на сервері, якщо потрібно, додає ваш публічний ключ до authorized_keys і встановлює правильні права доступу. Готово.

Ручний метод

Іноді ssh-copy-id недоступний або потрібен більший контроль. Ось ручний процес:

# На локальній машині — покажіть публічний ключ
cat ~/.ssh/id_ed25519.pub
# На сервері — створіть SSH-директорію та файл
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
# Вставте публічний ключ, збережіть, потім встановіть права
chmod 600 ~/.ssh/authorized_keys

Керування кількома ключами

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

Створіть ~/.ssh/config на локальній машині:

Host work-server
    HostName 192.168.1.100
    User admin
    IdentityFile ~/.ssh/id_work_ed25519
Host personal-vps
    HostName 203.0.113.50
    User deploy
    IdentityFile ~/.ssh/id_personal_ed25519
    Port 2222

Тепер можна просто набрати ssh work-server замість того, щоб пам'ятати IP-адреси, імена користувачів і розташування ключів.

Зміцнення конфігурації SSH

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

Редагуйте /etc/ssh/sshd_config на сервері. Ось що найважливіше:

Вимкніть вхід під root

PermitRootLogin no

Це не обговорюється. Навіть з ключовою автентифікацією дозволяти прямий root-логін — зайвий ризик. Створіть звичайного користувача, додайте його до групи sudo і підключайтесь під ним. Атакуючому тепер потрібно скомпрометувати дві речі: ваш SSH-ключ і пароль sudo.

Вимкніть парольну автентифікацію

PasswordAuthentication no
PubkeyAuthentication yes

Коли переконаєтесь, що ключова автентифікація працює — вимкніть паролі повністю. Ця одна зміна усуває 99% автоматизованих атак на сервер. Боти можуть підбирати ваш логін весь день — без валідного ключа вони нікуди не потраплять.

Змініть стандартний порт

Port 2222

Це security through obscurity — не зупинить цілеспрямованого атакуючого, але усуне шум від автоматичних сканерів, що бомблять порт 22. Ваш auth.log скаже вам дякую. Виберіть будь-який порт вище 1024 і нижче 65535.

Обмежте доступ користувачів

AllowUsers deploy admin
# або
AllowGroups sshusers

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

Зміцнення протоколу та шифрів

# Використовувати тільки SSH протокол 2
Protocol 2
# Тільки сильні шифри
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
# Сильні алгоритми обміну ключами
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
# Сильні MAC
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

Ці налаштування вимикають застарілі, потенційно вразливі алгоритми. Компроміс у тому, що дуже старі SSH-клієнти можуть не підключитись — але якщо щось працює на SSH з 2010 року, воно має більші проблеми.

Безпека сесії

# Відключати неактивні сесії через 15 хвилин
ClientAliveInterval 300
ClientAliveCountMax 3
# Обмежити спроби автентифікації
MaxAuthTries 3
# Вимкнути порожні паролі (очевидно)
PermitEmptyPasswords no

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

sudo sshd -t

Якщо помилок немає, перезапустіть SSH-сервіс:

sudo systemctl restart sshd

За межами базової конфігурації

Зміцнений sshd_config — чудово, але defense in depth означає додавання більше шарів захисту. Ось найефективніші додаткові заходи.

Fail2Ban: ваша автоматична охорона

Fail2Ban моніторить логи і автоматично банить IP-адреси, які демонструють шкідливу поведінку. Для SSH він відстежує невдалі спроби входу і блокує порушників.

sudo apt install fail2ban
sudo systemctl enable fail2ban

Стандартна конфігурація прийнятна, але можна налаштувати в /etc/fail2ban/jail.local:

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Це банить будь-яку IP з 3 невдалими спробами протягом 10 хвилин на 1 годину. Так, досить агресивно, але автоматичні атаки потребують агресивної відповіді.

Правила файрволу

Використовуйте UFW для обмеження SSH-доступу:

# Дозволити SSH тільки з вашої IP або діапазону
sudo ufw allow from 192.168.1.0/24 to any port 2222
# Або якщо потрібен глобальний доступ
sudo ufw allow 2222/tcp
sudo ufw enable

Якщо у вас статична IP, обмеження SSH-доступу тільки до неї неймовірно ефективне. Атакуючі навіть не зможуть достукатись до вашого SSH-порту.

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

Для максимальної безпеки поєднайте SSH-ключі з TOTP (Time-based One-Time Password):

sudo apt install libpam-google-authenticator

Це додає другий фактор — навіть якщо хтось вкраде ваш приватний ключ і passphrase, йому все одно потрібен код з authenticator-додатку.

SSH Jump Hosts (Bastion)

У production-середовищах ніколи не виставляйте SSH критичних серверів напряму в інтернет. Використовуйте bastion host — зміцнений мінімальний сервер, який виступає єдиною точкою входу до вашої мережі.

# У локальному ~/.ssh/config
Host production-db
    HostName 10.0.1.50
    User dbadmin
    ProxyJump bastion
Host bastion
    HostName 203.0.113.10
    User jump
    IdentityFile ~/.ssh/id_bastion

Тепер ssh production-db автоматично підключається через bastion. SSH-порт сервера бази даних ніколи не потрібно виставляти публічно.

Моніторинг безпеки SSH

Безпека — не одноразове налаштування, а безперервний процес. Ось як відстежувати, що відбувається з SSH на вашому сервері.

Слідкуйте за логами

Ваш auth.log розповідає історію кожної спроби автентифікації:

# Останні невдалі спроби
grep "Failed password" /var/log/auth.log | tail -20
# Успішні входи
grep "Accepted" /var/log/auth.log | tail -20
# Хто зараз залогінений
who
w

Відстежуйте використання ключів

Додавайте коментарі до записів authorized_keys для відстеження:

ssh-ed25519 AAAAC3... laptop-2026
ssh-ed25519 AAAAC3... work-desktop
ssh-ed25519 AAAAC3... emergency-backup

Періодично переглядайте цей файл. Якщо бачите ключ, який не впізнаєте — це проблема.

Налаштуйте сповіщення

Для критичних серверів налаштуйте алерти при успішних входах. Простий підхід через PAM-скрипт:

# /etc/pam.d/sshd — додайте рядок
session optional pam_exec.so /usr/local/bin/ssh-login-alert.sh

Скрипт може надсилати email, повідомлення в Slack або Telegram при кожному вході. Якщо отримуєте алерт, а це не ви заходите — ви дізнаєтесь одразу.

Типові помилки, яких варто уникати

За роки роботи з серверами ми бачили сотні SSH-конфігурацій. Деякі помилки повторюються настільки часто, що варто розібрати їх окремо.

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