Nokta_strigo 28 авг 2018 в 21:39

Что записано в файле .ssh/known_hosts

5 мин

62K

Информационная безопасность*Криптография*Сетевые технологии*

+43

Комментарии 15

xcore78 29 авг 2018 в 00:46

DSA (ssh-dss) к использованию не рекомендуется, его поддержка уже выключена по-умолчанию в openssh 7 и выше.

www.openssh.com/legacy.html

Nokta_strigo 29 авг 2018 в 01:29

Да, OpenSSH7.2 у меня по-умолчанию ssh_host_dsa_key сгенерировал. Но подключения с ним не принимает.

Daniyar94 29 авг 2018 в 00:56

Не понимаю смысл? Потенциальный злоумышленник не может просто постучатся к машине, словить ее публичный ключ, и потом просто предоставить его жертве (скажем скомпрометировал DNS сервера у жертвы и перенаправляет его на свою машину)?

Nokta_strigo 29 авг 2018 в 01:17

Во время обмена ключами сервер подписывает своим приватным ключём свою посылку (она каждый раз разная, к тому же включает число, полученное от клиента — оно тоже каждый раз разное и генерируется клиентом). Если у злоумышленника нет приватного ключа, то он не сможет её подписать и клиент прекратит установление соединения. Повторно передать записанную посылку он тоже не может, т.к. клиент увидит, что она не соответствует тому, что он только что послал.

Dmitri-D 29 авг 2018 в 03:04

Если у злоумышленника нет приватного ключа, то он не сможет её подписать и клиент прекратит установление соединени

не совсем так. Если у злоумышленика нет приватного ключа _вашего_ сервера то он использует свой. Поэтому его public ключ и, соответственно, fingerprint тоже отличается, от того что клиент запомнил в своем локальном known_hosts файле. Обнаружив изменения, клиент _не_ разорвет соединение. Он сообщит пользователю об изменении идентификации сервера — ровно то сообщение, что в шапке статьи, и если клиент проигнорирует его, т.е. согласится с изменениями, то MITM вполне так себе перехватит сессию и будет видеть весь трафик в исходном виде

andreymal 29 авг 2018 в 03:11

Он сообщит пользователю об изменении идентификации сервера

… и разорвёт соединение :) Чтобы MitM случился, пользователь должен не «согласиться с изменениями» (ничего подобного в этом случае нет), а ручками вычистить несовпадающий ключ из known_hosts и подключиться заново

Dmitri-D 29 авг 2018 в 03:21

зависит от опции
-o StrictHostKeyChecking=no или yes

andreymal 29 авг 2018 в 03:27

Нет, разорвёт, смотрите сами:

Заголовок спойлера

(а вы хитрый, отредактировали коммент, пока я гифку записывал. Кто-то в здравом уме трогает эту опцию?)

Dmitri-D 29 авг 2018 в 03:31

разумеется отредактировал, имею право 5 минут )).
Я просто привык к этой опции в no и ниже написал почему она no

angapov 29 авг 2018 в 11:52

StrictHostKeyChecking=no используется например в облачных CI/CD средах, где виртуалки в определенной подсети многократно создаются и убиваются. Там это вполне оправданно.

Dmitri-D 29 авг 2018 в 03:30

кстати, если ключ на сервере поменялся, а вы должны периодически его менять в полном соответствии с предписаниями и рекомендациями ssh, или если обновась версия и добавились новые HMAC методы (и заодно задепрекейтились старые), то fingerprint поменяется и это будет false positive. Вам нужно будет на всех клиентских хостах ручками чистить. Хорошо если вы один сам себе режиссер. А если это компания вроде нашей, где 1500 человек разработчиков и десятки тысяч серверов то, каждое обновление серверных ключей или HMAC — и полный геморрой с чисткой known_hosts. Неудобное решение. Централизованно подписанные сертификаты были бы удобнее.

Nokta_strigo 29 авг 2018 в 10:22

В живую централизовано подписанных сертификатов в SSH не видел, но мануале к Убунте пишут про метку "@cert-authority" как раз в known_hosts, указывающую что эта строка описывает доверенный CA.
В RFC 4251 пишут что CA тоже могут поддерживаться. Ещё есть RFC 6187 X.509v3 Certificates for Secure Shell Authentication. Ну и упомянутые в статье алгоритмы, основанные на PGP тоже должны давать возможность централизации доверия.