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

Question

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

Так в основном с ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" :

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

2) Есть ли другие угрозы безопасности?

С уважением,

JP

Answer 1

1. Нет. Или по крайней мере ... не напрямую. Так как вы никогда не отправляете свой закрытый ключ, ключ будет в безопасности. Это не значит, что человек, который выполняет атаку MITM, не может выполнять команды и/или читать полученные выводы.

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

Answer 2

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

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

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

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

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