Второй вариант похож на первый и также основан на перехвате на этапе организации соединения, но этот случай подчеркивает важность безопасного распространения открытых ключей. Если для открытого ключа сервера не обеспечивается безопасное распространение, клиент не может удостовериться в том, что он соединился с нужным сервером. Атакующий может воспользоваться мошенническими методами (social engineering) для передачи ключей ничего не подозревающим пользователям и после этого поместить устройство перехвата на пути между клиентом и легитимным сервером. В этом случае клиент просто соединится с устройством атакующего, а атакующий организует соединение с легитимным сервером и сможет организовать мониторинг данных от клиента и сервера, а также манипулировать этими данными. Администраторам серверов рекомендуется делать «отпечатки» ключей доступными для проверки с помощью тех или иных средств, безопасность которых не влияет на целостность реальных ключей. Возможные механизмы обсуждались в параграфе 4.1 и могут также включать защищенные Web-страницы, передачу на бумажных носителях и т.п. Разработчикам следует обеспечивать рекомендации по эффективному использованию таких мер с их реализациями. Поскольку протокол является расширяемым, в будущих версиях могут обеспечиваться более эффективные методы распространения ключей серверов до организации первого соединения. Например, могут создаваться отпечатки ключей доступные через безопасные серверы DNS или использоваться Kerberos ([RFC4120]) через GSS-API ([RFC1964]) в процессе обмена ключами для аутентификации сервера.
В третьем варианте атакующий может попытаться манипулировать пакетами в процессе их передачи между партнерами после организации сеанса. Как описано в параграфе 9.3.3, вероятность успеха при таких атаках весьма мала. Как и для описанного в параграфе 9.3.3 случая причина низкой вероятности успеха при такой атаке обусловлена тем, алгоритм MAC является достаточно безопасным и нереально подобрать входные данные для алгоритма MAC, чтобы получить на выходе желаемый результат. Более детальное обсуждение этого вопроса приводится в разделе 6 [RFC2104]. Если алгоритм MAC имеет уязвимости или достаточно слаб, атакующий может оказаться способен задать те или иные данные на входе для получения известного значения MAC. Используя это, он сможет изменить передаваемые через сеть пакеты. Кроме того, атакующий может воспользоваться уязвимостью алгоритма или его слабостью для определения разделяемого ключа (shared secret) путем просмотра MAC в захваченных пакетах. В любом из этих случаев атакующий сможет создавать пакеты и помещать их в поток SSH. Для предотвращения этого разработчикам следует использовать общепринятые проверенные алгоритмы MAC, а администраторам следует читать современную литературу и дискуссии для того, чтобы вовремя узнавать о найденных в используемых алгоритмах MAC уязвимостях или недостатках.
В заключение отметим, что использование этого протокола без надлежащей проверки связи между хостами и их ключами, не обеспечивает должного уровня безопасности и не рекомендуется. Однако такое использование может оказаться необходимым для сред, где безопасность не играет критически важной роли и обеспечивается защита от пассивных атак. Разработчикам протоколов и использующих их приложений следует принимать этот факт во внимание.