Không thể SSH: debug1: mong đợi SSH2_MSG_KEX_DH_GEX_REPLY

Chúng tôi có một máy chủ XXX TRÊN Amazon EC2.

SSH đang chạy trên một cổng tiêu chuẩn (22).

Tôi đã đặt pubkey của mình tại tệp /.ssh/authorized_keys

Điều thú vị là NGÀY NAY nó đã hoạt động rất tốt!

Nhưng hôm nay, tôi không biết chuyện gì đã xảy ra! Tôi chỉ không thể đăng nhập.

tên máy chủ ssh -vvvv

bị mắc kẹt trên

debug1: mong đợi SSH2_MSG_KEX_DH_GEX_REPLY

Tôi đã kiểm tra pubkey của tôi và nó ở đó! (làm thế nào tôi kiểm tra ?? Tôi yêu cầu người khác kiểm tra)

và sau đó tôi đã sử dụng một máy tính khác (windows 7 + putty) và đặt pubkey mới của tôi. Vậy thì sao? Tôi đã có thể đăng nhập! Và đó là một máy tính khác có Win7 không phải là mạng LAN mà IP bên ngoài giống nhau.

Khóa riêng của tôi hoạt động cho các máy chủ khác nhưng không phải với điều này.

Hãy giúp tôi!

Thay đổi giao diện mạng MTU để giải quyết nó. Đây là một lỗi cho Ubuntu 14.04.

Điều này làm việc cho tôi:

sudo ip li set mtu 1200 dev wlan0

HOẶC LÀ

sudo ifconfig wlan0 mtu 1200

ssh không kết nối được với máy chủ VPN - bị treo ở 'mong đợi SSH2_MSG_KEX_ECDH_REPLY'

Vấn đề chính xác tương tự ở đây để truy cập một máy chủ chuyên dụng tại trung tâm dữ liệu online.net.

Không có vấn đề gì sau khi khởi động lại, không cần thay đổi MTU, kết nối ssh hoạt động trong 1-3 tuần, sau đó xuất hiện lỗi chính xác này, chặn trên KEXINIT, không thể kết nối máy chủ ssh nữa.

Nó có thể là một loại lỗi sshd, nhưng nó nhất thiết phải được kích hoạt bởi một số nội dung mới xảy ra sau 1-3 tuần, tôi đã tái tạo vấn đề chính xác này nhiều lần với nhiều máy chủ khác nhau trên mạng này, một số người cho rằng nó có thể liên quan đến lỗi cisco, có thể liên quan đến một số tùy chọn DPI.

Vấn đề đó không bao giờ xảy ra với các máy chủ khác mà tôi quản lý trong các trung tâm dữ liệu khác và có cùng phiên bản distro, config và sshd.

nếu bạn không muốn khởi động lại cứ sau 10 ngày vì tường lửa trung tâm dữ liệu (hoặc các chỉnh sửa mạng khác) đang làm những việc kỳ lạ:

đầu tiên kết nối với một trong những cách giải quyết phía khách hàng:

cách giải quyết 1, hạ MTU cục bộ, phía máy khách của bạn:

ip li set mtu 1400 dev wlan0

(1400 là đủ nhưng bạn có thể thử sử dụng các giá trị thấp hơn nếu cần)

cách giải quyết 2, chỉ định cypher đã chọn cho kết nối ssh:

ssh -c aes256-gcm@openssh.com host

(hoặc thử với bất kỳ cypher có sẵn nào khác)

Cả hai cách giải quyết phía khách hàng đó đã giúp tôi, tôi có thể kết nối và tiết kiệm thời gian hoạt động của mình; nhưng bạn muốn sửa lỗi phía máy chủ này mãi mãi, vì vậy bạn không phải yêu cầu mọi khách hàng điều chỉnh MTU cục bộ của họ.

Trên gentoo tôi chỉ cần thêm:

mtu_eth0="1400"

trong /etc/conf.d/net

(tùy chọn mtu tương tự sẽ có sẵn ở đâu đó trong tệp cấu hình mạng phân phối ưa thích của bạn)

Tôi đã đặt mtu thành 1400, nhưng 1460 có lẽ là đủ trong hầu hết các trường hợp.

một cách giải quyết khác có thể là sử dụng các quy tắc iptables sau để quản lý phân mảnh:

# / sbin / iptables -I OUTPUT -p tcp --tcp-flags SYN, RST SYN -j TCPMSS --clamp-mss-to-pmtu

# / sbin / ip6tables -I OUTPUT -p tcp --tcp-flags SYN, RST SYN -j TCPMSS --clamp-mss-to-pmtu

(nhưng tôi không cần cái này cho đến bây giờ)

cũng lưu ý rằng các triệu chứng của vấn đề này cũng có thể là:

debug1: SSH2_MSG_KEXINIT sent

không chỉ là

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

chỉnh sửa tháng 3 năm 2016:

• Việc hạ mtu xuống 1400 trên máy chủ luôn hoạt động, nhưng gần đây tôi đã gặp trường hợp mtu đã bị hạ xuống 1400 trên máy chủ và vấn đề xuất hiện trở lại, và khách hàng cũng phải hạ mtu xuống 1400.

• Sự cố cũng xuất hiện trên các biểu mẫu đăng nhập web đang chờ trang tải lại cho đến khi thông báo "máy chủ đã đặt lại kết nối", cũng được khắc phục sau khi máy khách đặt mtU thành 1400.

  Liên kết liên quan :

https://bugs.launchpad.net/ubfox/+source/openssh/+orms/1254085

http://www.ained.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

https://nowhere.dk/articles/natty-narwhal-probols-connecting-to-servers-behind-cisco-firewalls-USE-ssh

/programming/2419412/ssh-connection-stop-at-debug1-ssh2-msg-kexinit-sent

http://www.1-script.com/forums/ssh/ssh-hang-after-ssh2-msg-kexinit-sent-10616-.htm

http://www.snailbook.com/faq/mtu-mismatch.auto.html

Trong trường hợp của tôi, tôi không được phép hạ kích thước MTU. Và chỉ định thủ công Mật mã không hoạt động.

Tôi có thể kết nối sau khi rút ngắn danh sách MAC bằng cách chỉ định một danh sách, ví dụ:

ssh -o MACs=hmac-sha2-256 <HOST>

Tôi gặp vấn đề tương tự sau khi tôi nâng cấp máy khách Ubuntu của mình. Tôi đã giải quyết vấn đề của mình bằng cách giảm kích thước của dòng "Mật mã" trong / etc / ssh / ssh_config. Nó cũng hoạt động nếu bạn chỉ định cypher trong dòng lệnh (ví dụ: ssh -c username @ hostname)

Mẹo từ đây:

https://bugs.launchpad.net/ubfox/+source/openssh/+orms/708493/comments/39

Tôi bắt đầu gặp vấn đề này ngày hôm nay, trên Windows (ssh được phân phối với Git) và Ubuntu.

Nó dường như là một lỗi trên OpenSSH, có một vấn đề trên LauchPad .

Nó hoạt động với tôi trên Windows khi buộc mật mã 3des-cbc và khóa trên Ubuntu.

Việc thay đổi Thuật toán Kex đã phù hợp với tôi và có thể là một tùy chọn trong đó bạn không có quyền hệ thống để thay đổi cài đặt MTU. Đây cũng có thể là một để nhóm OpenSSH giải quyết. ví dụ

ssh -o KexAlgorithms=ecdh-sha2-nistp521 fu@bar.com

chúng tôi đã giải quyết nó nhận xét dòng Ciphers trên / etc / ssh / ssh_config

Dường như rõ ràng hộp thoại tùy chọn gây ra một vấn đề, bởi vì tôi đã thay đổi thứ tự mà Putty đàm phán trao đổi khóa và vấn đề được giải quyết.

cmiiw

• kiểm tra quyền ~ / .ssh / ủy quyền của bạn, nó phải là 600

• kiểm tra bật / var / log / safe, / var / log / message hoặc / var / log / auth