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 ઘટાડતા પણ અટકાવે છે જે કદ વિશે ક્યારેય ન હતી.

જો ચિત્ર હજી અસ્પષ્ટ હોય, તો તે જ ટનલ પર બીજા ક્લાઇન્ટથી પરીક્ષણ કરો. જે ક્લાઇન્ટ જોડાય છે તે ખામીને પાથથી પ્રથમ મશીનની ગોઠવણી તરફ ખસેડે છે.