SSH bekerja di dempul tetapi tidak terminal

24

Ketika saya mencoba ssh ini di terminal: ssh username@sub.domain.comSaya mendapatkan kesalahan berikut:
Connection closed by 69.163.227.82

Ketika saya menggunakan dempul, saya dapat terhubung ke server. Mengapa ini terjadi, dan bagaimana saya bisa membuatnya bekerja di terminal?

ssh -v username@sub.domain.com

OpenSSH_6.0p1 (CentrifyDC build 5.1.0-472) (CentrifyDC build 5.1.0-472), OpenSSL 0.9.8w 23 Apr 2012
debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config
debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to sub.domain.com [69.163.227.82] port 22.
debug1: Connection established.
debug1: identity file /home/ryannaddy/.ssh/id_rsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_rsa-cert type -1
debug1: identity file /home/ryannaddy/.ssh/id_dsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_dsa-cert type -1
debug1: identity file /home/ryannaddy/.ssh/id_ecdsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug1: Miscellaneous failure
Cannot resolve network address for KDC in requested realm

debug1: Miscellaneous failure
Cannot resolve network address for KDC in requested realm

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Connection closed by 69.163.227.82
linux  ssh  terminal  putty 
— Lepaskan Rumput Saya
sumber
Apa yang ssh -v username@sub.domain.comditunjukkan?
— James Sneeringer
Saya memperbarui pertanyaan utama. Juga server harus meminta kata sandi, tidak ada kunci ssh yang diperlukan untuk masuk.
— Turun Lawn Saya
Apakah Anda mengubah pengaturan dari default di Putty?
— Kruug
Sudahkah Anda mencoba user@domain.com? Tinggalkan sub.
— Kruug
1
Anda menggunakan build OpenSSH dari Centrify, yang menyiratkan sistem Anda terintegrasi AD. Active Directory menggunakan Kerberos, dan OpenSSH mengeluh bahwa ia tidak dapat menemukan KDC Kerberos, jadi itu bailing out. Seperti apa /etc/krb5.confpenampilanmu?
— James Sneeringer

Jawaban:

23

Solusi ditemukan untuk saya melalui URL berikut: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

Bahkan melakukan pekerjaan yang cukup baik untuk menjelaskan apa yang sedang terjadi.

Pada akhirnya, saya menambahkan yang berikut ke / etc / ssh / ssh_config:

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160

Baik Ciphers, atau HostKeyAlgorithms bekerja sendiri, cukup yakin MAC menempatkan saya di atas untuk membuat ini bekerja, tapi saya tidak yakin, menghabiskan banyak waktu untuk menyelesaikan masalah ini. Saya harap ini setidaknya dapat membantu orang lain.

Sunting: Ini (kadang-kadang) memperbaiki masalah, tetapi mungkin tidak seperti yang Anda inginkan. --jcwenger

Pengaturan ini tampaknya (sebagai efek samping) mengubah cara klien ssh memancarkan paket, dan menyebabkannya memancarkan paket yang lebih kecil. Ini tidak memperbaiki masalah; itu hanya, kadang-kadang, membuatnya sehingga masalah nyata (fragmentasi MTU berinteraksi dengan implementasi aturan firewall bodoh) tidak terpicu.

Solusi yang benar adalah dengan mengatur MTU yang berfungsi ujung ke ujung.

Harus secara manual mengatur MTU ke angka yang lebih kecil untuk memastikan tidak ada fragmentasi terjadi tidak lebih bersih (kita sebagai pengguna tidak harus mengambil langkah-langkah secara manual untuk mengatasi masalah yang disebabkan oleh tim jaringan kami) ... tapi setidaknya secara langsung berurusan dengan penyebab sebenarnya dengan cara yang andal dan dapat dibuktikan, daripada mengacaukan pengaturan sandi SSH dengan cara yang, sebagai efek samping, ketika bintang-bintang sejajar, kebetulan menyebabkannya tidak membuat paket besar.

Juga, SSH bukan satu-satunya hal yang membuat paket besar. Pengaturan MTU menjaga hal yang sama tidak terjadi pada protokol lain juga.

— mattw
sumber
5
terima kasih, dalam kasus saya hanya baris terakhir MACs hmac-md5,hmac-sha1,hmac-ripemd160sudah cukup
— Tombart
Saya punya masalah dengan github - git pull / git push - tidak ada yang terjadi. Mencoba ssh -T -v git@github.com dan mendapatkan kesalahan yang sama. Gunakan ini untuk menyelesaikannya. Terima kasih!
— Jason
Saya memiliki masalah yang sama dan mencoba solusi ini. Satu efek samping adalah bahwa koneksi apa pun ke host yang dikenal kemudian akan menuduh perubahan kunci host.
— lfagundes
Semua tambalan ini mengobati gejala dan bukan penyebabnya. Mengurangi ukuran sandi memiliki potensi untuk mencegah fragmentasi MTU ... yang merupakan masalah sebenarnya, dibawa oleh @jagguli di bawah ini.
— jcwenger
Menambahkan baris "HostKeyAlgorithms ssh-rsa, ssh-dss" ke / etc / ssh / ssh_config memperbaiki masalah saya dengan tidak dapat SSH ke modem Zyxel. Semua baris lain di tetbox di atas sudah ada di mesin saya. Terima kasih atas tipnya!
— Jeff Wright
6

Ini memperbaiki masalah MTU tanpa harus meng-hardcode beberapa nilai, itu akan memperbaikinya untuk ssh dan protokol lain yang dipengaruhi oleh ini. Sebagai root jalankan yang berikut:

echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

Anda dapat membaca lebih lanjut tentang masalah dan solusinya di sini dan di sini .

— Marwan Alsabbagh
sumber
Penjelasan: "Ternyata sistem file kernel / proc menyediakan cara mudah untuk mengaktifkan dan menonaktifkan TCP MTU Probing dengan mengubah nilai dalam 'file' / proc / sys / net / ipv4 / tcp_mtu_probing. Nilai 0 = dinonaktifkan ; 1 = diaktifkan ketika router lubang hitam terdeteksi; 2 = selalu diaktifkan. "
— Jorj
1

Apakah beberapa orang mencari dan menemukan saran berikut di sini :

Coba pastikan baris berikut di / etc / ssh / ssh_config (BUKAN sshd_config) TIDAK dikomentari:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

Anda juga dapat mencoba mengembalikan file itu kembali ke default dan mencoba lagi, yaitu menghapus dan menginstal ulang openssh-clientIIRC nama paket.

— LawrenceC
sumber
Itu tidak memperbaikinya :(
— Get Off My Lawn
1

Saya bisa mengatasi masalah ini dengan memaksa menggunakan IPv4 dengan

ssh -4 username@host.xyz

Karena saya menggunakan Mac, saya tidak tahu apa pengaturan MTU di sini atau bagaimana mengubahnya, tetapi berpikir bahwa orang lain dapat mengambil manfaat dari ini.

— Bruno Kim
sumber
Opsi itu memaksa ssh untuk menggunakan IP4 saja. Saya di Mac juga dan TIDAK menyelesaikan masalah saya.
— Jorj
0

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
0

Sedikit necro di sini, tapi saya menemukan ini di OpenSSH_7.8p1, di Linux. Pengenalan penandaan DSCP dalam rilis OpenSSH baru-baru ini tampaknya tersandung di VMware NAT (Jaringan Bridged disebut baik-baik saja di tautan di bawah).

Anda dapat mengatasi ini untuk saat ini dengan menambahkan / mengatur yang berikut ke / etc / ssh / ssh_config :

IPQoS lowdelay throughput

Faktor-faktor tambahan adalah Putty (atau klien SSH lain yang berbeda) mungkin tidak menghadapi masalah dari host yang sama, dan MTU Anda sejauh ini memeriksanya. yaitu:

ping -M do -s 1472 your-ssh-server

Posting-posting ini sangat membantu dan membuat saya berada di tempat yang saya inginkan:

https://groups.google.com/forum/#!topic/opensshunixdev/5FK67SCpPg8 https://groups.google.com/forum/#!topic/opensshunixdev/uNd48nGOe7A

— Kachunkachunk
sumber
-2

ssh -c aes256-ctr berfungsi dengan baik;

— udara
sumber
Mengapa Anda percaya bahwa perintah ini akan menyelesaikan masalah?
— Scott
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.