OpenSSH жёсткое шифрование: отключаем SHA‑1 и CBC, задаём KEX и MAC современного уровня

Любая атака на SSH — это удар по входной двери продовой инфраструктуры. Хорошая новость: в 2025 году OpenSSH из коробки уже избегает многих слабостей. Плохая: на серверах с историей легко встретить включённые SHA‑1, CBC и устаревшие KEX. В статье показываю, как жёстко закрутить криптополитику: запретить SHA‑1 и CBC, выбрать современные KEX и MAC, не убив совместимость и доступность.

Почему SHA‑1 и CBC — мимо, а AEAD, SHA‑2 и Curve25519 — в дело

Коротко по сути:

• SHA‑1 компрометирован коллизиями; его использование в подписи ключей (ssh-rsa) и MAC — риск. Выбор: SHA‑2 (256/512).
• CBC‑режимы (aes*-cbc) имеют уязвимости на уровне паддинга и оракулов. Предпочтительно AEAD: chacha20-poly1305@openssh.com, aes*-gcm@openssh.com.
• KEX: быстрый и стойкий curve25519-sha256 и гибридный PQ‑вариант sntrup761x25519-sha512@openssh.com. В качестве бэкапа — ecdh-sha2-nistp256, diffie-hellman-group16-sha512.
• MAC: при AEAD не нужен отдельный MAC; для CTR‑шифров используйте только *-etm@openssh.com на SHA‑2: umac-128-etm@openssh.com, hmac-sha2-256-etm@openssh.com, hmac-sha2-512-etm@openssh.com.

Подготовка: инвентаризация и план изменений

Прежде чем менять криптосеты, ответьте на два вопроса:

1. Какая версия OpenSSH на серверах и клиентах? Проверьте ssh -V и версию пакета OpenSSH на сервере. Нужны как минимум 8.4+, лучше 9.x.
2. Какие клиенты реально подключаются? Старые PuTTY, сетевые устройства, устаревшие либы могут сломаться. Проверьте логи и баннеры клиента.

Быстрая инвентаризация поддерживаемых алгоритмов на хосте:

ssh -Q kex
ssh -Q cipher
ssh -Q mac
ssh -Q key

Если есть отдельный тестовый стенд на VDS, сначала обкатайте политику там.

Рекомендуемые наборы алгоритмов на 2025 год

Сервер (sshd):

• Ciphers: chacha20-poly1305@openssh.com, aes256-gcm@openssh.com, aes128-gcm@openssh.com, затем CTR как fallback.
• MACs: только ETM и SHA‑2: umac-128-etm@openssh.com, hmac-sha2-512-etm@openssh.com, hmac-sha2-256-etm@openssh.com.
• KexAlgorithms: sntrup761x25519-sha512@openssh.com, curve25519-sha256, curve25519-sha256@libssh.org, затем ecdh-sha2-nistp256, при необходимости diffie-hellman-group16-sha512.
• HostKey/подписи: ssh-ed25519 и RSA на SHA‑2 (rsa-sha2-512, rsa-sha2-256). Отключаем ssh-rsa (RSA+SHA‑1). ECDSA допустим как бэкап.

Практика: обновляем sshd_config с бэкапом и проверкой

Создадим резервную копию и проверим синтаксис:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak-$(date +%F)
sudo chmod 600 /etc/ssh/sshd_config.bak-$(date +%F)
sudo sshd -t -f /etc/ssh/sshd_config

Базовый жёсткий профиль. Расставляйте приоритеты слева направо: сначала AEAD и гибридный KEX, затем бэкапы.

# /etc/ssh/sshd_config (фрагмент)
# Ключи хоста
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_rsa_key

# Современные шифры и MAC
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Современные KEX
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,diffie-hellman-group16-sha512

# Подписи и хост-алгоритмы: без SHA-1
HostKeyAlgorithms ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256
CASignatureAlgorithms rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ecdsa-sha2-nistp256

# Дополнительно полезно
Protocol 2
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
AllowTcpForwarding yes
AllowAgentForwarding yes
ClientAliveInterval 300
ClientAliveCountMax 2

Важно: на старых релизах OpenSSH директива называлась PubkeyAcceptedKeyTypes. Если sshd -T ругается на PubkeyAcceptedAlgorithms, используйте прежнее имя опции.

Проверка и перезагрузка без обрыва текущих сессий:

sudo sshd -t
sudo systemctl reload sshd

Тонкая совместимость через Match‑блоки

Если есть единичные легаси‑клиенты, не размягчайте глобальную политику. Лучше сделайте адресный Match и добавьте только необходимые алгоритмы без SHA‑1 и CBC.

# Пример: для подсети техподдержки оставить ecdh и ctr как временный бэкап
Match Address 203.0.113.0/24
  KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256
  Ciphers aes256-ctr,aes192-ctr,aes128-ctr
  MACs umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com

Не добавляйте diffie-hellman-group14-sha1, ssh-rsa, hmac-sha1, aes*-cbc даже во временных исключениях.

Проверяем результат: какие алгоритмы реально торгуются

Локальная проверка баннера и набора по -vvv:

ssh -vvv user@server echo ok |& sed -n '1,120p'

В отладочном выводе ищите строки kex:, cipher:, MAC:, server host key algo: — там будут согласованные алгоритмы. Узкий тест с явным выбором:

ssh -oKexAlgorithms=curve25519-sha256 -oCiphers=chacha20-poly1305@openssh.com -oMACs=umac-128-etm@openssh.com user@server uname -a

Инвентаризация снаружи: можно использовать утилиты аудита SSH, либо nmap с NSE‑скриптом перечисления алгоритмов.

nmap -p22 --script ssh2-enum-algos server.example

Клиентская сторона: закрепляем политику в ~/.ssh/config

Чтобы ваши исходящие подключения тоже не проваливались на SHA‑1 и CBC, пропишите явные предпочтения для клиента.

# ~/.ssh/config (фрагмент)
Host *
  HostKeyAlgorithms +ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256
  PubkeyAcceptedAlgorithms +ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256
  KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256
  Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
  MACs umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
  GSSAPIAuthentication no
  ServerAliveInterval 60
  ServerAliveCountMax 3

Символ + в HostKeyAlgorithms/PubkeyAcceptedAlgorithms означает добавление к дефолтному списку. Если хотите жёстко зафиксировать полный список, уберите +.

RSA‑SHA2 и ключи Ed25519: что важно учесть

Отключая ssh-rsa (RSA+SHA‑1), убедитесь, что:

• На сервере есть ключ ssh_host_ed25519_key. Если нет — сгенерируйте: sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N "".
• Пользовательские ключи RSA у разработчиков подписаны SHA‑2. Если импортированы старые ssh-rsa, пересоздайте или перевыпустите.
• Для межсерверной аутентификации обновите authorized_keys и known_hosts, чтобы устранить предупреждения о несовпадении алгоритмов. Подробно про SSH CA, TTL и отзыв — в материале SSH CA, TTL и отзыв ключей.

Безопасное внедрение: staged rollout и откат

Рекомендую внедрять в три шага:

1. Обкатка на тестовом сервере/окне обслуживания. Проверка типичных клиентов и CI/CD.
2. Пилот на 10–20% серверов с мониторингом отказов в SSH‑логах. Аналитика по IP/AGENT.
3. Полный rollout с включением Match‑исключений для остаточных легаси до миграции.

План отката должен быть письменным и коротким:

Если доступ потерян, подключиться через альтернативную консоль (IPMI/серийка/консоль). Восстановить бэкап и перезагрузить sshd. После — расследовать по loglevel DEBUG3 на тесте.

sudo cp /etc/ssh/sshd_config.bak-$(date +%F) /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl restart sshd

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Наблюдаем и логируем

Поднимите уровень логов на время миграции и отслеживайте отклонённые алгоритмы:

# Временно для диагностики
LogLevel VERBOSE

Ищите сообщения об отказах рукопожатия, неподдерживаемых алгоритмах ключа, невозможности согласовать KEX. Это позволит точечно добавить безопасные fallback в Match‑блок.

Автоматизация Ansible: минимальный пример

Фрагмент роли, которая безопасно применяет криптополитику и делает бэкап:

---
- name: Harden OpenSSH crypto
  hosts: sshd
  become: true
  tasks:
    - name: Backup sshd_config
      copy:
        src: /etc/ssh/sshd_config
        dest: "/etc/ssh/sshd_config.bak-{{ ansible_date_time.date }}"
        mode: '0600'
        remote_src: true

    - name: Deploy hardened options
      blockinfile:
        path: /etc/ssh/sshd_config
        marker: "# {mark} FAST HARDENING"
        block: |
          Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
          MACs umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
          KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,diffie-hellman-group16-sha512
          HostKeyAlgorithms ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256
          PubkeyAcceptedAlgorithms ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256
          CASignatureAlgorithms rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ecdsa-sha2-nistp256

    - name: Validate sshd_config
      command: sshd -t
      changed_when: false

    - name: Reload sshd
      service:
        name: sshd
        state: reloaded

FAQ по совместимости

Что с очень старыми клиентами?

Если клиент не умеет SHA‑2 подписи или Curve25519, почти всегда он поддерживает ecdh-sha2-nistp256 и CTR‑шифры. Этого достаточно без возврата к SHA‑1 и CBC. Если нет — это повод немедленно обновить клиент.

Нужно ли включать ECDSA?

Да, как дополнительный бэкап. Основной упор — ssh-ed25519. ECDSA на NIST P‑256 корректен, но Ed25519 проще и быстрее.

Где смотреть, почему рукопожатие не сошлось?

Поднимите LogLevel на сервере, а на клиенте используйте -vvv. Там видно, какие списки предлагали стороны и почему отказались.

Нужно ли включать sntrup761x25519?

Да, это гибридный KEX с примесью постквантовой стойкости, доступный в OpenSSH 8+. Он быстрый и безопасный. Оставляйте его первым в списке.

Итоги и чек‑лист

• Убрали SHA‑1: нет ssh-rsa, нет hmac-sha1*, нет diffie-hellman-*-sha1.
• Отключили CBC: нет aes*-cbc. Приоритет AEAD: chacha20-poly1305, aes*-gcm.
• Современный KEX: sntrup761x25519, curve25519-sha256, затем ecdh-sha2-nistp256.
• Подписи: ssh-ed25519 и rsa-sha2-512/256. Старый ssh-rsa — запрещён.
• Проверка: sshd -t, -vvv с клиента, периодический аудит алгоритмов.
• Совместимость: точечные Match‑блоки вместо размягчения глобальной политики.

Такой профиль сохраняет устойчивость к известным атакам на CBC и SHA‑1, даёт быстрые и проверенные KEX/MAC, а также управляемый путь для легаси‑подключений. Применяйте поэтапно, фиксируйте договорённости с командами и держите под рукой план отката — и SSH станет значительно крепче.