SSH ค้างที่ SSH2_MSG_KEX_ECDH_REPLY: ไม่ใช่ MTU เสมอไป

อุโมงค์ทำงานอยู่ แบนเนอร์มาถึง และไคลเอนต์พิมพ์ข้อความว่า กำลังรอคำตอบของการแลกกุญแจ ผลการค้นหาชี้ตรงไปที่ MTU และบางครั้งก็ถูก แต่บ่อยครั้งไม่ใช่ คำตอบอาจไม่เคยถูกส่งเลย เพราะไคลเอนต์อ่านไฟล์กุญแจไม่ได้ หรือทั้งสองฝั่งไม่เคยตกลงอัลกอริทึมร่วมกัน บรรทัดนี้บอกว่าไคลเอนต์กำลังรออะไร ไม่ได้บอกว่าเหตุใดการรอจึงเริ่มต้น มองเป็นอาการ แล้วแยกสาเหตุทั้งสามออกจากกันก่อนจะเปลี่ยนขนาดใด ๆ

อ่าน trace เพื่อดูว่ามีการคาดหวังคำตอบหรือไม่

เอาต์พุตแบบละเอียดแสดงขั้นตอนสุดท้ายที่สำเร็จก่อนจะเงียบ ถ้าแบนเนอร์โปรโตคอลของเซิร์ฟเวอร์มาถึง TCP ทำงานและปลายทางยังมีชีวิต คำถามที่ยังเปิดอยู่คือเกิดอะไรขึ้นกับแพ็กเก็ตหนึ่ง ๆ ความเงียบหนึ่งนาทีหลังแบนเนอร์ดูเหมือนปัญหาของเส้นทาง ข้อความว่าไม่มีวิธีแลกกุญแจที่ตรงกันเป็นปัญหานโยบาย การรอเป็นเวลานานแล้วจบลงด้วยเซิร์ฟเวอร์ปิดเซสชันหมายความว่าเซิร์ฟเวอร์ยอมแพ้ และบันทึกของเซิร์ฟเวอร์อธิบายเหตุผล

ในกรณีหลัง อ่านบันทึกการยืนยันตัวตนของเซิร์ฟเวอร์ก่อนจะแตะไคลเอนต์ ไคลเอนต์มองไม่เห็นการตัดสินใจที่เซิร์ฟเวอร์ไม่เคยส่งมา

ทำไมคำตอบเล็ก ๆ จึงยังอาจใหญ่เกินไป

คำตอบของการแลกกุญแจมักเล็กมาก การโทษขนาดจึงฟังดูผิด แต่เมื่อใช้ใบรับรองโฮสต์ คำตอบไม่เล็ก เพราะมีห่วงโซ่ใบรับรองของเซิร์ฟเวอร์ติดมาด้วย จึงกลายเป็นแพ็กเก็ตแรกในเซสชันที่อาจเกินเพย์โหลดที่ใช้ได้ของอุโมงค์ เมื่อผลป้อนกลับของการค้นหา MTU ของเส้นทางหายไปที่ใดที่หนึ่งบนเส้นทาง ผู้ส่งจะส่งแพ็กเก็ตที่ใส่ไม่ลงซ้ำแล้วซ้ำอีก และไคลเอนต์จะรอตลอดไปที่บรรทัดเดิม

กำหนดขนาดแทนการสันนิษฐาน อ่าน MTU ของอุโมงค์ด้วย ip link show tun0 แล้วส่งโพรบที่ไม่ควรถูกแบ่งส่วน: ping -4 -M do -s 1352 host ทำซ้ำด้วยเพย์โหลดที่เล็กลง การเปลี่ยนจากล้มเหลวเป็นสำเร็จที่ขนาดหนึ่ง ๆ คือหลักฐาน ความล้มเหลวสม่ำเสมอแสดงว่า ICMP ถูกกรอง และไม่ได้บอกอะไรเลย

การลดชั่วคราวยืนยันทฤษฎีได้เร็ว ส่วนเวอร์ชันถาวรควรอยู่ในโปรไฟล์หรือเป็น MSS clamp บนเราเตอร์ที่ส่งต่ออุโมงค์:

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 เพราะข้อบกพร่องที่ไม่เคยเกี่ยวกับขนาด

ถ้าภาพยังไม่ชัด ให้ทดสอบจากไคลเอนต์ที่สองบนอุโมงค์เดียวกัน ไคลเอนต์ที่เชื่อมต่อได้จะย้ายข้อบกพร่องจากเส้นทางไปที่การตั้งค่าของเครื่องแรก