ssh_exchange_identification: baca: Koneksi diatur ulang oleh rekan

106

Saya menggunakan OS X mencoba ssh ke server ubuntu 12.04. Saya bisa masuk SSH - sampai tiba-tiba barang berhenti bekerja. Saya sudah membaca online untuk menggunakan -vdebug ini. Output ditunjukkan di bawah ini. Jika saya ssh ke kotak yang berbeda dan kemudian ssh dari kotak itu ke server saya bisa masuk. Saya tidak tahu cara men-debug masalah ini tetapi ingin belajar.

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

Sejauh ini (atas saran dari papan pesan) saya telah mencari host deny file - tetapi tidak ada file seperti itu di komputer saya.

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

Saya memiliki akses admin di mesin klien tetapi tidak di server.

ssh

— bernie2436
sumber

Saya akan merekomendasikan memulai sshdmendengarkan pada port alternatif, dengan output verbose, dan memberikan output ketika mencoba terhubung. $(which sshd) -d -p 23. Jika Anda tidak memiliki kemampuan untuk melakukan ini, opsi Anda sangat terbatas. Taruhan terbaik adalah untuk mendapatkan seseorang yang memiliki hak admin di server.

— Patrick

Mungkinkah administrator di server membatasi akses Anda karena alasan tertentu? Bagaimanapun, saya dapat menghubungi orang itu.

— mdpc

12

File hosts.deny dan hosts.allow harus diperiksa di server , bukan pada klien. Juga, log sistem di server harus diperiksa. Jika Anda tidak memiliki akses ke keduanya, Anda mungkin ingin menghubungi admin server untuk melihatnya.

— ckujau

apakah Anda menemukan solusi untuk itu? apa masalahnya?

— MeV

2

Adalah daftar hosts.deny yang diisi oleh admin dengan skrip otomatis. Ketika saya lupa kata sandi saya pada beberapa titik, saya mengalami beberapa upaya gagal masuk, yaitu ketika IP saya dimasukkan pada daftar hosts.deny. Begitu banyak untuk produktivitas keamanan yang terlalu bersemangat.

— K.-Michael Aye

24

Perubahan mendadak bisa merupakan hasil dari perubahan file konfigurasi pada sshdkonfigurasi server , tetapi Anda mengindikasikan tidak dapat memeriksa atau mengubahnya tanpa admin yang benar. Anda masih dapat mencoba yang berikut jika admin server tidak dapat dijangkau (pada waktunya).

Log Anda hanya menunjukkan string versi lokal, Anda harus memeriksa versi yang sshdberjalan di server dan mesin perantara.

Jika versi ini berbeda (terutama antara mesin lokal dan server dan kurang antara mesin perantara dan server) mungkin ada beberapa ketidakcocokan negosiasi, ini telah terjadi sebelumnya di ssh. Solusi yang digunakan adalah mempersingkat entri Cipher, HostKeyAlgorithms dan / atau MAC, baik pada commandline ( ssh -c aes256-ctr, dll.) Atau di dalam Anda /etc/ssh/ssh_config.

Anda harus melihat informasi debug (dari menghubungkan melalui perantara ke server) untuk nilai-nilai yang sesuai sebagai argumen untuk resp baris perintah -c/ Ciphers, -o HostKeyAlgorithms/ HostKeyAlgorithmsdan -m/ MACs. perubahan ssh_config.

Saya belum memiliki masalah ini untuk sementara waktu, tetapi IIRC ketika saya melakukannya sudah cukup untuk secara manual memaksa pengaturan Ciphers dan HostKeyAlgorithms, setelah itu saya dapat memperbarui versi server sshddan masalahnya hilang.

— Anthon
sumber

3

Dalam kasus saya, sshdpaket server diperbarui ke versi yang lebih baru dan menghasilkan ketidakcocokan dengan sshkonfigurasi klien saya saat ini seperti yang Anda katakan. Membersihkan sshfile konfigurasi lama saya berhasil. Ini harus menjadi jawaban yang diterima.

— chakrit

2

@chakrit, bagaimana Anda membersihkan file konfigurasi ssh lama Anda?

— Jonathan

@ Jonathan Saya memasang disk pemulihan untuk melakukannya.

— chakrit

16

Anda mungkin telah dilarang oleh fail2banatau denyhosts. Dalam kasus seperti itu (dan juga untuk memeriksanya), jika Anda tidak ingin repot dengan bantuan penyedia server Anda, Anda perlu masuk ke server Anda dari alamat IP lain: misalnya server lain, atau koneksi rumah teman, atau wifi hot spot, atau menggunakan SSH dengan TOR.

Setelah masuk, periksa apakah alamat IP Anda memang muncul di /etc/hosts.deny(di sisi server). Jika demikian, maka fail2banatau denyhostspasti memang pelakunya.

Lihat jawaban atas pertanyaan ini untuk prosedur mencegah denyhostspemblokiran alamat Anda secara terus menerus. Untuk fail2banmenemukan ip Anda dengan iptables -L --line-numberdan membatalkan pencekalan ip iptables -D <chain> <chain number>Anda, Anda memeriksa rincian tentang howtoforge .

Anda mungkin ingin menambahkan alamat IP Anda fail2bandan denyhostsdaftar putih (masing-masing /etc/fail2ban/jail.conf, baris ignoreip, dan /var/lib/denyhosts/allowed-hosts, buat jika diperlukan (tetapi berhati-hatilah bahwa jalurnya mungkin berbeda pada distribusi Anda)) untuk mencegah masalah terjadi lagi.

— Skippy le Grand Gourou
sumber

9

Di server host, hapus ssh pub.key yang terletak di sini: ~/.ssh/authorized_keysuntuk mac Anda. Kemudian tail -f /var/log/auth.logketika Anda membuka terminal lain dan mencoba untuk ssh lagi ssh -v me@server. Jika Anda dimintai kata sandi maka ada masalah dengan kunci ssh Anda. Jika Anda masih melihat 'ssh_exchange_identification: baca: Sambungan direset oleh rekan', maka Anda harus dapat mengidentifikasi apa masalahnya dari entri log di file '/var/log/auth.log' setelah upaya Anda yang gagal untuk login.

Jika Anda masih gagal terhubung, posting entri yang dicatat dari file auth di sini dan saya akan merevisi jawaban saya.

— devnull
sumber

Tidak perlu menghapus kunci SSH dalam beberapa kasus. Langsung ke tail -f /var/log/auth.log dan periksa upaya terbaru.

— Jack Robson

6

Ini dapat terjadi jika Anda memiliki beberapa mesin di jaringan dengan alamat MAC yang sama (misalnya, jika Anda membuat salinan mesin virtual dan lupa mengubah MAC).

— elCapitano
sumber

4

Saya mendapatkan ini karena nameserver saya ISP di /etc/resolv.conf. Server nama ini sering kelebihan beban dan jika reverse DNS lookup gagal sshdakan menjatuhkan koneksi. Saya memecahkan masalah dengan menggunakan server nama yang lebih dapat diandalkan, misalnya 8.8.8.8.

— njahnke
sumber

4

Saya dihadapkan dengan masalah yang sama. Saya akan membuka sesi ssh dengan sukses, tetapi akan direset setelah beberapa waktu. Ketika saya mencoba menghubungkan gain segera saya akan mendapatkan kesalahan "Sambungan ditolak". ketika saya men-debug sesi saya mendapat pesan ini pada saat koneksi sedang direset

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1

Pada titik ini saya menyadari bahwa ada konflik alamat IP di jaringan. Saya berubah ke alamat lain dan masalah teratasi

— David
sumber

2

Downvotes, apa yang salah dengan jawabannya? Itu masih bisa menjadi kasus yang valid untuk memeriksa ketika turun daftar, mungkin saja bukan yang umum di antara yang lainnya.

— Pysis

@ Analisis: Jawaban yang benar dan tervotifikasi

— Daniel

3

Log Anda berarti sisi server menjatuhkan koneksi. Untuk mengetahui alasannya, Anda harus berkonsultasi dengan log sisi server, mereka harus menunjukkan alasan pemutusan. Anda harus selalu dapat menemukan log di / var / log / messages

Saya bisa menebaknya, ketika koneksi turun setelah klien mengirim nomor versi, server entah bagaimana mengancam klien sebagai tidak kompatibel.

— gena2x
sumber

3

Saya memiliki masalah yang sama tetapi ternyata penyebabnya berbeda: Saya menggunakan port yang salah.

Pada versi yang lebih baru dari sshkesalahan yang diberikan adalah Connection refusedatau Bad port.

Pada versi yang lebih lama kesalahan yang diberikan adalah ssh_exchange_identification: read: Connection reset by peer

Jadi, ketika Anda mendapatkan kesalahan seperti itu periksa apakah port sudah benar.

— Mugoma J. Okomba
sumber

1

Saya tahu pertanyaan ini sudah lama, tetapi saya ingin membagikan beberapa temuan yang saya miliki. Periksa apakah /var/empty/sshddi server memiliki kepemilikan dan izin yang sesuai.

Kami memiliki skrip koki yang dimodifikasi untuk memperbarui beberapa izin direktori, tetapi secara tidak sengaja memperbarui direktori di bawah target yang dimaksudkan, mengubah kepemilikan / var ke pengguna / grup aplikasi dan mengubah izin menjadi 775.

— Andrew Boerema
sumber

1

Karena belum disebutkan secara eksplisit dalam Jawaban, cara lain kesalahan ini dapat muncul adalah jika firewall berbasis jaringan antara Anda dan server telah memutuskan untuk memblokir koneksi. Firewall dapat memutuskan bahwa ada "terlalu banyak" koneksi dari IP sistem OS X, dan mulai memblokirnya. Belum ada koneksi "terlalu banyak" dari sistem lain, sehingga diizinkan.

Pesan terakhir yang Anda terima dari server adalah pesan yang muncul bahkan sebelum Anda memulai upaya otentikasi apa pun, yang mengesampingkan sejumlah besar kemungkinan seputar akun, kunci, atau kata sandi Anda.

Contoh dari kebijakan brute-force seperti itu dari sampling acak vendor adalah:

— Jeff Schaller
sumber