Полное руководство по безопасной настройке SSH на Debian 13: миграция порта, аутентификация по ключа

В этом подробном руководстве мы рассмотрим комплексную настройку безопасности SSH-сервера на Debian-подобных системах (включая Debian 13). Особое внимание уделим безопасному внесению изменений без риска нарушения работоспособности существующих сервисов и точному определению текущей конфигурации фаервола.

Почему это критически важно?

В современных Debian-системах могут одновременно сосуществовать несколько систем фильтрации трафика (nftables, iptables, UFW), но активной управляет только одна. Неправильное определение может привести к:

• Добавлению правил в неработающую систему
• Конфликту правил между разными фаерволами
• Полной или частичной потере сетевой доступности

Методика точного определения

Выполните последовательно эти команды для определения реально активной системы управления фаерволом:

# 1. Проверяем, запущена ли служба nftables (управляет /etc/nftables.conf)
systemctl is-active nftables && echo "✅ nftables активен (управляет через /etc/nftables.conf)"

# 2. Проверяем, работает ли UFW - проверяем СТАТУС, а не только активность службы
sudo ufw status verbose

# 3. Проверяем, используется ли iptables-persistent (сохранённые iptables-правила)
systemctl is-active netfilter-persistent && echo "✅ iptables-persistent активен (управляет iptables-правилами)"

Анализ результатов на реальном примере

Допустим, вы получаете такой вывод:

inactive
Status: inactive
✅ iptables-persistent активен (управляет iptables-правилами)

Что это означает:

1. nftables неактивен — служба nftables не запущена, правила nftables (если они есть) созданы другими сервисами или вручную.
2. UFW отключен (inactive) — Uncomplicated Firewall установлен, но не включен. Служба UFW может быть запущена (systemctl status ufw может показывать active (exited)), но сам фаервол UFW выключен командой ufw disable.
3. iptables-persistent активен — эта служба сохраняет правила iptables между перезагрузками и в вашем случае является основной системой управления фаерволом.

Важный нюанс: Обратите внимание, что systemctl is-active ufw может показывать "active", даже если UFW выключен (Status: inactive). Это происходит потому, что служба systemd для UFW запускается при загрузке, но сам фаервол может быть отключен. Поэтому команда sudo ufw status verbose — единственный надежный способ проверить, включен ли UFW.

Отключение ICMP echo-ответов снижает заметность сервера при автоматических сетевых сканированиях, не влияя на функциональность.

Временное отключение (до перезагрузки):

sudo sysctl -w net.ipv4.icmp_echo_ignore_all=1

Постоянное отключение:

echo "net.ipv4.icmp_echo_ignore_all = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Проверка: Выполните ping ваш_сервер с другого компьютера — должны получить "Request timed out".

На основании определенного активного фаервола выбираем соответствующую ветку действий:

Ветка A: Если активен iptables-persistent (ваш случай)

Поскольку в примере выше показано, что iptables-persistent активен, используем именно его:

# Проверяем текущие правила iptables
sudo iptables -L -n --line-numbers

# Добавляем правило для порта 10022
sudo iptables -A INPUT -p tcp --dport 10022 -j ACCEPT

# Проверяем добавленное правило
sudo iptables -L -n | grep 10022

# Сохраняем правила для автоматической загрузки после перезагрузки
sudo netfilter-persistent save

# Альтернативный способ сохранения (если netfilter-persistent не работает):
# sudo iptables-save | sudo tee /etc/iptables/rules.v4

Важно: iptables-persistent автоматически загружает сохраненные правила при загрузке системы из файлов /etc/iptables/rules.v4 и /etc/iptables/rules.v6.

Ветка B: Если активен UFW (Status: active)

Если бы sudo ufw status verbose показал "Status: active":

# Добавляем правило для порта 10022
sudo ufw allow 10022/tcp

# Проверяем добавленное правило
sudo ufw status numbered | grep 10022

# UFW автоматически сохраняет правила между перезагрузками

Ветка C: Если активен nftables

Если бы systemctl is-active nftables показал "active":

# Временное правило
sudo nft add rule ip filter input tcp dport 10022 accept

# Постоянное правило (через конфигурационный файл)
sudo nano /etc/nftables.conf

В файле найдите цепочку input и добавьте:

chain INPUT {
    type filter hook input priority filter; policy accept;
    # ... существующие правила
    tcp dport 10022 accept  # Добавленная строка
}

Примените: sudo nft -f /etc/nftables.conf

Ветка D: Если все системы неактивны (ручное управление)

Если все три проверки показали неактивное состояние:

# Проверяем существующие правила через оба интерфейса
sudo nft list ruleset 2>/dev/null
sudo iptables -L -n

# Определяем, какая система используется (обычно nftables в Debian 12+)
# Добавляем временное правило
sudo nft add rule ip filter input tcp dport 10022 accept

# Для сохранения после перезагрузки создаем скрипт:
sudo nano /etc/network/if-pre-up.d/firewall-custom

Содержимое файла:

#!/bin/bash
nft add rule ip filter input tcp dport 10022 accept

Даем права: sudo chmod +x /etc/network/if-pre-up.d/firewall-custom

Безопасный подход: Добавляем новый порт параллельно со старым, тестируем, и только потом убираем старый.

1. Редактируем конфигурацию SSH:

sudo nano /etc/ssh/sshd_config

1. Добавляем новый порт (можно указать несколько портов на отдельных строках):

# Старый порт (оставляем для подстраховки)
Port 22

# Новый порт
Port 10022

Важно: Формат Port 22,10022 (через запятую) не поддерживается и вызовет ошибку.

1. Проверяем синтаксис и применяем:

sudo sshd -t && sudo systemctl reload ssh

1. Проверяем, что sshd слушает оба порта:

sudo ss -tlnp | grep sshd

Ожидаемый вывод:

LISTEN 0      128          0.0.0.0:22       0.0.0.0:*    users:(("sshd",pid=1234,fd=3))
LISTEN 0      128          0.0.0.0:10022    0.0.0.0:*    users:(("sshd",pid=1234,fd=4))

Часть A: Подготовка на клиенте

1. Генерация ключа (на вашем локальном компьютере):

ssh-keygen -t ed25519 -a 100 -C "ваш_комментарий"

Для совместимости со старыми системами:

ssh-keygen -t rsa -b 4096 -a 100 -C "ваш_комментарий"

1. Копирование ключа на сервер (пока через порт 22):

ssh-copy-id -p 22 ваш_пользователь@ваш_сервер

Часть B: Настройка прав на сервере

Неправильные права — частая причина проблем с аутентификацией по ключам:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown ваш_пользователь:ваша_группа ~/.ssh/authorized_keys

Часть C: Конфигурация sshd

1. Редактируем конфигурацию:

sudo nano /etc/ssh/sshd_config

1. Устанавливаем параметры безопасности:

# Основные настройки аутентификации
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no  # Если не используете PAM-модули

# Настройки root-доступа (по вашему требованию)
PermitRootLogin prohibit-password  # Разрешает root по ключу

# Дополнительные ограничения
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
LoginGraceTime 60
AllowUsers ваш_пользователь  # Ограничение по пользователям (опционально)

1. Проверяем и применяем:

sudo sshd -t && sudo systemctl reload ssh

Часть D: Тестирование

1. Подключение по новому порту с ключом:

ssh -p 10022 ваш_пользователь@ваш_сервер

Должно подключиться без запроса пароля.

1. Проверка отключения паролей:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no \
    -p 10022 ваш_пользователь@ваш_сервер

Должен получить немедленный отказ с сообщением "Permission denied".

Что такое fail2ban и как он работает?

Fail2ban — это система интеллектуальной защиты от брутфорс-атак, которая:

1. Мониторит логи сервисов (SSH, веб-серверы, FTP и др.)
2. Анализирует шаблоны неудачных попыток аутентификации
3. Добавляет временные блокировки в фаервол для IP-адресов нарушителей
4. Автоматически разблокирует IP после истечения заданного времени

Важно: В вашем случае fail2ban будет работать с iptables, так как именно он активен.

Установка и настройка для порта 10022:

1. Установка:

sudo apt update
sudo apt install fail2ban -y

1. Создание конфигурации:

sudo nano /etc/fail2ban/jail.local

1. Конфигурация для SSH на порту 10022:

[DEFAULT]
# Глобальные настройки
bantime = 1h
findtime = 10m
maxretry = 3
backend = systemd  # Используем systemd как бэкенд для логов

[sshd]
enabled = true
port = 10022
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 24h

[sshd-ddos]
enabled = true
port = 10022
filter = sshd-ddos
logpath = /var/log/auth.log
maxretry = 5
bantime = 10m
findtime = 10m

Пояснение параметров:

• port = 10022 — мониторим именно новый порт
• maxretry = 3 — 3 неудачные попытки до блокировки
• bantime = 24h — блокировка на 24 часа для стандартных атак
• findtime = 10m — окно времени для подсчета попыток

1. Запуск и проверка:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

1. Проверка логов fail2ban:

sudo tail -f /var/log/fail2ban.log

После успешного тестирования:

1. Удаляем старый порт 22 из SSH-конфигурации:

sudo nano /etc/ssh/sshd_config

Удалите строку Port 22 и оставьте только Port 10022.

1. Обновляем конфигурацию:

sudo sshd -t && sudo systemctl reload ssh

1. Проверяем итоговую конфигурацию:

# Проверяем прослушиваемые порты
sudo ss -tlnp | grep sshd

# Проверяем правила iptables для порта 10022
sudo iptables -L -n | grep 10022

# Проверяем сохраненные правила
sudo iptables-save | grep 10022

# Проверяем fail2ban
sudo fail2ban-client status sshd

# Проверяем подключение
ssh -p 10022 -o ConnectTimeout=5 ваш_пользователь@ваш_сервер echo "Успех!"

1. Опционально удаляем правило для порта 22 из iptables:

# Находим номер правила для порта 22
sudo iptables -L INPUT -n --line-numbers | grep "dpt:22"

# Удаляем правило (замените X на номер правила)
sudo iptables -D INPUT X

# Сохраняем изменения
sudo netfilter-persistent save

1. Всегда имейте резервный доступ — консоль через панель хостинга (VNC, IPMI, KVM) до завершения всех настроек.
2. Не удаляйте порт 22 до полной проверки работы через порт 10022.
3. Сохраняйте резервные копии перед изменениями:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
sudo iptables-save > ~/iptables-backup-$(date +%Y%m%d).rules

1. Тестируйте в двух окнах терминала — одно для внесения изменений, второе для проверки подключения.
2. Для iptables-persistent особо важно — после каждого изменения правил выполняйте sudo netfilter-persistent save.

Вы выполнили комплексную настройку безопасности SSH-сервера, включающую:

1. Точную диагностику текущей конфигурации фаервола с правильным определением активного iptables-persistent
2. Безопасное добавление правил в iptables с сохранением через netfilter-persistent
3. Миграцию на нестандартный порт для снижения внимания ботов
4. Принудительную аутентификацию по ключам для исключения брутфорса
5. Установку автоматической защиты через fail2ban, интегрированную с iptables

Ключевое преимущество данного подхода: все изменения внесены с учетом реальной конфигурации вашей системы, где iptables-persistent является основной системой управления фаерволом. Мы сохранили совместимость с существующими правилами и обеспечили сохранение настроек между перезагрузками.

Теперь ваш сервер защищен от большинства автоматизированных атак и готов к безопасной эксплуатации в production-среде.