SSH macunla çalışıyor ancak terminalde çalışmıyor

Bunu bir terminalde ssh yapmaya çalıştığımda: ssh username@sub.domain.comAşağıdaki hatayı alıyorum:
Connection closed by 69.163.227.82

Macunu kullandığımda sunucuya bağlanabiliyorum. Bu neden oluyor ve bunun bir terminalde çalışmasını nasıl sağlayabilirim?

ssh -v kullaniciadi@etki.alani.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

Aşağıdaki URL aracılığıyla benim için çözüm bulundu: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

Neler olup bittiğini açıklamak oldukça iyi bir iş yapıyor.

Sonunda, / etc / ssh / ssh_config dosyasına şunu ekledim:

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

Ne Şifreler, ne de HostKeyAlgorithms kendi başlarına çalıştılar, eminim ki MAC'ler bunun işe yaraması için beni en üste çıkardı, ama emin olamıyorum, bu sorunu çözmek için uzun saatler harcadım. Umarım bu en azından başkasına yardım edebilir.

Düzenleme: Bu (bazen) sorunu düzeltir, ancak muhtemelen istediğiniz şekilde değildir. --jcwenger

Bu ayarlar (yan etki olarak) ssh istemcisinin paket yayınlama biçimini değiştiriyor ve daha küçük paketler yaymasına neden oluyor gibi görünüyor. Bu sorunu çözmüyor; sadece, bazen, gerçek sorunun (aptal güvenlik duvarı kuralı uygulamalarıyla etkileşime giren MTU parçalanması) tetiklenmemesini sağlar.

Doğru çözüm, uçtan uca çalışan bir MTU ayarlamaktır.

Parçalanmanın gerçekleşmemesini sağlamak için MTU'yu manuel olarak daha küçük bir sayıya ayarlamak zorunda olmak daha temiz değil (kullanıcıların ağ ekiplerimizin neden olduğu sorunları gidermek için manuel olarak adımlar atmamız gerekmiyor) ... ama en azından doğrudan Asıl sebep, SSH'nin şifre ayarlarını, yıldızların hizalanması durumunda yan paket olarak büyük paketler yapmamasına neden olacak şekilde vidalamak yerine, güvenilir ve kanıtlanabilir bir şekilde gerçekleştirmektir.

Ayrıca, büyük paketler yapan tek şey SSH değildir. MTU’yu ayarlamak da aynı şeyi diğer protokollere yapmaktan alıkoyuyor.

Bu benim için çalıştı ...

ifconfig eth0 mtu 576

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

Bu, MTU sorununu bir değeri sabitlemek zorunda kalmadan düzeltti, ssh ve bundan etkilenen diğer protokoller için düzeltecektir. Kök olarak aşağıdakileri çalıştırın:

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

Sorun ve çözüm hakkında burada ve burada daha fazla bilgi bulabilirsiniz .

Bazıları aradı ve aşağıdaki öneriyi burada buldu :

/ Etc / ssh / ssh_config (NOT sshd_config) içindeki şu satırın yorumlanmamasına dikkat edin:

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

Ayrıca, bu dosyayı varsayılana geri getirmeyi ve yeniden denemeyi deneyebilirsiniz, yani openssh-clientpaketin adını IIRC'yi kaldırıp yeniden yükleyin .

Çözmek için MTU ağ arayüzünü değiştirin. Bu, ubuntu 14.04 için bir hatadır.

Bu benim için çalıştı:

sudo ip li set mtu 1200 dev wlan0

Veya:

sudo ifconfig wlan0 mtu 1200

ssh VPN ana bilgisayarına bağlanamadı - 'SSH2_MSG_KEX_ECDH_REPLY bekliyor'

IPv4'ü kullanmaya zorlayarak bu sorunu çözdüm

ssh -4 username@host.xyz

Mac’te bulunduğumdan, buradaki MTU ayarlarının ne olduğunu veya bunların nasıl değiştirileceğini bilmiyorum, ancak başkalarının bundan yararlanabileceğini düşündüm.

Bugün bu sorunu Windows (Git ile birlikte dağıtılan ssh) ve Ubuntu'da yaşamaya başladım.

OpenSSH'de bir hata olduğu anlaşılıyor , LauchPad'de bir sorun var .

Benim için Windows'ta çalıştı, 3des-cbc şifresini ve Ubuntu'daki anahtarı zorladı.

Burada biraz necro var, ancak bununla OpenSSH_7.8p1, Linux'ta karşılaştım. OpenSSH'nin son sürümlerinde DSCP işaretinin tanıtılması VMware NAT'ta tetikliyor gibi görünüyor (Bridged networking'in aşağıdaki bağlantılarda iyi olduğu belirtildi).

Bu işlemi şimdilik / etc / ssh / ssh_config dizinine ekleyerek / ayarlayarak çalışabilirsiniz :

IPQoS lowdelay throughput

Ek faktörler, PuTTY'nin (veya diğer belirli SSH istemcilerinin) aynı ana bilgisayardan sorunla karşı karşıya kalmayacağı ve şu ana kadar MTU'nuzun kontrol edebileceği olabilir. yani:

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

Bu yazılar özellikle yardımcı oldu ve olmam gereken yere gitti:

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

ssh -c aes256-ctr düzgün çalışıyor;