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 заради дефект, който никога не е бил за размер.

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