SSH зависает на SSH2_MSG_KEX_ECDH_REPLY: дело не всегда в MTU

Туннель поднят, баннер приходит, и клиент печатает сообщение об ожидании ответа обмена ключами. Результаты поиска указывают прямо на MTU, и иногда это верно. Часто нет: ответ мог вообще не отправляться, потому что клиент не смог прочитать файл ключа или стороны так и не договорились об алгоритме. Строка описывает, чего ждёт клиент, а не почему началось ожидание. Считайте это симптомом и разделите три причины, прежде чем менять любой размер.

Прочитайте трассировку, чтобы увидеть, ожидался ли ответ вообще

Подробный вывод показывает последний успешный шаг перед тишиной. Если баннер протокола сервера пришёл, TCP работает и удалённая сторона жива; открытый вопрос — что случилось с одним конкретным пакетом. Минута тишины после баннера выглядит как проблема пути. Сообщение об отсутствии подходящего метода обмена ключами — это проблема политики. Долгое ожидание, заканчивающееся закрытием сеанса сервером, означает, что сервер сдался, и его журнал объясняет почему.

В последнем случае прочитайте журнал аутентификации сервера, прежде чем трогать клиент. Клиент не может видеть решение, которое сервер никогда не отправлял.

Почему маленький ответ всё равно может быть слишком большим

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

Определите размер, а не предполагайте. Прочитайте MTU туннеля с помощью ip link show tun0, затем отправьте пробы, которые не должны фрагментироваться: ping -4 -M do -s 1352 host, повторяя с меньшими нагрузками. Переход от неудачи к успеху при определённом размере — это доказательство; равномерная неудача говорит о том, что ICMP фильтруется, и ничего вам не сообщает.

Временное снижение быстро подтверждает теорию, а постоянный вариант место имеет в профиле или как ограничение MSS на маршрутизаторе, который передаёт туннель:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Две причины, имитирующие проблему размера

Файл ключа, который клиент не может прочитать, даёт то же ожидание, без предупреждения даже в подробном выводе. Один шаблон known_hosts делает это простым: запись @cert-authority, указывающая на открытый ключ CA, который может прочитать только одна учётная запись. Учётная запись — владелец файла — подключается, а все остальные зависают. Если сбой следует за пользователем, а не за хостом, проверьте режимы файла раньше размеров пакетов.

Обновление также может удалить алгоритм, который обе стороны раньше использовали. Закрепите один метод, который сервер ещё предлагает, как диагностику: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Соединение, которое сразу удаётся, доказывает, что путь в порядке, и исправление относится к политике согласования с обеих сторон.

Три факта, которые стоит записать

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

Они также мешают следующему человеку снизить MTU из-за неисправности, которая никогда не была связана с размером.

Если картина всё ещё неясна, проверьте со второго клиента в том же туннеле. Клиент, который подключается, переносит неисправность с пути на конфигурацию первой машины.