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 пользователя, под которым идёт вход.