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

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

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

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

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

С уважением,

JP

Ответы [ 2 ]

13 голосов
/ 26 декабря 2010

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

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

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

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

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

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

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

...