Во время первого контакта с сервером через ssh пользователю предоставляется открытый ключ сервера выбранного алгоритма ключа для его проверки. После проверки результат обычно сохраняется в ~/.ssh/known_hosts файл для противодействия последующим атакам MITM.
$ ssh host.example.com
The authenticity of host 'host.example.com (1.2.3.4)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)?
Это, очевидно, не поможет против MITM-атаки на первое соединение и просто перенесет проблему на пользователя, который теперь должен иметь какой-то процесс для проверки представленного открытого ключа - и все мы знаем, чем это заканчивается.
Можно ли распространять ключи ssh-сервера, подписанные корпоративным центром сертификации, для противодействия MITM-атакам при первом контакте? Инфраструктура открытых и закрытых ключей с цепочкой сертификатов в целом поддерживает это, но я никогда не видел, чтобы она использовалась в корпоративной среде для защиты серверов ssh.
Общая идея - доверять ключу CA для набора хостов:
trust *.example.com SHA256:<fingerprint(public key(corporate-ca))>
и каждый хост, который это сделал и был подписан ЦС, является доверенным:
ca.example.com
+- host.example.com
Это похоже на то, как защищается HTTPS, и поскольку ssh использует ту же базовую технологию - что-то подобное уже реализовано в OpenSSH, и я просто не нашел его?
Это возможно.
Цитирование документы:
AUTHORIZED_KEYS FILE FORMAT
[...]
cert-authority
Specifies that the listed key is a certification authority (CA)
that is trusted to validate signed certificates for user authentication.
Certificates may encode access restrictions similar to these key options.
If both certificate restrictions and key options are present, the most
restrictive union of the two is applied.
Шаги для этого:
ssh-keygen -f server_ca
ssh-keygen -t ecdsa -b 521 -N '' -C 'somehost.example.com' -f ssh-ecdsa.key
ssh-keygen -s server_ca -I somehost.example.com -h -n 'somehost.example.com,somehost,<list of SANs>,<list of IPv4>,<list of IPv6>' -V +3650d ssh-ecdsa.key
/etc/ssh, редактировать /etc/ssh/sshd_config):HostCertificate /etc/ssh/ssh-ecdsa.key-cert.pub
HostKey /etc/ssh/ssh-ecdsa.key
@cert-authority example.com ssh-rsa AAAA[...]
Ноты:
По ссылкам ниже вы найдете дополнительную информацию, особенно о том, как настроить подпись ключей для пользователей.
Ссылки:
Другой подход - публиковать отпечатки ключей SSH в DNS как записи SHFP:
См. RFC 4255 https://tools.ietf.org/html/rfc4255
Это делает проверку открытого ключа автоматизированным процессом после того, как вы установите VerifyHostKeyDNS к yes в (глобальных) настройках клиента ssh по умолчанию.
Если он находится в корпоративной среде, у вас также может быть централизованно управляемый список ключей SSH для всех ваших машин, которые затем можно развернуть на /etc/ssh/ssh_known_hosts на всех клиентах с помощью вашего любимого инструмента управления конфигурацией. Это также можно использовать для прямой аутентификации на основе хоста между машинами. (Централизованное управление ключами хоста SSH также полезно для предотвращения нежелательных изменений ключа хоста при переустановке сервера.)
Конечно, этот подход работает только для «внутреннего» доступа по SSH, когда и клиент, и сервер находятся под вашим контролем. Если вам нужны произвольные внешние пользователи для SSH (и вы не можете просто предоставить им файл known_hosts), возможно, вам подойдут записи SSHFP в DNS с защитой DNSSEC.