Цепочка сертификатов ssh сервера против MITM-атак?
Во время первого контакта с сервером через 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.
Шаги для достижения этой цели:
- Создание ключа CA сервера SSH:
ssh-keygen -f server_ca
- Создание ключа хоста сервера SSH:
ssh-keygen -t ecdsa -b 521 -N '' -C 'somehost.example.com' -f ssh-ecdsa.key
- Подпишите ключ хоста своим ключом CA:
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
- Разверните ключ хоста + сертификат на вашем SSH-сервере (скопируйте сертификат и ключ в
/ etc / ssh, отредактируйте/ etc / ssh / sshd_config):
HostCertificate /etc/ssh/ssh-ecdsa.key-cert.pub
HostKey /etc/ssh/ssh-ecdsa.key
- Настройте своих клиентов доверять вашему ключу CA для идентификации хостов (~ / .ssh / known_hosts)
@cert-authority example.com ssh-rsa AAAA[...]
Примечания :
- Он несовместим с обычными PKI X.509.
- Ведение (и использование) списка отзыва ключей ( KRL) необходим. Подробности см. В Поваренной книге OpenSSH .
- Громоздко, подумайте об использовании чего-то вроде Vault и инструмента управления конфигурацией для автоматизации этого.
- Посмотрите на Monkeysphere проект, посвященный идее «сети доверия для SSH».
Дополнительную информацию можно найти по ссылкам ниже, особенно о том, как настроить это для подписи ключей для пользователей.
Ссылки:
В корпоративной среде вы также можете иметь централизованно управляемый список SSH-ключи всех ваших машин, которые вы затем можете развернуть в / etc / ssh / ssh_known_hosts на всех клиентах с помощью вашего любимого инструмента управления конфигурацией. Это также можно использовать для прямой аутентификации на основе хоста между машинами. (Централизованное управление ключами хоста SSH также полезно для предотвращения нежелательных изменений ключа хоста при переустановке сервера.)
Конечно, этот подход работает только для «внутреннего» доступа SSH, когда и клиент, и сервер находятся под вашим контролем. Если вам нужны произвольные внешние пользователи для SSH (и вы не можете просто предоставить им файл known_hosts), возможно, вам подойдут записи SSHFP в DNS с защитой DNSSEC.
Другой подход заключается в публикации отпечатков ключей SSH в DNS в виде записей SHFP:
См. RFC 4255 https://tools.ietf.org/html/rfc4255
. Это делает проверку открытого ключа автоматическим процессом, если вы установите VerifyHostKeyDNS на yes в (глобальных) настройках клиента ssh по умолчанию.