Home » Как усилить безопасность OpenSSH на Ubuntu 24

Как усилить безопасность OpenSSH на Ubuntu 24

Если ты читаешь эту статью, значит, тебя уже достали попытки взлома через SSH, или ты просто понимаешь, что дефолтная конфигурация OpenSSH — это как оставить ключи от дома под ковриком. Ubuntu 24 из коробки даёт нам OpenSSH Server, который работает… но не так, как нужно для продакшена. Сегодня разберём, как превратить твой SSH в неприступную крепость, не потеряв при этом удобство работы.

Статистика неумолима: 90% успешных атак на серверы начинаются именно с SSH. Брутфорс по SSH-портам идёт круглосуточно — боты сканируют диапазоны IP и долбят стандартные порты тысячами попыток в минуту. Если твой сервер торчит в интернете с дефолтными настройками, это вопрос времени.

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

Анатомия атаки: как ломают SSH

Прежде чем защищаться, нужно понять, от чего именно. Основные векторы атак на SSH:

Brute Force — перебор паролей по словарям
Dictionary attacks — атака по популярным логинам/паролям
Credential stuffing — использование украденных баз данных
Exploits — эксплуатация уязвимостей в старых версиях OpenSSH
Man-in-the-Middle — подмена ключей при первом подключении

Самый частый сценарий: бот находит твой сервер, видит открытый 22 порт, начинает перебирать admin/admin, root/root, root/123456 и так далее. Если у тебя слабый пароль или включён root-доступ — игра окончена.

Базовая конфигурация: первые шаги

Начнём с основ. Открываем конфиг SSH:

sudo nano /etc/ssh/sshd_config

Вот минимальный набор изменений для повышения безопасности:

# Меняем стандартный порт
Port 2222

# Отключаем root-доступ
PermitRootLogin no

# Только аутентификация по ключам
PasswordAuthentication no
PubkeyAuthentication yes

# Отключаем пустые пароли
PermitEmptyPasswords no

# Ограничиваем количество попыток
MaxAuthTries 3

# Таймаут для неактивных сессий
ClientAliveInterval 300
ClientAliveCountMax 2

# Отключаем X11 Forwarding (если не нужен)
X11Forwarding no

# Ограничиваем пользователей
AllowUsers your_username

# Отключаем устаревшие методы аутентификации
ChallengeResponseAuthentication no
UsePAM no

После изменений перезапускаем SSH:

sudo systemctl restart sshd
sudo systemctl status sshd

Важно: Не закрывай текущую SSH-сессию! Открой новую вкладку терминала и проверь, что можешь подключиться с новыми настройками. Если что-то пошло не так, у тебя будет возможность откатиться.

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

Пароли — это прошлый век. SSH-ключи не только безопаснее, но и удобнее. Генерируем пару ключей на клиенте:

# Генерируем ED25519 ключ (более безопасный, чем RSA)
ssh-keygen -t ed25519 -C "your_email@example.com"

# Если система не поддерживает ED25519, используем RSA 4096
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

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

# Автоматически
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@server_ip

# Или вручную
cat ~/.ssh/id_ed25519.pub | ssh username@server_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Настраиваем правильные права доступа на сервере:

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

Продвинутые настройки безопасности

Теперь займёмся более серьёзными вещами. Добавляем в /etc/ssh/sshd_config:

# Ограничиваем алгоритмы шифрования (только современные)
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

# Ограничиваем MAC алгоритмы
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512

# Ограничиваем алгоритмы обмена ключами
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

# Отключаем сжатие (защита от CRIME атак)
Compression no

# Строгая проверка режимов файлов
StrictModes yes

# Логирование
LogLevel VERBOSE
SyslogFacility AUTH

Fail2Ban: автоматическая защита от брутфорса

Fail2Ban — это твой верный страж, который банит IP-адреса после нескольких неудачных попыток входа. Устанавливаем:

sudo apt update
sudo apt install fail2ban

Создаём локальный конфиг:

sudo nano /etc/fail2ban/jail.local

Добавляем конфигурацию для SSH:

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
ignoreip = 127.0.0.1/8 192.168.1.0/24

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600

Запускаем и проверяем:

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

Дополнительные уровни защиты

Port Knocking

Суть в том, что SSH-порт закрыт по умолчанию и открывается только после “стука” в определённую последовательность портов. Устанавливаем knockd:

sudo apt install knockd

Конфигурируем /etc/knockd.conf:

[options]
        UseSyslog

[openSSH]
        sequence    = 7000,8000,9000
        seq_timeout = 5
        command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 2222 -j ACCEPT
        tcpflags    = syn

[closeSSH]
        sequence    = 9000,8000,7000
        seq_timeout = 5
        command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 2222 -j ACCEPT
        tcpflags    = syn

Двухфакторная аутентификация

Устанавливаем Google Authenticator:

sudo apt install libpam-google-authenticator

Настраиваем для пользователя:

google-authenticator

Редактируем /etc/pam.d/sshd:

auth required pam_google_authenticator.so

В /etc/ssh/sshd_config добавляем:

ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Мониторинг и логирование

Настраиваем детальное логирование SSH-активности. Создаём скрипт для мониторинга:

#!/bin/bash
# ssh_monitor.sh

tail -f /var/log/auth.log | while read line; do
    echo "$line" | grep -E "(Failed|Accepted|Invalid)" | \
    while read event; do
        echo "$(date): $event" >> /var/log/ssh_security.log
        
        # Отправляем критические события в Telegram (опционально)
        if echo "$event" | grep -q "Failed"; then
            # Здесь можно добавить отправку уведомлений
            echo "Security alert: $event"
        fi
    done
done

Автоматизация и скрипты

Создаём скрипт для автоматической настройки SSH:

#!/bin/bash
# secure_ssh.sh

# Создаём бэкап оригинального конфига
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

# Применяем безопасные настройки
cat > /etc/ssh/sshd_config << 'EOF'
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
ChallengeResponseAuthentication no
UsePAM no
LogLevel VERBOSE
StrictModes yes
Compression no

# Современные алгоритмы шифрования
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256
EOF

# Перезапускаем SSH
systemctl restart sshd

echo "SSH secured successfully!"

Производительность vs безопасность

Сравнение влияния различных настроек на производительность:

Настройка	Влияние на безопасность	Влияние на производительность	Рекомендация
ED25519 ключи	Высокое	Позитивное (быстрее RSA)	Обязательно
ChaCha20-Poly1305	Высокое	Хорошее на ARM	Для современных систем
Compression no	Среднее	Негативное на медленных каналах	Зависит от сценария
Verbose logging	Высокое	Минимальное	Обязательно

Альтернативные решения

Если стандартного OpenSSH недостаточно, рассмотри альтернативы:

mosh — Mobile Shell, устойчивый к разрывам соединения
eternal-terminal — с автоматическим переподключением
ZeroTier — создание виртуальных сетей для доступа к серверам
Tailscale — VPN на базе WireGuard для команд

Установка mosh:

sudo apt install mosh
# Открываем UDP порты 60000-61000 в firewall
sudo ufw allow 60000:61000/udp

Интеграция с современными инструментами

SSH отлично интегрируется с инфраструктурными инструментами:

Ansible

# ansible.cfg
[defaults]
host_key_checking = False
remote_user = deploy
private_key_file = ~/.ssh/deploy_key

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=60s -o UserKnownHostsFile=/dev/null

Docker

Создание SSH-туннеля для Docker-контекста:

docker context create remote --docker "host=ssh://user@remote-server"
docker context use remote

Практические кейсы

Кейс 1: Компания с удалённой командой

Настройка централизованного управления ключами через AuthorizedKeysCommand:

AuthorizedKeysCommand /usr/local/bin/get_keys.sh
AuthorizedKeysCommandUser nobody

Кейс 2: Высоконагруженный сервер

Оптимизация для множественных подключений:

MaxStartups 30:30:100
MaxSessions 20
LoginGraceTime 30

Интересные факты и нестандартные применения

SSH как SOCKS прокси: ssh -D 8080 user@server — мгновенный прокси-сервер
Файловая система по SSH: sshfs user@server:/path /local/mount
Reverse tunnel: ssh -R 8080:localhost:80 user@server — доступ к локальному веб-серверу из интернета
Jump host: ssh -J jumphost finalserver — подключение через промежуточный сервер

SSH можно использовать для создания VPN-подобных подключений:

ssh -w 0:0 root@server
# Настройка интерфейсов tun0 на клиенте и сервере

Новые возможности в Ubuntu 24

Ubuntu 24 поставляется с OpenSSH 9.0+, который включает:

FIDO2/WebAuthn поддержка — аутентификация через USB-ключи
Улучшенная поддержка контейнеров — безопасное подключение к Docker/Podman
Quantum-resistant алгоритмы — готовность к постквантовой криптографии

Настройка FIDO2:

ssh-keygen -t ed25519-sk -C "hardware_key"
# Потребуется физическое касание ключа

Автоматизация мониторинга

Создаём systemd-сервис для автоматического мониторинга:

# /etc/systemd/system/ssh-monitor.service
[Unit]
Description=SSH Security Monitor
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/ssh_monitor.sh
Restart=always
User=monitor

[Install]
WantedBy=multi-user.target

Для более серьёзного мониторинга интегрируем с Prometheus:

#!/bin/bash
# ssh_exporter.sh
while true; do
    failed_attempts=$(grep "Failed password" /var/log/auth.log | wc -l)
    echo "ssh_failed_attempts $failed_attempts" > /var/lib/prometheus/ssh_metrics.prom
    sleep 60
done

Заключение и рекомендации

Защита SSH — это не разовая задача, а непрерывный процесс. Вот финальный чек-лист для продакшен-серверов:

✅ Смена стандартного порта
✅ Отключение root-доступа
✅ Аутентификация только по ключам
✅ Fail2Ban для защиты от брутфорса
✅ Современные алгоритмы шифрования
✅ Мониторинг и логирование
✅ Регулярные обновления
✅ Резервный план доступа

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

Если ты только начинаешь работу с серверами, обрати внимание на готовые решения для хостинга. Можешь заказать VPS с уже настроенной базовой безопасностью или выделенный сервер для более требовательных задач.

Дополнительные ресурсы для изучения:

Безопасность SSH — это основа инфраструктурной безопасности. Потрать время на правильную настройку сейчас, и это сэкономит тебе месяцы головной боли в будущем. Хакеры не спят, и твоя защита тоже не должна дремать.

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

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