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 בגלל תקלה שמעולם לא הייתה קשורה לגודל.

אם התמונה עדיין לא ברורה, בדקו מלקוח שני באותה מנהרה. לקוח שמתחבר מעביר את התקלה מהנתיב להגדרה של המכונה הראשונה.