Tidak dapat SSH: debug1: mengharapkan SSH2_MSG_KEX_DH_GEX_REPLY

Kami memiliki server XXX DI Amazon EC2.

SSH berjalan pada port standar (22).

Saya menempatkan pubkey saya di file /.ssh/authorized_keys

Yang menyenangkan adalah bahwa kemarin itu bekerja dengan baik!

Tetapi hari ini, saya tidak tahu apa yang terjadi! Saya tidak bisa masuk.

ssh -vvvv servername

macet

debug1: mengharapkan SSH2_MSG_KEX_DH_GEX_REPLY

Saya memeriksa pubkey saya dan itu ada di sana! (bagaimana saya memeriksa ?? Saya meminta orang lain untuk memeriksa)

dan kemudian saya menggunakan komputer lain (windows 7 + dempul) dan menempatkan pubkey baru saya. Dan apa? Saya bisa masuk! Dan itu komputer lain dengan Win7 ont LAN yang sama yang menas bahwa IP eksternal sama.

Kunci pribadi saya berfungsi untuk server lain tetapi tidak dengan ini.

Tolong bantu!

Ubah antarmuka jaringan MTU untuk menyelesaikannya. Ini adalah bug untuk ubuntu 14.04.

Ini bekerja untuk saya:

sudo ip li set mtu 1200 dev wlan0

ATAU

sudo ifconfig wlan0 mtu 1200

ssh gagal terhubung ke host VPN - hang di 'mengharapkan SSH2_MSG_KEX_ECDH_REPLY'

Masalah yang sama persis di sini untuk mengakses server khusus di pusat data online.net.

Tidak ada masalah setelah reboot, tidak perlu mengubah MTU, koneksi ssh bekerja selama 1-3 minggu, kemudian muncul bug yang sama persis ini, memblokir KEXINIT, tidak ada lagi kemungkinan untuk menghubungkan server ssh.

Ini bisa jadi semacam sshd bug, tetapi dipicu oleh beberapa hal nework yang terjadi setelah 1-3 minggu, saya mereproduksi masalah yang sama ini berkali-kali dengan banyak server berbeda di jaringan ini, ada yang mengatakan itu mungkin terkait dengan bug cisco, mungkin terkait dengan beberapa opsi DPI.

Masalah itu tidak pernah terjadi dengan server lain yang saya kelola di pusat data lain, dan yang memiliki versi distro, config dan sshd yang sama persis.

jika Anda tidak ingin melakukan reboot setiap 10 hari karena firewall datacenter (atau tweak jaringan lainnya) melakukan hal-hal aneh:

pertama terhubung dengan salah satu dari solusi sisi klien:

solusi 1, menurunkan MTU sisi klien lokal Anda:

ip li set mtu 1400 dev wlan0

(1400 harus cukup tetapi Anda dapat mencoba menggunakan nilai yang lebih rendah jika diperlukan)

solusi 2, tentukan cypher yang dipilih untuk koneksi ssh:

ssh -c aes256-gcm@openssh.com host

(atau coba dengan kode sandi lain yang tersedia)

Kedua solusi sisi klien itu membuatnya untuk saya, saya bisa terhubung dan menghemat waktu kerja saya; tetapi Anda ingin memperbaiki sisi server ini, selamanya, jadi Anda tidak perlu meminta setiap klien untuk mengubah MTU mereka secara lokal.

Pada gentoo saya baru saja menambahkan:

mtu_eth0="1400"

di /etc/conf.d/net

(opsi MTU yang sama harus tersedia di suatu tempat di file konfigurasi jaringan distro pilihan Anda)

Saya telah mengatur mtu ke 1400, tetapi 1460 mungkin cukup dalam banyak kasus.

solusi lain yang membantu adalah dengan menggunakan aturan iptables berikut untuk mengelola fragmentasi:

# / 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

(Tapi saya pribadi tidak membutuhkan yang satu ini sampai sekarang)

juga perhatikan bahwa gejala dari masalah ini juga bisa:

debug1: SSH2_MSG_KEXINIT sent

tidak hanya

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

sunting maret 2016:

• menurunkan mtu ke 1400 di server paling selalu berfungsi, tetapi saya baru-baru ini memiliki kasus di mana mtu sudah diturunkan ke 1400 di server dan masalah muncul kembali, dan klien juga harus menurunkan mtu ke 1400.

• Masalahnya juga muncul pada formulir masuk web menunggu halaman untuk memuat ulang sampai mengatakan "server telah me-reset koneksi", juga diperbaiki setelah klien mengatur mtU ke 1400.

  tautan yang berhubungan :

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085

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

https://nowhere.dk/articles/natty-narwhal-problems-connecting-to-servers-behind-cisco-firewalls-using-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

Dalam kasus saya, saya tidak memiliki izin untuk menurunkan ukuran MTU. Dan secara manual menentukan Cipher tidak bekerja.

Saya dapat terhubung setelah memperpendek daftar MAC dengan menentukan satu, misalnya:

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

Saya memiliki masalah yang sama setelah saya meningkatkan mesin klien Ubuntu saya. Saya memecahkan masalah saya dengan mengurangi ukuran baris "Ciphers" di / etc / ssh / ssh_config. Ini juga berfungsi jika Anda menentukan cypher di baris perintah (mis: ssh -c username @ hostname)

Kiat dari sini:

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493/comments/39

Saya mulai mengalami masalah ini hari ini, di Windows (ssh didistribusikan dengan Git) dan Ubuntu.

Tampaknya ada bug di OpenSSH, ada masalah di LauchPad .

Ini bekerja untuk saya di Windows yang memaksa cipher 3des-cbc dan kunci di Ubuntu.

Mengubah Algoritma Kex bekerja untuk saya, dan mungkin menjadi opsi di mana Anda tidak memiliki hak sistem untuk mengubah pengaturan MTU. Ini mungkin juga satu untuk ditangani oleh kru OpenSSH. misalnya

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

kami menyelesaikannya dengan mengomentari baris Ciphers di / etc / ssh / ssh_config

Tampaknya jelas dialog opsi menyebabkan masalah, karena saya mengubah urutan Putty menegosiasikan pertukaran kunci dan masalah terpecahkan.

cmiiw

• periksa izin Anda ~ / .ssh / Authorized_key, itu harus 600

• periksa on / var / log / secure, / var / log / messages atau / var / log / auth