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

[xcore78]

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

www.openssh.com/legacy.html

[Nokta_strigo]

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

[Daniyar94]

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

[Nokta_strigo]

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

[Dmitri-D]

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

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

[andreymal]

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

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

[Dmitri-D]

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

[andreymal]

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

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

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

[Dmitri-D]

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

[angapov]

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

[Dmitri-D]

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

[Nokta_strigo]

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

[Nokta_strigo]

Мануал к Ubuntu про генерацию сертификатов для SSH (не X.509).

[nvv]

Это супер краткий пересказ документации с уточнением, что видел так в одной системе?

[g0rd1as]

Я когда увидел заголовок, как-то даже слегка пригорел… :) Типа: «Чтоа?! Никто разве этот файл не читал?!» Провокация, однако. :-D