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

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

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

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

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

С уважением,

JP

10
man-in-the-middle openssh security ssh ssh-keys

2 ответов

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

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

2

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

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

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

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

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

13