Проблема
SSH (Secure Shell) стандартный протокол удалённого управления серверами. Однако стандартная установка OpenSSH часто имеет настройки, которые не соответствуют современным требованиям безопасности: разрешён вход по паролю, активен доступ для root, используются устаревшие алгоритмы шифрования. Это делает сервер уязвимым для брутфорса, перехвата сессий и компрометации учётных данных. Вместо паролей следует использовать асимметричные ключи, а также грамотно ограничить доступ, чтобы обеспечить защиту без потери удобства. В этой статье мы настроим SSH-сервер (OpenSSH) на Debian/Ubuntu и RHEL-подобных системах, сфокусировавшись на безопасности и использовании ключей.
Решение
Используем OpenSSH наиболее распространённую реализацию, доступную в репозиториях всех дистрибутивов. Основные принципы безопасности:
- Отключение аутентификации по паролю (оставляем только ключи).
- Запрет прямого входа для root (используем sudo).
- Смена стандартного порта (опционально, но снижает количество атакующих сканеров).
- Ограничение доступа по IP или подсетям через
AllowUsers/AllowGroups. - Использование современных алгоритмов шифрования (Ed25519, RSA с достаточной длиной) и отказ от слабых (CBC, MD5).
Ключевая часть генерация и правильное размещение SSH-ключей, а также настройка агента аутентификации для удобства.
Пошаговая инструкция
Все действия выполняются на сервере под управлением Linux. Примеры команд даны для Ubuntu 22.04 LTS, различия для RHEL-подобных будут указаны.
1. Установка и первичная проверка
Debian / Ubuntu:
sudo apt update
sudo apt install openssh-serverRHEL / CentOS / Rocky Linux:
sudo dnf install openssh-server
sudo systemctl enable --now sshdПроверяем статус:
sudo systemctl status sshd2. Генерация SSH-ключей на клиенте
На клиентской машине (откуда будем подключаться) генерируем пару ключей. Рекомендуется использовать алгоритм Ed25519, так как он более безопасен и быстр, чем RSA. Подробности алгоритмов можно найти в документации OpenSSH.
ssh-keygen -t ed25519 -C "user@client-host"При запросе можно оставить путь по умолчанию (~/.ssh/id_ed25519) и задать пароль (passphrase) для дополнительной защиты. Пароль запрашивается при каждом использовании ключа, но его можно добавить в агент.
Если необходимо использовать RSA (например, для совместимости со старыми системами), укажите длину ключа не менее 3072 бит:
ssh-keygen -t rsa -b 4096 -C "user@client-host"3. Копирование публичного ключа на сервер
Самый простой способ — использовать утилиту ssh-copy-id. Если доступ по паролю ещё разрешён, выполните:
ssh-copy-id user@server_ipЕсли парольный доступ уже отключён, ключ нужно добавить вручную:
cat ~/.ssh/id_ed25519.pub | ssh user@server_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"Убедитесь, что права на .ssh и authorized_keys установлены правильно:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys4. Базовая настройка безопасности сервера
Редактируем конфигурационный файл /etc/ssh/sshd_config. Перед изменением сделайте резервную копию:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bakОтключение парольной аутентификации
PasswordAuthentication noЗапрет входа для root
PermitRootLogin noСмена порта (опционально)
Port 2222Если меняете порт, не забудьте открыть его в брандмауэре. Стандартный 22 можно оставить, но снизить число атак помогает смена.
Ограничение пользователей / групп
AllowUsers user1 user2
AllowGroups sshusersРазрешает вход только указанным пользователям или членам группы. Группу можно создать:
sudo groupadd sshusers
sudo usermod -aG sshusers user1Использование современных алгоритмов шифрования
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.comЭти параметры отключают слабые алгоритмы. Рекомендации по их выбору можно найти в статье Mozilla Security.
Прочие полезные опции
-
PubkeyAuthentication yesявно разрешает аутентификацию по ключам (обычно включено по умолчанию). -
X11Forwarding noотключает X11 forwarding, если не нужен. -
MaxAuthTries 3ограничивает количество попыток аутентификации. -
ClientAliveInterval 300иClientAliveCountMax 2разрывает неактивные сессии.
5. Применение конфигурации
После изменений проверьте синтаксис:
sudo sshd -tЕсли ошибок нет, перезапустите службу:
sudo systemctl restart sshdУбедитесь, что вы не потеряли доступ: откройте новое окно терминала и попробуйте подключиться по новому порту (если меняли) с использованием ключа:
ssh -p 2222 user@server_ipЕсли вход выполнен успешно, можно закрыть старую сессию.
6. Настройка брандмауэра
ufw (Ubuntu):
sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp # если хотите закрыть старый портfirewalld (RHEL):
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload7. Использование агента SSH для удобства
Агент позволяет хранить расшифрованные ключи в памяти, чтобы не вводить пароль при каждом подключении. Запуск агента:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519Для автоматического запуска агента в графических средах обычно используется ssh-agent при входе. В консольных сессиях можно добавить в .bashrc:
if [ -z "$SSH_AUTH_SOCK" ]; then
eval "$(ssh-agent -s)" > /dev/null
ssh-add ~/.ssh/id_ed25519 2>/dev/null
fi8. Дополнительный уровень: двухфакторная аутентификация
Для повышения безопасности можно добавить двухфакторную аутентификацию (2FA) через Google Authenticator или TOTP. Установите пакет libpam-google-authenticator и настройте PAM. Это выходит за рамки статьи, но стоит рассмотреть для особо важных серверов.
Устранение распространённых проблем
| Проблема | Вероятная причина | Решение |
|---|---|---|
Permission denied (publickey) | Публичный ключ не добавлен в authorized_keys, неверные права на файлы. | Проверить содержимое authorized_keys, права: ~/.ssh 700, authorized_keys 600. Убедиться, что в sshd_config разрешена PubkeyAuthentication. |
| Сервер не отвечает на новом порту | Брандмауэр блокирует порт, SELinux (на RHEL) мешает. | Проверить firewall-cmd или ufw. На RHEL: semanage port -a -t ssh_port_t -p tcp 2222. |
ssh-add не может соединиться с агентом | Агент не запущен. | Выполнить eval "$(ssh-agent -s)" перед ssh-add. |
| Подключение прерывается через несколько минут бездействия | Настройки ClientAliveInterval на сервере или межсетевой экран убивает сессию. | Установить ClientAliveInterval 60 и ClientAliveCountMax 3 на сервере. На клиенте можно добавить ServerAliveInterval 60 в ~/.ssh/config. |
Ошибка no matching key exchange method | Клиент и сервер не договорились об алгоритмах. | Обновить OpenSSH на обеих сторонах. Временно можно добавить старый алгоритм в KexAlgorithms, но это снизит безопасность. |
Итог
Мы настроили SSH-сервер с использованием ключей вместо паролей, отключили вход для root, ограничили доступ к серверу по пользователям и, при желании, сменили порт. Также применили современные алгоритмы шифрования и научились работать с агентом SSH. Эти меры существенно повышают безопасность удалённого доступа и являются стандартом де-факто в индустрии. Регулярно обновляйте OpenSSH и следите за журналами (/var/log/auth.log) для обнаружения подозрительной активности.
