SSH bị treo tại SSH2_MSG_KEX_ECDH_REPLY: không phải lúc nào cũng do MTU

Đường hầm đang hoạt động, banner đến và ứng dụng in thông báo đang chờ phản hồi trao đổi khóa. Kết quả tìm kiếm chỉ thẳng vào MTU, và đôi khi điều đó đúng. Thường thì không: phản hồi có thể chưa bao giờ được gửi, vì ứng dụng không đọc được tệp khóa hoặc hai đầu chưa bao giờ thống nhất thuật toán. Dòng này mô tả ứng dụng đang chờ gì, không phải vì sao việc chờ bắt đầu. Hãy coi đó là triệu chứng và tách ba nguyên nhân trước khi thay đổi bất kỳ kích thước nào.

Đọc dấu vết để xem có phản hồi nào được mong đợi hay không

Kết quả chi tiết cho thấy bước thành công cuối cùng trước sự im lặng. Nếu banner giao thức của máy chủ đã đến, TCP vẫn chạy và đầu xa vẫn sống; câu hỏi mở là điều gì đã xảy ra với một gói cụ thể. Một phút im lặng sau banner trông giống sự cố đường đi. Thông báo không có phương thức trao đổi khóa phù hợp là vấn đề chính sách. Chờ lâu kết thúc bằng việc máy chủ đóng phiên nghĩa là máy chủ đã bỏ cuộc, và nhật ký của nó giải thích vì sao.

Trong trường hợp cuối, hãy đọc nhật ký xác thực của máy chủ trước khi chạm vào ứng dụng. Ứng dụng không thể thấy quyết định mà máy chủ chưa bao giờ gửi.

Vì sao một phản hồi nhỏ vẫn có thể quá lớn

Phản hồi trao đổi khóa thường rất nhỏ, nên đổ lỗi cho kích thước nghe có vẻ sai. Với chứng chỉ máy chủ, phản hồi không nhỏ, vì nó mang chuỗi chứng chỉ của máy chủ. Điều đó khiến nó thành gói đầu tiên trong phiên có thể vượt tải trọng khả dụng của đường hầm. Khi phản hồi phát hiện MTU đường đi bị mất ở đâu đó trên tuyến, bên gửi tiếp tục gửi lại gói không vừa, và ứng dụng chờ mãi ở cùng dòng.

Xác định kích thước thay vì giả định. Đọc MTU của đường hầm bằng ip link show tun0, rồi gửi các phép thử không được phân mảnh: ping -4 -M do -s 1352 host, lặp lại với tải trọng nhỏ hơn. Thay đổi từ thất bại sang thành công ở một kích thước cụ thể là bằng chứng; thất bại đồng loạt gợi ý ICMP đang bị lọc và không cho bạn biết gì.

Giảm tạm thời xác nhận lý thuyết nhanh chóng, còn phiên bản lâu dài thuộc về hồ sơ hoặc thành giới hạn MSS trên bộ định tuyến chuyển tiếp đường hầm:

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

Hai nguyên nhân bắt chước sự cố kích thước

Tệp khóa mà ứng dụng không đọc được tạo ra cùng sự chờ đợi, không có cảnh báo ngay cả trong kết quả chi tiết. Một mẫu known_hosts làm điều này dễ dàng: mục @cert-authority trỏ tới khóa công khai CA mà chỉ một tài khoản đọc được. Tài khoản sở hữu tệp kết nối được, còn mọi tài khoản khác bị treo. Nếu lỗi đi theo người dùng chứ không phải máy chủ, hãy kiểm tra quyền tệp trước kích thước gói.

Bản nâng cấp cũng có thể loại bỏ thuật toán mà hai đầu từng chia sẻ. Ghim một phương thức mà máy chủ vẫn cung cấp để chẩn đoán: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Kết nối thành công ngay chứng minh đường đi tốt và việc sửa thuộc chính sách thương lượng ở cả hai phía.

Ba sự thật đáng ghi lại

Ghi lại MTU của đường hầm trước và sau mọi thay đổi, việc sao chép tệp lớn có thất bại ở kích thước lặp lại hay không, và máy chủ không có chứng chỉ trên cùng đường hầm có treo giống vậy hay không. Ba quan sát đó tách kích thước khỏi quyền và khỏi thương lượng nhanh hơn một chồng lệnh.

Chúng cũng ngăn người tiếp theo hạ MTU vì một lỗi chưa bao giờ liên quan đến kích thước.

Nếu bức tranh vẫn chưa rõ, hãy thử từ ứng dụng thứ hai trên cùng đường hầm. Ứng dụng kết nối được sẽ chuyển lỗi từ đường đi sang cấu hình của máy đầu tiên.