Проблема
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.
text
sudo apt update
sudo apt install openssh-server
RHEL, CentOS, Rocky Linux.
text
sudo dnf install openssh-server
sudo systemctl enable --now sshd
Проверяем статус.
text
sudo systemctl status sshd
2. Генерация SSH ключей на клиенте
На клиентской машине (откуда будем подключаться) генерируем пару ключей. Рекомендуется использовать алгоритм Ed25519. Он более безопасен и быстр, чем RSA.
text
ssh-keygen -t ed25519 -C "user@client-host"
При запросе можно оставить путь по умолчанию (~/.ssh/id_ed25519) и задать пароль (passphrase) для дополнительной защиты. Пароль запрашивается при каждом использовании ключа, но его можно добавить в агент.
Если необходимо использовать RSA (например для совместимости со старыми системами), укажите длину ключа не менее 3072 бит.
text
ssh-keygen -t rsa -b 4096 -C "user@client-host"
3. Копирование публичного ключа на сервер
Самый простой способ использовать утилиту ssh-copy-id. Если доступ по паролю ещё разрешён, выполните.
text
ssh-copy-id user@server_ip
Если парольный доступ уже отключён, ключ нужно добавить вручную.
text
cat ~/.ssh/id_ed25519.pub | ssh user@server_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
Убедитесь, что права на .ssh и authorized_keys установлены правильно.
text
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
4. Базовая настройка безопасности сервера
Редактируем конфигурационный файл /etc/ssh/sshd_config. Перед изменением сделайте резервную копию.
text
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
Отключение парольной аутентификации.
text
PasswordAuthentication no
Запрет входа для root.
text
PermitRootLogin no
Смена порта (опционально).
text
Port 2222
Если меняете порт, не забудьте открыть его в брандмауэре. Стандартный 22 можно оставить, но смена порта снижает число атак.
Ограничение пользователей или групп.
text
AllowUsers user1 user2
AllowGroups sshusers
Разрешает вход только указанным пользователям или членам группы. Группу можно создать.
text
sudo groupadd sshusers
sudo usermod -aG sshusers user1
Использование современных алгоритмов шифрования.
text
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
Эти параметры отключают слабые алгоритмы.
Прочие полезные опции.
PubkeyAuthentication yes явно разрешает аутентификацию по ключам (обычно включено по умолчанию).
X11Forwarding no отключает X11 forwarding, если не нужен.
MaxAuthTries 3 ограничивает количество попыток аутентификации.
ClientAliveInterval 300 и ClientAliveCountMax 2 разрывают неактивные сессии.
5. Применение конфигурации
После изменений проверьте синтаксис.
text
sudo sshd -t
Если ошибок нет, перезапустите службу.
text
sudo systemctl restart sshd
Убедитесь, что вы не потеряли доступ. Откройте новое окно терминала и попробуйте подключиться по новому порту (если меняли) с использованием ключа.
text
ssh -p 2222 user@server_ip
Если вход выполнен успешно, можно закрыть старую сессию.
6. Настройка брандмауэра
Ubuntu (ufw).
text
sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp # если хотите закрыть старый порт
RHEL (firewalld).
text
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
7. Использование агента SSH для удобства
Агент позволяет хранить расшифрованные ключи в памяти, чтобы не вводить пароль при каждом подключении. Запуск агента.
text
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Для автоматического запуска агента в графических средах обычно используется ssh-agent при входе. В консольных сессиях можно добавить в .bashrc.
text
if [ -z "$SSH_AUTH_SOCK" ]; then
eval "$(ssh-agent -s)" > /dev/null
ssh-add ~/.ssh/id_ed25519 2>/dev/null
fi
8. Дополнительный уровень: двухфакторная аутентификация
Для повышения безопасности можно добавить двухфакторную аутентификацию (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 2222ssh-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) для обнаружения подозрительной активности.