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!
sumber
SSH2_MSG_KEX_DH_GEX_REPLY
) terjadi jauh lebih awal dalam koneksi.Jawaban:
Ubah antarmuka jaringan MTU untuk menyelesaikannya. Ini adalah bug untuk ubuntu 14.04.
Ini bekerja untuk saya:
ATAU
ssh gagal terhubung ke host VPN - hang di 'mengharapkan SSH2_MSG_KEX_ECDH_REPLY'
sumber
sudo ip li set mtu 1400 dev eno1
bekerja untuk saya di Ubuntu 16.04.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:
(1400 harus cukup tetapi Anda dapat mencoba menggunakan nilai yang lebih rendah jika diperlukan)
solusi 2, tentukan cypher yang dipilih untuk koneksi ssh:
(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:
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:
tidak hanya
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.
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
sumber
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:
sumber
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
sumber
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.
sumber
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
sumber
kami menyelesaikannya dengan mengomentari baris Ciphers di / etc / ssh / ssh_config
sumber
Tampaknya jelas dialog opsi menyebabkan masalah, karena saya mengubah urutan Putty menegosiasikan pertukaran kunci dan masalah terpecahkan.
sumber
cmiiw
periksa izin Anda ~ / .ssh / Authorized_key, itu harus 600
periksa on / var / log / secure, / var / log / messages atau / var / log / auth
sumber
authorized_keys
izin 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.