Comments 15
DSA (ssh-dss) к использованию не рекомендуется, его поддержка уже выключена по-умолчанию в openssh 7 и выше.
www.openssh.com/legacy.html
www.openssh.com/legacy.html
Не понимаю смысл? Потенциальный злоумышленник не может просто постучатся к машине, словить ее публичный ключ, и потом просто предоставить его жертве (скажем скомпрометировал DNS сервера у жертвы и перенаправляет его на свою машину)?
Во время обмена ключами сервер подписывает своим приватным ключём свою посылку (она каждый раз разная, к тому же включает число, полученное от клиента — оно тоже каждый раз разное и генерируется клиентом). Если у злоумышленника нет приватного ключа, то он не сможет её подписать и клиент прекратит установление соединения. Повторно передать записанную посылку он тоже не может, т.к. клиент увидит, что она не соответствует тому, что он только что послал.
Если у злоумышленника нет приватного ключа, то он не сможет её подписать и клиент прекратит установление соединени
не совсем так. Если у злоумышленика нет приватного ключа _вашего_ сервера то он использует свой. Поэтому его public ключ и, соответственно, fingerprint тоже отличается, от того что клиент запомнил в своем локальном known_hosts файле. Обнаружив изменения, клиент _не_ разорвет соединение. Он сообщит пользователю об изменении идентификации сервера — ровно то сообщение, что в шапке статьи, и если клиент проигнорирует его, т.е. согласится с изменениями, то MITM вполне так себе перехватит сессию и будет видеть весь трафик в исходном виде
Он сообщит пользователю об изменении идентификации сервера
… и разорвёт соединение :) Чтобы MitM случился, пользователь должен не «согласиться с изменениями» (ничего подобного в этом случае нет), а ручками вычистить несовпадающий ключ из known_hosts и подключиться заново
зависит от опции
-o StrictHostKeyChecking=no или yes
-o StrictHostKeyChecking=no или yes
кстати, если ключ на сервере поменялся, а вы должны периодически его менять в полном соответствии с предписаниями и рекомендациями ssh, или если обновась версия и добавились новые HMAC методы (и заодно задепрекейтились старые), то fingerprint поменяется и это будет false positive. Вам нужно будет на всех клиентских хостах ручками чистить. Хорошо если вы один сам себе режиссер. А если это компания вроде нашей, где 1500 человек разработчиков и десятки тысяч серверов то, каждое обновление серверных ключей или HMAC — и полный геморрой с чисткой known_hosts. Неудобное решение. Централизованно подписанные сертификаты были бы удобнее.
В живую централизовано подписанных сертификатов в SSH не видел, но мануале к Убунте пишут про метку "@cert-authority" как раз в known_hosts, указывающую что эта строка описывает доверенный CA.
В RFC 4251 пишут что CA тоже могут поддерживаться. Ещё есть RFC 6187 X.509v3 Certificates for Secure Shell Authentication. Ну и упомянутые в статье алгоритмы, основанные на PGP тоже должны давать возможность централизации доверия.
В RFC 4251 пишут что CA тоже могут поддерживаться. Ещё есть RFC 6187 X.509v3 Certificates for Secure Shell Authentication. Ну и упомянутые в статье алгоритмы, основанные на PGP тоже должны давать возможность централизации доверия.
Мануал к Ubuntu про генерацию сертификатов для SSH (не X.509).
Это супер краткий пересказ документации с уточнением, что видел так в одной системе?
Sign up to leave a comment.
Что записано в файле .ssh/known_hosts