Как обезопасить SSH‑сервер на Ubuntu

Изображение: ноутбук с терминалом и надписью SSH

SSH — безопасный сетевой протокол и интерфейс командной строки для удалённого доступа к Linux‑серверу. Он обеспечивает шифрование соединения и защищённый канал для обмена данными между клиентом и сервером. SSH используется администраторами для управления серверами, выполнения удалённых команд и безопасной передачи файлов. В этом руководстве подробно описано, как надёжно настроить SSH‑сервер.

Важно: инструкционные примеры показаны на Ubuntu, но шаги применимы к большинству дистрибутивов Linux.

Содержание

Установка и обновление SSH
Настройка входа по ключам (passwordless)
Жёсткая конфигурация /etc/ssh/sshd_config
Защита через TCP‑wrappers
Защита через iptables (и альтернативы)
Упрощённая конфигурация клиента
Контрольный список для админа
Как откатить изменения и отладка
Часто задаваемые вопросы
Глоссарий (1 строка)

Установка и обновление SSH

Перед началом убедитесь, что система обновлена, и установите необходимые пакеты.

На сервере и клиенте выполните:

sudo apt update && sudo apt upgrade -y
sudo apt install -y openssh-server openssh-client

Проверьте статус службы SSH на сервере:

sudo systemctl status ssh

Если служба не запущена, включите и запустите её:

sudo systemctl enable --now ssh

Важно: на некоторых дистрибутивах пакет серверной части называется openssh-server. Команда выше установит и клиентскую, и серверную части, если они отсутствуют.

Настройка SSH для входа по ключам (passwordless)

Определение: SSH‑ключи — пара файлов: публичный ключ (id_rsa.pub) и приватный ключ (id_rsa). Приватный ключ храните локально и никогда не распространяйте.

На клиентской машине сгенерируйте пару ключей (RSA/Ed25519 рекомендуются; Ed25519 короче и безопаснее по умолчанию):

ssh-keygen -t ed25519

Нажимайте Enter для значений по умолчанию или задайте путь/фразу‑пару (passphrase) для приватного ключа.

Скопируйте публичный ключ на сервер:

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

Если ssh-copy-id недоступна, можно вручную создать каталог и файл:

ssh username@your.server.ip.address 'mkdir -p ~/.ssh && chmod 700 ~/.ssh'
cat ~/.ssh/id_ed25519.pub | ssh username@your.server.ip.address 'cat >> ~/.ssh/authorized_keys'
ssh username@your.server.ip.address 'chmod 600 ~/.ssh/authorized_keys'

Изображение: генерация публичного ключа в терминале

Проверьте права на сервере:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Подключитесь для проверки:

ssh username@your.server.ip.address

Если подключение происходит без запроса пароля сервера (требуется только фраза к приватному ключу, если она задана), значит всё настроено правильно.

Примечание для Windows: современные версии Windows 10/11 имеют встроенный OpenSSH‑клиент; для генерации ключей и копирования можно использовать PowerShell/Windows Terminal или PuTTYgen для PuTTY.

Жёсткая конфигурация /etc/ssh/sshd_config

Файл /etc/ssh/sshd_config задаёт системные параметры демона sshd. Перед изменениями сделайте резервную копию текущей конфигурации:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Откройте файл в редакторе:

sudo nano /etc/ssh/sshd_config

Ниже — рекомендуемые настройки с пояснениями. Применяйте по необходимости и тестируйте каждое изменение.

Изменить порт прослушивания

По умолчанию SSH слушает порт 22. Изменение порта уменьшит количество случайных сканирований, но не является защитой по принципу безопасности через неявность (security through obscurity).

Из:

#Port 22

В:

Port 2200

Если вы меняете порт, не забудьте открыть его в брандмауэре и в правилах iptables/UFW.

Использовать только протокол 2

Protocol 2

SSH protocol v1 устарел и уязвим; используйте v2.

Ограничить доступ пользователей

Разрешайте вход только конкретным пользователям:

AllowUsers user1 user2

Запретить конкретных пользователей:

DenyUsers baduser1 baduser2

Альтернатива: директива AllowGroups для разрешения групп.

Отключить вход под root

Вход под root через SSH увеличивает вектор атаки. Разрешите получение прав через sudo.

Из:

#PermitRootLogin prohibit-password

В:

PermitRootLogin no

Если вам требуется удалённое восстановление, держите административный пользователь с sudo и протестируйте доступ прежде, чем закрыть root.

Скрыть информацию о последнем входе

PrintLastLog no

Это уменьшит количество информации, которую видит пользователь при входе (полезно для приватности).

Ограничить интерфейс для прослушивания

Если у сервера несколько интерфейсов, укажите конкретный IP для прослушивания:

#ListenAddress 0.0.0.0
ListenAddress 192.168.68.175

Оставьте #ListenAddress закомментированным, чтобы слушать на всех интерфейсах.

Отключить парольную аутентификацию

После успешной настройки ключей отключите вход по паролю:

Из:

#PasswordAuthentication yes

В:

PasswordAuthentication no

Важно: до того, как вы отключите парольную аутентификацию, проверьте, что доступ по ключу работает. В противном случае вы рискуете запереть себя вне сервера.

Отключить .rhosts и host‑based аутентификацию

IgnoreRhosts yes
RhostsAuthentication no
HostbasedAuthentication no
RSAAuthentication yes

Уменьшить время ожидания входа

LoginGraceTime 1m

Это уменьшит окно для автоматизированных попыток входа.

Ограничить количество новых подключений

MaxStartups 2

Эта опция помогает смягчить атаки типа brute‑force. Значение подбирайте в зависимости от нагрузки.

Отключить переадресацию X11 и туннелирование, если не нужно

X11Forwarding no
AllowTcpForwarding no
PermitTunnel no

Если вы используете SSH для безопасного туннелирования, разрешите только явно необходимые опции.

Уровень логирования

LogLevel VERBOSE

LogLevel VERBOSE даёт больше информации о попытках входа и полезно для расследования инцидентов. В продакшене следите за объёмом логов.

Запрет пустых паролей

PermitEmptyPasswords no

Таймаут простоя соединения

Добавьте, чтобы автоматически закрывать бездействующие сессии:

ClientAliveInterval 300
ClientAliveCountMax 0

Включить строгую проверку прав

StrictModes yes

Это заставит ssh проверять права на домашнюю директорию и файлы ключей.

Сохраните файл и перезапустите службу:

sudo systemctl restart ssh

Изображение: перезапуск демона SSH и консоль статуса

Важно: после каждой значимой правки sshd_config протестируйте доступ в отдельной сессии или используйте sshd -t для проверки синтаксиса перед рестартом:

sudo sshd -t && sudo systemctl restart ssh

Если вы теряете доступ, вернитесь на консоль провайдера/панель VPS или используйте режим восстановления.

Защита SSH с помощью TCP‑wrappers

TCP‑wrappers (файлы /etc/hosts.allow и /etc/hosts.deny) обеспечивают простой хост‑ориентированный контроль доступа.

Откройте /etc/hosts.allow:

sudo nano /etc/hosts.allow

Добавьте разрешение только для нужных IP:

sshd : 192.168.68.1 192.168.68.175

И в /etc/hosts.deny можно жёстко запретить по умолчанию:

sshd : ALL

Изображение: редактирование hosts.allow для фильтрации доступа по IP

Примечание: TCP‑wrappers работают только с сервисами, поддерживающими libwrap; современный systemd/sshd чаще всего поддерживает, но проверяйте совместимость.

Защита SSH с помощью iptables (и альтернатива UFW)

iptables даёт гибкий контроль сетевого трафика. Ниже — пример, разрешающий SSH только с конкретного IP и блокирующий остальные.

Разрешить только источник 192.168.68.1 на порт 2200:

sudo iptables -A INPUT -p tcp -m state --state NEW --source 192.168.68.1 --dport 2200 -j ACCEPT

Заблокировать остальные соединения на порт 2200:

sudo iptables -A INPUT -p tcp --dport 2200 -j DROP

Сохраните правила (варианты зависят от системы):

sudo iptables-save > /etc/iptables/rules.v4

Альтернатива для Ubuntu — UFW (Uncomplicated Firewall), более простая в использовании:

sudo ufw allow from 192.168.68.1 to any port 2200 proto tcp
sudo ufw enable

Совет: сначала настройте правило разрешения, проверьте, что вы можете подключиться, затем включайте правило DROP по умолчанию. Всегда держите откатный доступ (консоль VPS или физический доступ).

Изображение: интерфейс брандмауэра и правила iptables

Упрощение подключений на локальной машине

Чтобы не вводить длинные команды, используйте конфигурационный файл клиента ~/.ssh/config.

Создайте или отредактируйте файл ~/.ssh/config:

Host sshserver
    HostName remote.server.ip.address
    Port 2200
    User foobar
    IdentityFile ~/.ssh/remote.server.key

Затем подключение выполнится одной командой:

ssh sshserver

Этот файл поддерживает множественные профили, параметры прокси и переадресацию. Держите права файла chmod 600 ~/.ssh/config.

Контрольный список для безопасной эксплуатации (для администратора)

Сделать резервную копию /etc/ssh/sshd_config
Сгенерировать и развернуть ключи для всех админов
Отключить PasswordAuthentication после проверки ключей
Запретить вход root: PermitRootLogin no
Ограничить AllowUsers/AllowGroups
Установить нестандартный порт (опционально)
Настроить брандмауэр (UFW/iptables) и TCP‑wrappers
Включить LogLevel VERBOSE и настроить ротацию логов
Настроить ClientAliveInterval для автоматического закрытия простоя
Тесты восстановления доступа: консоль провайдера/режим восстановления

Как откатить изменения и план восстановления

Если потеряли доступ к SSH, используйте:
- Консоль хоста у провайдера (VPS панель, serial console)
- Физический доступ к серверу
Верните резервную копию конфигурации:

sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sudo systemctl restart ssh

Если проблема в iptables, очистите правила временно:

sudo iptables -F
sudo iptables -X

Если вы отключили PasswordAuthentication и нет ключей, временно разрешите пароли через панель хоста или режим восстановления, затем восстановите ключи.

Критерии приёмки: после изменений вы должны уметь подключаться по SSH с ключами, вход под root должен быть запрещён, пустые пароли — запрещены, и брандмауэр должен пропускать только разрешённые IP.

Отладка — полезные команды

Проверить синтаксис конфигурации sshd:

sudo sshd -t

Просмотреть статус службы:

sudo systemctl status ssh

Проверить прослушиваемые порты:

sudo ss -tulpn | grep sshd

Смотреть последние записи в журнале:

sudo journalctl -u ssh -f
# или
sudo tail -n 200 /var/log/auth.log

Проверить права и содержимое authorized_keys:

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

Альтернативные подходы и расширения

Использовать Fail2Ban: инструмент для отслеживания неудачных попыток логина и автоматического добавления правил в брандмауэр.
Использовать двухфакторную аутентификацию (2FA) для SSH (например, Google Authenticator PAM модуль).
Централизованное управление ключами и аудит: ldap, FreeIPA, HashiCorp Vault или ssh certificates (OpenSSH Certificate Authority).
Использовать систему прокси‑двухфакторного доступа (bastion/jump host) и приватные сети.

Когда это не подходит: если у вас динамические IP у администраторов и нет возможности использовать ключи/CA, возможно, придётся временно разрешать диапазоны IP или использовать VPN.

Тестовые сценарии и критерии приёмки

Базовая проверка доступа:
- Убедитесь, что пользователь с ключом может подключиться.
- Отключите PasswordAuthentication и убедитесь, что попытка входа по паролю блокируется.
Ограничение IP:
- Попробуйте подключиться с разрешённого IP — доступ разрешён.
- Попробуйте подключиться с запрещённого IP — соединение блокируется.
Перезагрузка sshd:
- После рестарта sshd все настройки сохраняются и доступ остаётся корректным.
Логирование:
- В логах появляются записи о неудачных попытках и успешных подключениях (LogLevel VERBOSE).

Роль‑ориентированные чек‑листы

Администратор:

Соберите резервный канал доступа
Разверните ключи и проверьте их
Настройте брандмауэр и TCP‑wrappers
Настройте ротацию логов и мониторинг

Разработчик/DevOps:

Настройте ~/.ssh/config для упрощённого подключения
Добавьте CI/CD‑ключи в ограниченные аккаунты
Используйте ssh‑агент или секретный менеджер для приватных ключей

Оператор/Helpdesk:

Проверять журналы для неудачных попыток
Иметь готовый сценарий отката и инструкции по восстановлению доступа

Часто задаваемые вопросы

IP моего устройства поменялся. Сможу ли я подключиться?

Если вы настроили строгую фильтрацию по конкретному IP, то после смены IP доступ будет невозможен. Рекомендация: разрешайте диапазон IP (CIDR), используйте VPN или динамический DNS и соответствующие правила брандмауэра.

Пример для диапазона:

sudo iptables -A INPUT -p tcp -m state --state NEW --source 192.168.1.0/24 --dport 2200 -j ACCEPT

Нужно ли использовать одновременно hosts.allow и iptables?

Обычно достаточно одного механизма, но комбинирование может давать дополнительный уровень фильтрации. Учтите, что слишком много правил усложняет отладку.

Потерял приватный ключ. Что делать?

Если приватный ключ потерян и это единственный способ доступа — вы не сможете войти по SSH. Используйте консоль провайдера VPS или физический доступ для восстановления, затем создайте новую пару ключей и обновите authorized_keys. При необходимости временно включите PasswordAuthentication, но только из надёжной сети.

Минимальная методология развёртывания (шаги)

Обновить системы и установить OpenSSH.
Сгенерировать ключи для администраторов и загрузить публичные ключи на сервер.
Настроить sshd_config: запрет root, отключение паролей, уменьшение LoginGraceTime.
Настроить брандмауэр/iptables и TCP‑wrappers.
Включить логирование (VERBOSE) и мониторинг (Fail2Ban, SIEM).
Тестирование и утверждение политики доступа.

Безопасность и приватность

Храните приватные ключи в защищённом месте и используйте фразу‑пароль (passphrase).
Используйте ssh‑agent для сокращения количества вводов фразы без хранения ключа в открытом виде.
Если сервер обрабатывает персональные данные — проверьте соответствие требованиям местного законодательства о защите данных и ротацию ключей.

Глоссарий — 1 строка

SSH: защищённый протокол для удалённого доступа по зашифрованному каналу; sshd — демон сервера, ssh — клиент.

Итог и рекомендации

Вкратце: отдавайте предпочтение аутентификации по ключам, запрещайте root и пустые пароли, ограничивайте вход по пользователям и IP, настраивайте брандмауэр и ведите расширенное логирование. Всегда заранее готовьте план отката и тестируйте доступ по альтернативному каналу.

Важно: никогда не отключайте PasswordAuthentication окончательно, пока не проверили, что доступ по ключам работает для всех необходимых админов.

Image Credit: Unsplash. Все скриншоты и правки — автор.