Фактически, метод аутентификации с открытым ключом предотвращает атаку MITM. Насколько я могу сказать, это совпадение, а не по замыслу. Хотя полноценная MITM-атака невозможна, злоумышленник все же может выдать себя за сервер: получать команды и данные, отправленные клиентом, и возвращать клиенту произвольные ответы. Так что, в конце концов, было бы не очень хорошей идеей отключить проверку ключа хоста сервера.
Ниже приведено объяснение, почему полноценная атака MITM не может быть выполнена при использовании аутентификации с открытым ключом. В моем блоге http://www.gremwell.com/ssh-mitm-public-key-authentication содержится еще несколько деталей.
Во время атаки MITM злоумышленник вставляет себя между клиентом и сервером и устанавливает два отдельных соединения SSH. Каждое соединение будет иметь собственный набор ключей шифрования и идентификатор сеанса.
Для аутентификации с использованием метода открытого ключа клиент использует закрытый ключ для подписи пакета данных (включая идентификатор сеанса) и отправляет подпись на сервер. Ожидается, что сервер проверит подпись и отклонит попытку аутентификации, если подпись недействительна. Как объяснено выше, сервер и клиент будут иметь совершенно разные представления о том, каким должен быть идентификатор сеанса. Это означает, что у сервера нет возможности принять подпись, сгенерированную клиентом при атаке MITM.
Как упоминалось выше, идентификаторы сеансов гарантированно будут разными для соединений клиент-MITM и MITM-сервер. Они рассчитываются на основе общего секрета, согласованного с Диффи-Хеллманом, отдельно или по каждому соединению. Это означает, что злоумышленник не может организовать два сеанса с одинаковыми идентификаторами сеансов.