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

Ако сликата се уште не е јасна, тестирајте од втор клиент на истиот тунел. Клиентот што ќе се поврзе ја преместува грешката од патеката во конфигурацијата на првата машина.