SSH działa w kitach, ale nie na terminalach

Kiedy próbuję ssh to w terminalu: pojawia ssh username@sub.domain.comsię następujący błąd:
Connection closed by 69.163.227.82

Kiedy używam kitu, mogę połączyć się z serwerem. Dlaczego tak się dzieje i jak mogę to uruchomić w terminalu?

ssh -v nazwa użytkownika@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

Rozwiązanie znaleziono dla mnie pod następującym adresem URL: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

Wyjaśnia nawet, co się dzieje.

Ostatecznie dodałem do / 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

Ani Szyfry, ani HostKeyAlgorytmy nie działały same, całkiem pewne, że MAC postawił mnie na czele, żeby to zadziałało, ale nie jestem pewien, włożę wiele godzin w rozwiązanie tego problemu. Mam nadzieję, że to może przynajmniej pomóc komuś innemu.

Edycja: To (czasami) rozwiązuje problem, ale prawdopodobnie nie w sposób, w jaki chcesz. --jcwenger

Te ustawienia wydają się (jako efekt uboczny) zmienić sposób, w jaki klient ssh emituje pakiety i powoduje, że emituje mniejsze pakiety. To nie rozwiązuje problemu; czasami po prostu sprawia, że ​​prawdziwy problem (fragmentacja MTU współdziałająca z głupimi implementacjami reguł zapory ogniowej) nie jest wyzwalana.

Prawidłowym rozwiązaniem jest ustawienie jednostki MTU, która działa od początku do końca.

Konieczność ręcznego ustawienia MTU na mniejszą liczbę w celu zapewnienia braku fragmentacji nie jest wcale czystsza (my jako użytkownicy nie powinniśmy ręcznie podejmować kroków w celu przeciwdziałania problemom powodowanym przez nasze zespoły sieciowe) ... ale to przynajmniej bezpośrednio rzeczywista przyczyna w niezawodny i dający się udowodnić sposób, zamiast popsuć ustawienia szyfru SSH w taki sposób, że efektem ubocznym, gdy gwiazdy się wyrównają, jest to przyczyną, że nie tworzy dużych pakietów.

Ponadto SSH nie jest jedyną rzeczą, która tworzy duże pakiety. Ustawienie MTU powstrzymuje to samo od innych protokołów.

To działało dla mnie ...

ifconfig eth0 mtu 576

http://fred-web.blogspot.com.au/2012/10/ssh-hang-on-expecting.html

To rozwiązało problem MTU bez konieczności kodowania pewnej wartości, naprawi to dla ssh i dowolnego innego protokołu przez to wywołanego. Jako root uruchom następujące czynności:

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

Możesz przeczytać więcej na temat problemu i rozwiązania tutaj i tutaj .

Czy ktoś szukał i znalazł tutaj następującą sugestię :

Spróbuj upewnić się, że następujący wiersz w / etc / ssh / ssh_config (NOT sshd_config) NIE jest skomentowany:

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

Możesz także spróbować przywrócić domyślny plik i spróbować ponownie, tj. Odinstaluj i ponownie zainstaluj openssh-clientIIRC nazwę pakietu.

Zmień MTU interfejsu sieciowego, aby go rozwiązać. To jest błąd dla Ubuntu 14.04.

To działało dla mnie:

sudo ip li set mtu 1200 dev wlan0

Lub:

sudo ifconfig wlan0 mtu 1200

ssh nie łączy się z hostem VPN - zawiesza się na „oczekując SSH2_MSG_KEX_ECDH_REPLY”

Udało mi się rozwiązać ten problem, zmuszając do korzystania z IPv4

ssh -4 username@host.xyz

Ponieważ jestem na komputerze Mac, nie wiem, jakie są tutaj ustawienia MTU i jak je zmienić, ale pomyślałem, że inni mogą z tego skorzystać.

Zacząłem mieć ten problem dzisiaj w systemie Windows (ssh dystrybuowany z Git) i Ubuntu.

Wygląda na to, że jest to błąd w OpenSSH, jest problem w LauchPad .

Działa dla mnie w systemie Windows, wymuszając szyfr 3des-cbc i klucz w Ubuntu.

Trochę nekro tutaj, ale natknąłem się na to na OpenSSH_7.8p1, na Linuksie. Wydaje się, że wprowadzenie oznaczenia DSCP w ostatnich wydaniach OpenSSH potknęło się w VMware NAT (w poniższych linkach wspominano, że w sieci mostkowej jest w porządku).

Możesz na razie obejść ten problem, dodając / ustawiając następujące opcje w / etc / ssh / ssh_config :

IPQoS lowdelay throughput

Dodatkowymi czynnikami mogą być to, że PuTTY (lub inni klienci SSH) mogą nie napotykać problemu z tego samego hosta, a Twój MTU jak dotąd się sprawdza. to znaczy:

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

Te posty były szczególnie pomocne i doprowadziły mnie tam, gdzie powinienem być:

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

ssh -c aes256-ctr działa dobrze;