Атака "человек-в-середине" представляет угрозу безопасности при аутентификации SSH с использованием ключей?

Я не эксперт в области сетевой безопасности, поэтому прошу прощения, если этот вопрос не очень умный:). Я автоматизирую логины для некоторых машин, используя ssh. В настоящее время я избегаю предупреждений ключа хоста, используя StrictHostKeyChecking no.
Я наивно понимаю, что кто-то может выдавать себя за сервера, и я рискую потерять его пароль, если это так. Однако, если я использую только аутентификацию на основе открытого/закрытого ключа (используя PasswordAuthentication no), может ли злоумышленник по-прежнему причинять вред?

Итак, в основном, с ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no":

1) Может ли злоумышленник расшифровать мой закрытый ключ?

2) Существуют ли другие угрозы безопасности?

С уважением,

В JP

Ответ 1

Нет. Или по крайней мере... не напрямую. Поскольку вы никогда не отправляете свой секретный ключ, клавиша будет безопасной. Это не означает, что человек, выполняющий атаку MITM, не может выполнять команды и/или читать выходные данные, которые вы получаете.
Да, есть и другие риски. Если лицо, выполняющее атаку MITM, перенаправляет данные на правильный сервер, чем может быть возможно использовать ваш закрытый ключ для выполнения команд на компьютере, к которому вы пытались получить доступ.

Ответ 2

Фактически, метод аутентификации с открытым ключом предотвращает атаку MITM. Насколько я могу судить, это совпадение не по дизайну. Хотя полномасштабная атака MITM невозможна, злоумышленник все же может выдавать себя за сервер: получать команды и данные, отправленные клиентом, и возвращать произвольные ответы клиенту. Поэтому, возможно, было бы неплохо отключить проверку ключа хоста сервера.

Ниже приведено объяснение, почему полномасштабная атака MITM не может быть выполнена при использовании аутентификации с открытым ключом. В моем сообщении в блоге http://www.gremwell.com/ssh-mitm-public-key-authentication содержится более подробная информация.

Во время атаки MITM злоумышленник вставляет себя между клиентом и сервером и устанавливает два отдельных SSH-соединения. Каждое соединение будет иметь свой собственный набор ключей шифрования и идентификатор сеанса.

Для аутентификации с использованием метода открытого ключа клиент использует закрытый ключ для подписи совокупности данных (включая идентификатор сеанса) и отправки подписи на сервер. Ожидается, что сервер проверит подпись и отклонит попытку аутентификации, если подпись недопустима. Как объяснялось выше, сервер и клиент будут иметь совершенно иное представление о том, какой идентификатор сеанса должен быть. Это означает, что сервер не может принять подпись, сгенерированную клиентом при атаке MITM.

Как упоминалось выше, идентификаторы сеансов гарантируют, что они будут отличаться для соединений клиент-MITM и MITM-сервера. Они рассчитываются из общей тайны, заключенной с Диффи-Хеллманом, отдельно или по каждому соединению. Это означает, что злоумышленник не может организовать два сеанса с одинаковыми идентификаторами сеанса.