Tidak dapat SSH: debug1: mengharapkan SSH2_MSG_KEX_DH_GEX_REPLY

24

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!

bakytn
sumber
Saya menghasilkan kunci BARU dan menyimpan pubkey baru .. hal yang sama! Ha!
bakytn
fyi, masalah Anda tidak ada hubungannya dengan otentikasi pubkey: pertukaran kunci DH ( SSH2_MSG_KEX_DH_GEX_REPLY) terjadi jauh lebih awal dalam koneksi.
grawity
terimakasih untuk informasinya. BTW GUYS, masalahnya sudah teratasi dengan sendirinya. Saya tidak melakukan apa-apa hanya mencoba masuk dan saya berhasil. hah
bakytn
Latensi jaringan buruk? banyak tetes? Pesannya biasa saja.
Korjavin Ivan
mungkin itu. Saya sekarang tidak dapat mereproduksi dengan cara apa pun. Jadi mungkin dari sisi saya.
bakytn

Jawaban:

28

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'

shgnInc
sumber
sudo ip li set mtu 1400 dev eno1bekerja untuk saya di Ubuntu 16.04.
Márcio
Terima kasih banyak. Saya sudah tidak dapat SSH atau remote desktop ke satu kotak tertentu selama berminggu-minggu. HTTP berfungsi dan mesin yang berdekatan bekerja dengan baik. Saya harus melompat dari mesin lain untuk masuk.
Duckbrain
12

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 [email protected] 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

neofutur
sumber
ini bisa terjadi terutama ketika Anda memiliki MTU kecil yang sangat tidak biasa di ujung klien, jika Anda ingin menggunakan openvpn pada jaringan double-nat.
Dennis Nolte
saya menggunakan nilai mtu standar sebelum mengalami masalah ini, menurunkan mtu adalah solusinya, bukan masalahnya. tolong jelaskan komentar Anda.
neofutur
9

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>
Lacek
sumber
Saya tahu itu tidak akan menjadi MTU. Jika seseorang mengacaukan MTU di sisi server, hal itu dapat memengaruhi throughput jaringan. Masalahnya harus ada beberapa perbedaan versi OpenSSH dan bagaimana mereka lebih suka kombinasi kode dan fungsi MAC tertentu.
Csaba Toth
7

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

rui
sumber
2

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.

LawfulHacker
sumber
2

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 [email protected]
SimonSC
sumber
-1

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

pengguna362323
sumber
-2

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

rfg
sumber
1
Apa yang tampak jelas? Pertanyaan ini dijawab (dengan jawaban yang diterima) lebih dari 4 tahun yang lalu.
David Makogon
-3

cmiiw

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

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

chocripple
sumber
The authorized_keysizin tidak ada hubungannya dengan kesalahan karena klien terjebak duing sebelumnya negitioation protokol. Memeriksa log sisi server mungkin membantu, tetapi baris ini lebih merupakan komentar - downvote.
coba-tangkap-akhirnya