Первые шаги после покупки VDS: базовая защита

Чеклист нового 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

Разбор ошибок первого подключения

Ошибка 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-соединение до полной проверки нового порта на случай, если что-то пойдёт не так.

Таблица: что теряется на каждом шаге при ошибке

Когда этого чеклиста недостаточно

• Сервер обрабатывает платежи или персональные данные — нужен полноценный аудит по стандарту вроде PCI DSS, а не общий чеклист для VDS.
• На сервере несколько независимых клиентов или проектов — нужна изоляция через контейнеры или отдельные системные пользователи с ограниченными правами, базового hardening недостаточно.
• Сервер доступен из недоверенной сети без VPN — стоит рассмотреть ограничение SSH по IP через UFW или полностью закрыть порт и ходить только через VPN/bastion-хост.
• Нужен аудит того, кто и что делал на сервере, а не только защита от входа — базовый чеклист не включает журналирование команд и файловых изменений, для этого нужен отдельный инструмент вроде auditd.

Какой тип SSH-ключа выбрать

Команда ssh-keygen без параметров создаёт ключ RSA-3072 — рабочий вариант, но не оптимальный. Для нового сервера лучше сгенерировать современный ключ явно: ssh-keygen -t ed25519 -C "admin@example.com".

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

1. В отдельном втором терминале, не закрывая текущую сессию, подключитесь заново: ssh -p 2222 myuser@server_ip — вход должен пройти по ключу без запроса пароля.
2. Проверьте, что root по SSH больше не пускает: ssh root@server_ip должен завершиться ошибкой доступа.
3. Проверьте статус firewall: ufw status verbose должен показывать только нужные порты в состоянии ALLOW.
4. Проверьте, что fail2ban активен и видит SSH: fail2ban-client status sshd.

Дальнейшие шаги по ограничению попыток входа — в статье про настройку fail2ban, а сравнение файрвол-инструментов — в статье про UFW на VPS. Если после базовой защиты нужно ещё и логировать действия пользователей на уровне ядра, смотрите статью про настройку auditd для мониторинга Linux — она уже не про первые шаги, а про постоянный контроль сервера.