Koneksi SSH: ssh_exchange_identifcation

9

Saya telah terhubung ke server jauh melalui Mac saya selama sekitar satu bulan sekarang. Sampai saat ini, saya mencoba terhubung menggunakan ssh dylan @ MY_IP dan mendapatkan pesan ini.

ssh_exchange_identification: read: Connection reset by peer

Saya juga mendapat beberapa informasi diagnostik ...

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 *
debug2: ssh_connect: needpriv 0
debug1: Connecting to {MY IP{ [MY IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/id_rsa type -1
debug1: identity file /Users/watson/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/watson/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /Users/watson/.ssh/id_dsa type 2
debug1: identity file /Users/watson/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2

Setelah melakukan riset, saya mencoba yang berikut ...

  1. Mulai ulang router saya
  2. Menghapus file "known_hosts" saya
  3. Menghapus file "known_hosts" saya
  4. Dirilis & Memperbarui DHCP saya
  5. Saya juga mencoba dari perangkat lain (Windows) menggunakan Putty dengan kesalahan juga

Perhatikan bahwa saya belum membuat perubahan apa pun pada server untuk menghambat komunikasi ini.

Juga, saya tidak yakin apakah ini akan menyebabkan masalah, tapi saya sudah terhubung dengan itu dengan nama domain dan juga IP-nya.

Selain itu, saya berhasil terhubung dari alamat IP lain.

Saya tahu ini adalah masalah besar dengan banyak sumber daya di luar sana, tetapi banyak solusi tidak bekerja atau saya benar-benar melihat jenis resolusi untuk siapa pun.

Memperbarui

Saya memaksanya untuk protokol 1. Alih-alih "Koneksi reset oleh rekan", saya sekarang mendapatkan "Koneksi ditutup oleh host jarak jauh". Menjalankannya dengan informasi debug terungkap:

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 *
debug2: ssh_connect: needpriv 0
debug1: Connecting to MY_IP [MY_IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/identity type -1
debug1: identity file /Users/watson/.ssh/identity-cert type -1
ssh_exchange_identification: Connection closed by remote host
Dylan
sumber
Apakah Anda menggunakan otentikasi kunci publik? Apakah Anda punya kunci /Users/watson/.ssh/id_dsa? Cobalah untuk membuat cadangan file dan menghapusnya.
pabouk
Saya tidak menggunakan otentikasi kunci publik; Namun, ada satu kunci dalam file. Saya mencoba menghapus file, tetapi tidak ada perubahan menjalankan perintah.
Dylan
jika ini merupakan masalah dengan versi protokol, Anda bisa memaksa untuk terhubung dengan protokol versi 1 denganssh -1 ...
wkaha
Lihat hasil edit baru pada posting.
Dylan

Jawaban:

4

Ini adalah bagaimana saya memecahkan kesalahan "ssh_exchange_identification: Connection closed by remote host" saat menghubungkan ke server SSH.

Saya mendapatkan kesalahan ini ketika mencoba terhubung ke mesin Linux yang tertanam, setelah membongkar paket ke root. Banyak file perpustakaan diganti, termasuk libssl.

Mencoba terhubung:

chetic@ubuntu:~$ ssh -v [email protected]
OpenSSH_6.2p2 Ubuntu-6ubuntu0.3, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to SC [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/delaval/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/delaval/.ssh/id_rsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_dsa type -1
debug1: identity file /home/delaval/.ssh/id_dsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.3
ssh_exchange_identification: read: Connection reset by peer

Googling sepertinya menyarankan memeriksa hosts.deny dan hosts.allow, tetapi mesin target saya tidak memiliki file seperti itu.

Setelah reboot (sesuai saran Karthik) sshd tidak berjalan. Saya mencoba secara manual memulai sshd sesuai target:

# sshd
OpenSSL version mismatch. Built against 1000002f, you have 1000105f

Saya mengganti /usr/lib/libssl.a dengan versi asli dan mulai sshd dan semuanya kembali normal. Masalahnya adalah dalam kasus saya yang disebabkan oleh versi yang salah dalam paket yang awalnya saya ekstrak ke root.

Chetic
sumber
3

Saya mendapatkan kesalahan yang sama (tetapi dari mesin mana pun, termasuk mesin yang merepotkan via ssh localhost).

Itu dimulai ketika saya memigrasikan profil pengguna; yaitu setelah menyalin file sebagai root, lalu melakukan perintah sukachown -R username /Users/username/Destop

Lagi pula, benar-benar tidak yakin mengapa / var / kosong pemilik diubah menjadi nama pengguna, tetapi sshpasti /var/emptyharus dimiliki oleh root (jika tidak Anda dapatkan ssh_exchange_identification: read: Connection reset by peer):

    sudo chown root /var/empty
hunter3740
sumber
Terima kasih! Mengubah pemilik /var/emptymemperbaiki masalah untuk saya.
Yevhen Pavliuk
1

Ini bukan masalah dengan mesin lokal Anda, tetapi masalah di sisi server. Mungkin ada beberapa faktor yang menyebabkan masalah ini:

  1. Perubahan pada konfigurasi /etc/hosts.allow atau /etc/hosts.deny di server jauh.
  2. Beban server berat.

Di masa lalu, ketika saya memiliki masalah ini, saya telah melakukan satu dari dua hal, dengan urutan sebagai berikut:

  1. Ubah /etc/hosts.allow seperti yang dirujuk dalam artikel di atas. (dan mulai ulang server SSH)
  2. Jika /etc/hosts.allow sudah seperti yang seharusnya, cukup restart server SSH (dan berhati-hatilah saat Anda melakukan ini!)
  3. Jika restart tidak berfungsi, buat ulang kunci server dan mulai ulang server SSH (ini berisiko, karena setiap pengguna yang masuk ke mesin ini akan mendapatkan kesalahan tentang server memiliki kunci yang diubah)

Lebih sering daripada tidak, saya memecahkan masalah, tetapi saya harus melakukan 2 dalam beberapa kasus .. Saya belum bisa mencari tahu mengapa itu terjadi, hanya saja sudah berhasil. Mungkin itu ada hubungannya dengan cara kunci disajikan, atau mungkin rusak dalam beberapa cara - saya tidak yakin. Tapi yang saya tahu adalah kesalahan itu sepenuhnya ada hubungannya dengan server, dan cara jabat tangan terjadi ketika koneksi SSH sedang diatur.

Karthik Rangarajan
sumber
1

Saya telah mengatur SSH dengan Cygwin dan dalam kasus saya itu adalah firewall Windows yang menyebabkan kesalahan ini, jadi pastikan untuk mengizinkan koneksi ke port 22.

anonim
sumber
0

Saya berhasil memecahkan masalah ini sendiri dengan sangat mudah.

Dalam OS X normal Anda dapat menyelesaikan ini dengan hanya mengaktifkan "Remote Login" di System Preferences / Sharing.

Namun, jika ini adalah server tanpa kepala (seperti dalam kasus saya), Anda dapat menggunakan aplikasi OSX Server untuk pergi ke (nama server Anda) / Pengaturan dan beralih "Amankan koneksi shell on dan off lagi"

Sirene
sumber
1
Saya mencatat juga bahwa bagaimana Anda dapat mengatasi masalah, tetapi tidak memperbaikinya: menonaktifkan remote login sangat mempengaruhi sistem, dan harus beralih remote login setiap kali seseorang ingin ssh ke beberapa tempat tertentu bukan solusi yang layak .
Ant6n
Ya ini masih merupakan masalah mengerikan yang saya miliki. Saya baru saja membuat skrip root cron yang memulai kembali layanan setiap tengah malam.
Sirene
0

Jika Anda menggunakan kunci pribadi atau kunci keamanan untuk masuk ke server Anda, maka Anda perlu mengubah izin untuk file kunci menjadi 660, menggunakan perintah

sudo chmod 660 File_Name

Srijan Chaudhary
sumber
1
(1) Meskipun ini bisa menjadi penyebab sshtidak berfungsi, tidak jelas bagaimana masalah ini akan menimbulkan sistem kerja secara acak. (2) Jawaban ini, seperti apa adanya, akan lebih bermanfaat jika Anda mengidentifikasi file yang sedang Anda bicarakan, atau memberikan instruksi untuk memungkinkan pengguna mengidentifikasinya. (3) Saya kira Anda sedang berbicara tentang file di (di bawah) direktori home pengguna. Jika itu masalahnya, sudoseharusnya tidak perlu.
Scott