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 због квара који никада није био везан за величину.

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