SSH funziona nello stucco ma non nel terminale

24

Quando provo a ssh questo in un terminale: ssh username@sub.domain.comottengo il seguente errore:
Connection closed by 69.163.227.82

Quando uso putty, sono in grado di connettermi al server. Perché sta succedendo questo e come posso farlo funzionare in un terminale?

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 
— Vattene dal mio prato
fonte
Cosa ssh -v username@sub.domain.commostra?
— James Sneeringer,
Ho aggiornato la domanda principale. Inoltre il server dovrebbe richiedere una password, non ci sono chiavi SSH necessarie per accedere.
— Get Off My Lawn,
Hai modificato le impostazioni predefinite in PuTTY?
— Kruug
Inoltre, hai provato user@domain.com? Lascia fuori il sub.
— Kruug
1
Stai usando la build di OpenrifH di Centrify, il che implica che il tuo sistema è integrato AD. Active Directory utilizza Kerberos e OpenSSH si lamenta che non riesce a trovare il KDC Kerberos, quindi si sta salvando. Com'è il tuo /etc/krb5.confaspetto?
— James Sneeringer,

Risposte:

23

Soluzione trovata per me tramite il seguente URL: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

Fa anche un ottimo lavoro nel spiegare cosa sta succedendo.

Alla fine, ho aggiunto quanto segue a / 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

Né Cipher, né HostKeyAlgorithms hanno funzionato da soli, abbastanza sicuri che i MAC mi mettessero in testa per farlo funzionare, ma non posso esserne sicuro, ho impiegato molte ore per risolverlo. Spero che questo possa almeno aiutare qualcun altro.

Modifica: questo (a volte) risolve il problema, ma probabilmente non nel modo desiderato. --jcwenger

Queste impostazioni sembrano (come effetto collaterale) cambiare il modo in cui il client ssh emette i pacchetti e possono causare l'emissione di pacchetti più piccoli. Questo non sta risolvendo il problema; a volte lo rende tale da non innescare il vero problema (frammentazione MTU che interagisce con le stupide implementazioni delle regole del firewall).

La soluzione corretta è impostare un MTU che funzioni end-to-end.

Dover impostare manualmente MTU su un numero più piccolo per garantire che non si verifichi alcuna frammentazione non è più pulito (noi come utenti non dovremmo prendere misure manualmente per contrastare i problemi causati dai nostri team di rete) ... ma almeno sta affrontando direttamente la causa reale in un modo affidabile e dimostrabile, piuttosto che rovinare le impostazioni di cifratura di SSH in un modo che, come effetto collaterale, quando le stelle si allineano, sembra che non crei grandi pacchetti.

Inoltre, SSH non è l'unica cosa che crea pacchetti di grandi dimensioni. L'impostazione di MTU evita che la stessa cosa accada anche ad altri protocolli.

— mattw
fonte
5
grazie, nel mio caso MACs hmac-md5,hmac-sha1,hmac-ripemd160è bastata l'ultima riga
— Tombart,
Ho avuto un problema con github - git pull / git push - non è successo niente. Ho provato ssh -T -v git@github.com e ho ottenuto lo stesso errore. Usato per risolverlo. Grazie!
— Jason,
Ho avuto un problema simile e ho provato questa soluzione. Un effetto collaterale è che qualsiasi connessione a un host noto accuserebbe quindi una modifica della chiave host.
— lfagundes,
Tutti questi cerotti trattano il sintomo e non la causa. Ridurre la dimensione del codice ha il potenziale per prevenire la frammentazione dell'MTU ... che è il vero problema, sollevato da @jagguli di seguito.
— jcwenger,
L'aggiunta della riga "HostKeyAlgorithms ssh-rsa, ssh-dss" in / etc / ssh / ssh_config ha risolto il mio problema con l'impossibilità di SSH in un modem Zyxel. Tutte le altre righe nella casella tet sopra erano già presenti sulla mia macchina. Grazie per il suggerimento!
— Jeff Wright,
6

Ciò ha risolto il problema MTU senza dover codificare alcun valore, lo risolverà per ssh e qualsiasi altro protocollo effettuato da questo. Come root esegui quanto segue:

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

Puoi leggere di più sul problema e sulla soluzione qui e qui .

— Marwan Alsabbagh
fonte
Spiegazione: "Si scopre che il file system kernel / proc fornisce un modo semplice per abilitare e disabilitare il probing MTU TCP modificando un valore in 'file' / proc / sys / net / ipv4 / tcp_mtu_probing. Un valore di 0 = disabilitato ; 1 = abilitato quando viene rilevato un router black hole; 2 = sempre abilitato. "
— Jorj,
1

Qualcuno ha cercato e trovato il seguente suggerimento qui :

Prova ad assicurarti che la seguente riga nel tuo / etc / ssh / ssh_config (NOT sshd_config) NON sia commentata:

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

È inoltre possibile provare a ripristinare il file sul valore predefinito e riprovare, ovvero disinstallare e reinstallare openssh-clientIIRC il nome del pacchetto.

— LawrenceC
fonte
Non è stato risolto :(
— Get Off My Lawn
1

Sono stato in grado di risolvere questo problema forzando l'uso di IPv4 con

ssh -4 username@host.xyz

Dato che sono su un Mac non so quali siano le impostazioni MTU qui o come modificarle, ma ho pensato che altri potrebbero trarne beneficio.

— Bruno Kim
fonte
Questa opzione obbliga ssh a usare solo IP4. Anch'io sono su Mac e NON ha risolto il mio problema.
— Jorj,
0

Ho iniziato ad avere questo problema oggi, su Windows (ssh distribuito con Git) e Ubuntu.

Sembra essere un bug su OpenSSH, c'è un problema su LauchPad .

Ha funzionato per me su Windows forzando il codice 3des-cbc e la chiave su Ubuntu.

— LawfulHacker
fonte
0

Un po 'di necro qui, ma l'ho riscontrato su OpenSSH_7.8p1, su Linux. L'introduzione della marcatura DSCP nelle recenti versioni di OpenSSH sembra essere intervenuta in VMware NAT (la rete Bridged è stata citata per essere corretta nei collegamenti seguenti).

Per ora puoi aggirare questo problema aggiungendo / impostando quanto segue su / etc / ssh / ssh_config :

IPQoS lowdelay throughput

Ulteriori fattori potrebbero essere che PuTTY (o altri client SSH distinti) potrebbero non riscontrare il problema dallo stesso host e il tuo MTU finora ha verificato. vale a dire:

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

Questi post sono stati di particolare utilità e mi hanno portato dove dovevo essere:

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

— Kachunkachunk
fonte
-2

ssh -c aes256-ctr funziona bene;

— udara
fonte
Perché ritieni che questo comando risolverà il problema?
— Scott
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.