SSH2_MSG_KEX_ECDH_REPLY వద్ద SSH ఆగిపోతుంది: ఎల్లప్పుడూ MTU కాదు

టన్నెల్ నడుస్తోంది, బ్యానర్ వస్తుంది, మరియు క్లయింట్ కీ మార్పిడి ప్రత్యుత్తరం కోసం వేచి ఉన్నట్లు సందేశాన్ని ముద్రిస్తుంది. శోధన ఫలితాలు నేరుగా MTU వైపు సూచిస్తాయి, కొన్నిసార్లు అది సరైనది. చాలాసార్లు కాదు: క్లయింట్ కీ ఫైల్ను చదవలేకపోవడం లేదా రెండు చివరలు అల్గోరిథంపై అంగీకరించకపోవడం వల్ల ప్రత్యుత్తరం ఎప్పుడూ పంపబడకపోవచ్చు. ఆ వరుస క్లయింట్ ఏమి కోసం వేచి ఉందో వివరిస్తుంది, వేచి ఉండటం ఎందుకు ప్రారంభమైందో కాదు. దాన్ని లక్షణంగా పరిగణించి ఏ పరిమాణాన్ని మార్చే ముందు మూడు కారణాలను వేరు చేయండి.

ప్రత్యుత్తరం నిజంగా ఆశించబడిందో లేదో చూడటానికి ట్రేస్ చదవండి

వివరణాత్మక ఉత్పత్తి నిశ్శబ్దానికి ముందు చివరి విజయవంతమైన దశను చూపిస్తుంది. సర్వర్ ప్రోటోకాల్ బ్యానర్ వచ్చి ఉంటే, TCP పని చేస్తోంది మరియు దూరపు చివర సజీవంగా ఉంది; తెరిచిన ప్రశ్న ఒక నిర్దిష్ట ప్యాకెట్కు ఏమి జరిగింది అనేది. బ్యానర్ తర్వాత ఒక నిమిషం నిశ్శబ్దం మార్గ సమస్యలా కనిపిస్తుంది. సరిపోలే కీ మార్పిడి పద్ధతి లేదు అనే సందేశం విధాన సమస్య. సర్వర్ సెషన్ను మూసివేయడంతో దీర్ఘ వేచి ఉండటం ముగిస్తే సర్వర్ వదిలేసిందని అర్థం, మరియు దాని లాగ్ కారణాన్ని వివరిస్తుంది.

చివరి సందర్భంలో, క్లయింట్ను తాకే ముందు సర్వర్ ప్రామాణీకరణ లాగ్ను చదవండి. సర్వర్ ఎప్పుడూ పంపని నిర్ణయాన్ని క్లయింట్ చూడలేదు.

చిన్న ప్రత్యుత్తరం ఇప్పటికీ చాలా పెద్దగా ఎందుకు ఉండగలదు

కీ మార్పిడి ప్రత్యుత్తరాలు సాధారణంగా చాలా చిన్నవి, కాబట్టి పరిమాణాన్ని నిందించడం తప్పుగా అనిపిస్తుంది. హోస్ట్ సర్టిఫికెట్లతో ప్రత్యుత్తరం చిన్నది కాదు, ఎందుకంటే అది సర్వర్ సర్టిఫికెట్ గొలుసును మోస్తుంది. ఇది సెషన్లో టన్నెల్ ఉపయోగించగల పేలోడ్ను మించగల మొదటి ప్యాకెట్గా మారుస్తుంది. మార్గ MTU ఆవిష్కరణ అభిప్రాయం మార్గంలో ఎక్కడో పోతే, పంపేవాడు సరిపోని ప్యాకెట్ను మళ్లీ మళ్లీ పంపుతూనే ఉంటాడు, క్లయింట్ అదే వరుసలో శాశ్వతంగా వేచి ఉంటుంది.

పరిమాణాన్ని ఊహించకుండా నిర్ణయించండి. ip link show tun0 తో టన్నెల్ MTUని చదవండి, తర్వాత విభజించబడకూడని ప్రోబ్లను పంపండి: 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లోని ఒక నమూనా దీన్ని సులభం చేస్తుంది: ఒక ఖాతా మాత్రమే చదవగల CA పబ్లిక్ కీని సూచించే @cert-authority నమోదు. ఫైల్ను కలిగి ఉన్న ఖాతా కనెక్ట్ అవుతుంది, మిగతా ప్రతి ఖాతా ఆగిపోతుంది. వైఫల్యం హోస్ట్ను కాకుండా వినియోగదారుని అనుసరిస్తే, ప్యాకెట్ పరిమాణాలకు ముందు ఫైల్ మోడ్లను తనిఖీ చేయండి.

అప్గ్రేడ్ రెండు చివరలు మునుపు పంచుకున్న అల్గోరిథంను కూడా తీసివేయవచ్చు. సర్వర్ ఇప్పటికీ అందించే ఒక పద్ధతిని నిర్ధారణగా పిన్ చేయండి: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. వెంటనే విజయవంతమయ్యే కనెక్షన్ మార్గం సరిగ్గా ఉందని నిరూపిస్తుంది, సరిదిద్దడం రెండు వైపుల చర్చా విధానంలో ఉంది.

రాయదగిన మూడు వాస్తవాలు

ఏదైనా మార్పుకు ముందు మరియు తర్వాత టన్నెల్ MTU, పెద్ద ఫైల్ కాపీ పునరావృత పరిమాణంలో విఫలమవుతుందా, అదే టన్నెల్లో సర్టిఫికెట్ లేని హోస్ట్ కూడా అదే విధంగా ఆగిపోతుందా అని నమోదు చేయండి. ఆ మూడు పరిశీలనలు పరిమాణాన్ని అనుమతులు మరియు చర్చల నుండి ఆదేశాల కుప్ప కంటే వేగంగా వేరు చేస్తాయి.

ఎప్పుడూ పరిమాణానికి సంబంధం లేని లోపం కోసం తర్వాతి వ్యక్తి MTU తగ్గించడాన్ని కూడా అవి నిరోధిస్తాయి.

చిత్రం ఇంకా స్పష్టంగా లేకపోతే, అదే టన్నెల్లో రెండవ క్లయింట్ నుండి పరీక్షించండి. కనెక్ట్ అయ్యే క్లయింట్ లోపాన్ని మార్గం నుండి మొదటి మెషీన్ కాన్ఫిగరేషన్కు తరలిస్తుంది.