SSH ทำงานได้ในแบบฉาบ แต่ไม่ใช่เทอร์มินัล

เมื่อฉันพยายาม ssh นี้ใน terminal: ssh username@sub.domain.comฉันได้รับข้อผิดพลาดต่อไปนี้:
Connection closed by 69.163.227.82

เมื่อฉันใช้ putty ฉันสามารถเชื่อมต่อกับเซิร์ฟเวอร์ ทำไมสิ่งนี้จึงเกิดขึ้นและฉันจะทำให้มันทำงานในอาคารผู้โดยสารได้อย่างไร?

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

พบวิธีแก้ปัญหาสำหรับฉันผ่าน URL ต่อไปนี้: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

มันเป็นงานที่ค่อนข้างดีในการอธิบายสิ่งที่เกิดขึ้น

ในที่สุดฉันเพิ่มต่อไปนี้ใน / 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

Ciphers หรือ HostKeyAlgorithms ทำงานด้วยตัวเองค่อนข้างแน่ใจว่า MACs ทำให้ฉันอยู่ด้านบนสุดเพื่อให้เรื่องนี้ทำงานได้ แต่ฉันไม่แน่ใจวางเวลาหลายชั่วโมงเพื่อแก้ไขปัญหานี้ ฉันหวังว่าอย่างน้อยสามารถช่วยคนอื่นได้

แก้ไข: สิ่งนี้ (บางครั้ง) แก้ไขปัญหา แต่อาจไม่ได้ตามที่คุณต้องการ --jcwenger

การตั้งค่าเหล่านี้ดูเหมือนจะ (เป็นผลข้างเคียง) เปลี่ยนวิธีที่ไคลเอ็นต์ ssh ส่งแพ็กเก็ตและเกิดขึ้นเพื่อปล่อยแพ็คเก็ตขนาดเล็ก สิ่งนี้ไม่ได้แก้ไขปัญหา เป็นเพียงบางครั้งทำให้เป็นปัญหาจริง (การกระจายตัวของ MTU การโต้ตอบกับการใช้กฎไฟร์วอลล์โง่) ไม่ได้ถูกเรียก

วิธีแก้ไขที่ถูกต้องคือตั้งค่า MTU ที่ใช้งานได้ตั้งแต่ต้นจนจบ

การตั้งค่า MTU ด้วยตนเองเป็นจำนวนที่น้อยลงเพื่อให้แน่ใจว่าไม่มีการแตกแฟรกเมนต์ไม่ได้เป็นเรื่องสะอาด (เราเป็นผู้ใช้ไม่ควรทำตามขั้นตอนเพื่อแก้ไขปัญหาที่เกิดจากทีมเครือข่ายของเรา) ... แต่อย่างน้อยก็จัดการโดยตรง สาเหตุที่แท้จริงในวิธีที่เชื่อถือได้และพิสูจน์ได้แทนที่จะตั้งค่าตัวเลขของ SSH ในลักษณะที่เป็นผลข้างเคียงเมื่อดวงดาวเรียงกันเกิดขึ้นเพื่อไม่ให้ห่อใหญ่

นอกจากนี้ SSH ไม่ใช่สิ่งเดียวที่ทำให้เป็นแพ็คเก็ตขนาดใหญ่ การตั้งค่า MTU ทำให้สิ่งเดียวกันไม่เกิดขึ้นกับโปรโตคอลอื่นด้วย

สิ่งนี้ใช้ได้กับฉัน ...

ifconfig eth0 mtu 576

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

สิ่งนี้แก้ไขปัญหา MTU โดยไม่ต้อง hardcode ค่าบางอย่างมันจะแก้ไขสำหรับ ssh และโปรโตคอลอื่น ๆ ที่ได้รับผลกระทบจากสิ่งนี้ ในฐานะที่เป็นรากรันต่อไปนี้:

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

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับปัญหาและวิธีการแก้ปัญหาที่นี่และที่นี่

มีบางคนมองและพบข้อเสนอแนะต่อไปนี้ที่นี่ :

ลองตรวจสอบให้แน่ใจว่าบรรทัดต่อไปนี้ใน / etc / ssh / ssh_config (ไม่ใช่ sshd_config) ของคุณไม่ได้ถูกใส่ความคิดเห็น:

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

คุณอาจลองคืนค่าไฟล์นั้นกลับไปเป็นค่าเริ่มต้นและลองอีกครั้งเช่นถอนการติดตั้งและติดตั้งopenssh-clientIIRC ชื่อแพ็คเกจใหม่

เปลี่ยนเน็ตเวิร์กอินเตอร์เฟส MTU เพื่อแก้ปัญหา นี่เป็นข้อผิดพลาดสำหรับ Ubuntu 14.04

สิ่งนี้ใช้ได้กับฉัน:

sudo ip li set mtu 1200 dev wlan0

หรือ:

sudo ifconfig wlan0 mtu 1200

ssh ล้มเหลวในการเชื่อมต่อกับโฮสต์ VPN - ค้างที่ 'คาดว่า SSH2_MSG_KEX_ECDH_REPLY'

ฉันสามารถแก้ไขปัญหานี้ได้โดยบังคับให้ใช้ IPv4 ด้วย

ssh -4 username@host.xyz

เนื่องจากฉันใช้ Mac ฉันไม่รู้ว่าการตั้งค่า MTU คืออะไรหรือจะเปลี่ยนได้อย่างไร แต่คิดว่าคนอื่นอาจได้ประโยชน์จากสิ่งนี้

ฉันเริ่มมีปัญหานี้วันนี้บน Windows (ssh กระจายกับ Git) และ Ubuntu

แต่ดูเหมือนว่ามันจะเป็นปัญหาที่เกี่ยวกับ OpenSSH มีปัญหาในLauchPad

มันใช้งานได้สำหรับฉันบน Windows ที่บังคับให้เข้ารหัส 3des-cbc และกุญแจบน Ubuntu

necro เล็กน้อยที่นี่ แต่ฉันพบสิ่งนี้ใน OpenSSH_7.8p1 บน Linux การแนะนำของการทำเครื่องหมาย DSCP ใน OpenSSH รุ่นล่าสุดดูเหมือนจะเพิ่มขึ้นใน VMware NAT (ระบบเครือข่ายบริดจ์ได้รับการกล่าวถึงว่าใช้ได้ในลิงค์ด้านล่าง)

คุณสามารถหลีกเลี่ยงปัญหานี้ได้โดยการเพิ่ม / ตั้งค่าต่อไปนี้เป็น/ etc / ssh / ssh_config :

IPQoS lowdelay throughput

ปัจจัยเพิ่มเติมอาจเป็นไปได้ว่า PuTTY (หรือลูกค้า SSH ที่แตกต่างอื่น ๆ ) อาจไม่พบปัญหาจากโฮสต์เดียวกันและ MTU ของคุณตรวจสอบแล้ว เช่น:

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

โพสต์เหล่านี้มีประโยชน์โดยเฉพาะและพาฉันไปที่ที่ฉันต้องการ:

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

ssh -c aes256-ctr ทำงานได้ดี;