Kesalahan SSH ssh_exchange_identification: baca: Koneksi diatur ulang oleh rekan

5

Saya mencoba mengakses ssh ke server tetapi mendapat " ssh_exchange_identification: baca: Koneksi diatur ulang oleh rekan ". Klien yang sama berfungsi dengan baik ketika saya memindahkan komputer ke rumah tetapi menunjukkan kesalahan ketika komputer di kantor bekerja. Apakah mungkin beberapa pengaturan jaringan LAN di jaringan kantor menyebabkan masalah? Saya mencoba komputer lain di jaringan kantor , masalah yang sama.

Bisakah saya mengubah pengaturan server untuk memperbaiki masalah ini?

Klien dan server dengan Debian yang sama "Linux debian 3.16.0-4-amd64 # 1 SMP Debian 3.16.7-2 (2014-11-06) x86_64 GNU / Linux"

Di sisi klien, log menunjukkan:

OpenSSH_6.7p1 Debian-3, OpenSSL 1.0.1j 15 Oct 2014
debug1: Reading configuration data /home/client/.ssh/config
debug1: /home/client/.ssh/config line 13: Applying options for navtk
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/client/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to www.host.com [xx.xx.xx.xx] port xx.
debug1: Connection established.
debug1: identity file /home/client/.ssh/user type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/user-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-3
ssh_exchange_identification: read: Connection reset by peer

Dan sisi login server

Server listening on :: port 443.
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 735
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
debug1: getpeername failed: Transport endpoint is not connected
debug1: get_remote_port failed

— Tmx
sumber

Server memutuskan untuk menjatuhkan koneksi segera setelah Anda terhubung. Ada beberapa alasan mengapa ini bisa terjadi. Anda harus memecahkan masalah ini di sisi server.

— Kenster

@Kenster. Terima kasih! Bagaimana saya bisa mendapatkan lebih banyak log dari sisi server? Dan jika di sisi server mengapa pengaturan yang sama berfungsi dengan baik untuk klien di rumah? Apakah pengaturan firewall router juga akan memengaruhi ini?

— Tmx

3

"Koneksi reset oleh rekan" berarti aliran TCP ditutup secara abnormal dari ujung lainnya. Saya pikir penjelasan yang paling mungkin adalah bahwa proses server jauh yang menangani koneksi mengalami gangguan, atau beberapa perangkat jaringan (seperti firewall stateful atau load balancer) telah memutuskan untuk mengganggu koneksi.

Anda perlu men-debug ini di server jauh jika Anda bisa. sshd log melalui syslog, dan pada sistem Unix yang khas, entri log akan berada di salah satu file di /var/log direktori. Jika kamu beruntung, sshd akan mencatat sesuatu setiap kali sesi Anda hilang

Jika Anda memiliki akses root di server, Anda dapat menjalankan instance debugging sshd. Menjadi root dan kemudian jalankan:

/path/to/sshd -ddd -p 1022

Ini akan menjalankan instance dari server SSH yang akan mendengarkan pada port 1022, menerima satu koneksi, dan mencetak informasi debug ke terminal Anda. Jalankan klien Anda seperti biasa, kecuali tentukan port 1022 sebagai port:

ssh -p 1022 user@host

Informasi debug yang dicetak oleh server diharapkan akan menjelaskan apa yang terjadi.

Sunting: Output server menunjukkan bahwa server tidak mogok atau sengaja menutup koneksi TCP. Sesuatu yang lain menyebabkannya tutup. Saya akan melihat perangkat lunak keamanan yang diinstal pada server yang dapat memonitor sesi TCP, serta firewall, load balancers, atau perangkat keras jaringan serupa yang mungkin menjadi bagian dari jaringan lokal.

— Kenster
sumber

Menggunakan port yang berbeda mungkin mengubah perilaku firewall.

— Daniel B

@ Kenster Silakan periksa pembaruan saya pada pertanyaan.

— Tmx

1

Saya memiliki masalah yang sama. Saat ini, sepertinya masalahnya ada pada ISP saya. Coba lakukan traceroute ke server Anda. Bagi saya, ini gagal sebelum mencapai server.

Server saya adalah server hosting bersama. Perusahaan hosting saya memberi tahu saya bahwa mereka memiliki masalah yang sama dengan klien lain menggunakan AT & amp; T atau Comcast.

Saya harap ini membantu, atau setidaknya menyelamatkan Anda dari menghabiskan waktu yang berlebihan untuk kemungkinan lain.

— Roger Creasy
sumber

0

Sudah terlambat di sini, tetapi mungkin seseorang yang terjun ke sini merasa terbantu.

Mulai ulang (hentikan & mulai) server.
Akses ke server oleh ssh lagi dengan ip publik. (Anda dapat melanjutkan ke langkah berikutnya jika itu berhasil.)
Mulai ulang server web.

Itu saja atau Anda mungkin perlu mengarahkan domain ke ip publik lagi.

Lingkungan saya adalah AWS dan NGINX.

— Pirun Seng
sumber

Apa hubungan server web dengan apa pun?

— Chloe

0

"ssh_exchange_identification: baca: Koneksi reset oleh rekan" juga akan terjadi ketika Anda berakhir di daftar blokir (mis. karena Anda memasukkan kata sandi yang salah terlalu sering). Terjadi pada saya dengan Synology-NAS saya. Jadi verifikasi bahwa IP dari mana Anda terhubung tidak ada dalam daftar itu.

Dalam hal synology, periksa di bawah "Control panel" / "Security" / "Account".

— kalmiya
sumber