Чеклист нового VDS
Після отримання нового сервера виконайте ці кроки в перші 30 хвилин — це захистить вас від 95% типових атак.
Крок 1: Створення користувача та SSH-ключі
# Створюємо користувача
adduser myuser
usermod -aG sudo myuser
# Копіюємо SSH-ключ для нового користувача
rsync --archive --chown=myuser:myuser ~/.ssh /home/myuser/Крок 2: Налаштування SSH
# /etc/ssh/sshd_config
Port 2222 # Змінюємо стандартний порт
PermitRootLogin no # Заборона входу root
PasswordAuthentication no # Лише ключі
PubkeyAuthentication yes
MaxAuthTries 3
systemctl reload sshdКрок 3: Файрвол UFW
ufw allow 2222/tcp # Ваш SSH-порт
ufw allow http
ufw allow https
ufw enableКрок 4: Автооновлення безпеки
apt install unattended-upgrades -y
dpkg-reconfigure --priority=low unattended-upgradesКрок 5: fail2ban
apt install fail2ban -y
systemctl enable --now fail2ban| Дія | Час | Пріоритет |
|---|---|---|
| Оновити систему | 2 хв | Критичний |
| Створити sudo-користувача | 2 хв | Критичний |
| Налаштувати SSH | 5 хв | Критичний |
| Налаштувати UFW | 3 хв | Високий |
| Встановити fail2ban | 2 хв | Високий |
Розбір помилок першого підключення
Помилка Permission denied (publickey) під час спроби зайти новим користувачем означає, що ключ не скопіювався або права на файли неправильні. SSH категорично відмовляється читати ключ, якщо каталог чи файли доступні на запис комусь, крім власника.
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/myuser/.ssh/id_ed25519
Permission denied (publickey).Перевірте права: ~/.ssh має бути 700, а ~/.ssh/authorized_keys — 600, і обидва належати користувачу, а не root. Команда rsync --chown з кроку 1 зазвичай вирішує це сама, але після ручного копіювання права потрібно виставити окремо.
Помилка Connection refused після зміни порту SSH означає, що або firewall ще не відкрив новий порт, або sshd не перечитав конфіг. Порядок дій важливий: спершу відкрити новий порт в UFW, потім застосувати конфіг sshd, і лише потім закривати старий порт — інакше ризикуєте лишитися без доступу взагалі. Тримайте одне відкрите SSH-зʼєднання до повної перевірки нового порту на випадок, якщо щось піде не так.
Таблиця: що втрачається на кожному кроці за помилки
| Крок | Якщо пропустити | Наслідок |
|---|---|---|
| SSH-ключі | Лишається вхід за паролем | Брутфорс підбирає пароль за години |
| Зміна порту SSH | Порт 22 видно всім | Постійний шум ботів у auth.log, зайве навантаження |
| UFW | Усі порти відкриті | Доступні сервіси, які не мають бути публічними |
| fail2ban | Немає блокування за спробами | Одна й та сама IP довбить SSH без обмежень |
Коли цього чеклиста недостатньо
- Сервер обробляє платежі або персональні дані — потрібен повноцінний аудит за стандартом на кшталт PCI DSS, а не загальний чеклист для VDS.
- На сервері кілька незалежних клієнтів чи проєктів — потрібна ізоляція через контейнери або окремі системні користувачі з обмеженими правами, базового hardening недостатньо.
- Сервер доступний з недовіреної мережі без VPN — варто розглянути обмеження SSH за IP через UFW або повністю закрити порт і ходити лише через VPN чи bastion-хост.
- Потрібен аудит того, хто і що робив на сервері, а не лише захист від входу — базовий чеклист не включає журналювання команд і файлових змін, для цього потрібен окремий інструмент на кшталт auditd.
Який тип SSH-ключа обрати
Команда ssh-keygen без параметрів створює ключ RSA-3072 — робочий варіант, але не оптимальний. Для нового сервера краще згенерувати сучасний ключ явно: ssh-keygen -t ed25519 -C "admin@example.com".
| Тип ключа | Довжина | Коли використовувати |
|---|---|---|
| ed25519 | 256 біт | За замовчуванням для нових серверів, швидший і компактніший за RSA |
| RSA | 4096 біт | Лише якщо потрібна сумісність зі старим софтом без підтримки ed25519 |
Перевірка результату
- В окремому другому терміналі, не закриваючи поточну сесію, підключіться заново:
ssh -p 2222 myuser@server_ip— вхід має пройти за ключем без запиту пароля. - Перевірте, що root через SSH більше не пускає:
ssh root@server_ipмає завершитися помилкою доступу. - Перевірте стан firewall:
ufw status verboseмає показувати лише потрібні порти у станіALLOW. - Перевірте, що fail2ban активний і бачить SSH:
fail2ban-client status sshd.
Подальші кроки з обмеження спроб входу — у статті про налаштування fail2ban, а порівняння файрвол-інструментів — у статті про UFW на VPS. Якщо після базового захисту потрібно ще й журналювати дії користувачів на рівні ядра, дивіться статтю про налаштування auditd для моніторингу Linux — вона вже не про перші кроки, а про постійний контроль сервера.