SSH hoạt động trong putty nhưng không phải thiết bị đầu cuối

Khi tôi cố gắng ssh cái này trong một thiết bị đầu cuối: ssh username@sub.domain.comTôi gặp lỗi sau:
Connection closed by 69.163.227.82

Khi tôi sử dụng putty, tôi có thể kết nối với máy chủ. Tại sao điều này xảy ra, và làm thế nào tôi có thể làm cho nó hoạt động trong một thiết bị đầu cuối?

ssh -v tên người dùng@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

Giải pháp được tìm thấy cho tôi qua URL sau: http://www.ained.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

Nó thậm chí còn làm một công việc khá tốt để giải thích những gì đang xảy ra.

Cuối cùng, tôi đã thêm vào sau / 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

Cả các thuật toán mã hóa hoặc HostKeyAlactic đều tự hoạt động, các MAC khá chắc chắn đã đưa tôi lên hàng đầu để làm việc này, nhưng tôi không chắc chắn, phải mất nhiều giờ để giải quyết vấn đề này. Tôi hy vọng điều này ít nhất có thể giúp đỡ người khác.

Chỉnh sửa: Điều này (đôi khi) khắc phục vấn đề, nhưng có lẽ không theo cách bạn muốn. --jcwenger

Các cài đặt này dường như (như một hiệu ứng phụ) thay đổi cách máy khách ssh phát ra các gói và xảy ra khiến nó phát ra các gói nhỏ hơn. Điều này không khắc phục được vấn đề; đôi khi, nó chỉ khiến vấn đề thực sự (phân mảnh MTU tương tác với việc triển khai quy tắc tường lửa ngu ngốc) không được kích hoạt.

Giải pháp đúng là đặt MTU hoạt động từ đầu đến cuối.

Phải tự thiết lập MTU cho một số nhỏ hơn để đảm bảo không có sự phân mảnh xảy ra không phải là bất kỳ sạch (chúng tôi như người dùng không cần phải tự tiến hành các bước để vấn đề truy cập gây ra bởi các nhóm mạng của chúng tôi) ... nhưng nó ít nhất trực tiếp đối phó với nguyên nhân thực sự theo một cách đáng tin cậy và có thể chứng minh được, thay vì làm hỏng các cài đặt mật mã của SSH theo cách mà như một hiệu ứng phụ, khi các ngôi sao căn chỉnh, sẽ khiến nó không tạo ra các gói lớn.

Ngoài ra, SSH không phải là thứ duy nhất tạo ra các gói lớn. Việc đặt MTU cũng giữ điều tương tự xảy ra với các giao thức khác.

Điều này làm việc cho tôi ...

ifconfig eth0 mtu 576

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

Điều này đã khắc phục sự cố MTU mà không phải mã hóa một số giá trị, nó sẽ sửa nó cho ssh và bất kỳ giao thức nào khác được thực hiện bởi điều này. Khi root chạy như sau:

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

Bạn có thể đọc thêm về vấn đề và giải pháp ở đây và đây .

Đã tìm kiếm và tìm thấy gợi ý sau đây :

Hãy thử đảm bảo dòng sau trong / etc / ssh / ssh_config (KHÔNG sshd_config) KHÔNG được nhận xét:

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

Bạn cũng có thể thử hoàn nguyên tệp đó về mặc định và thử lại, tức là gỡ cài đặt và cài đặt lại openssh-clientIIRC tên của gói.

Thay đổi giao diện mạng MTU để giải quyết nó. Đây là một lỗi cho Ubuntu 14.04.

Điều này làm việc cho tôi:

sudo ip li set mtu 1200 dev wlan0

Hoặc là:

sudo ifconfig wlan0 mtu 1200

ssh không kết nối được với máy chủ VPN - bị treo ở 'mong đợi SSH2_MSG_KEX_ECDH_REPLY'

Tôi đã có thể giải quyết vấn đề này bằng cách buộc sử dụng IPv4 với

ssh -4 username@host.xyz

Vì tôi đang sử dụng máy Mac, tôi không biết cài đặt MTU ở đây là gì hoặc cách thay đổi chúng, nhưng nghĩ rằng những người khác có thể được hưởng lợi từ việc này.

Tôi bắt đầu gặp vấn đề này ngày hôm nay, trên Windows (ssh được phân phối với Git) và Ubuntu.

Nó dường như là một lỗi trên OpenSSH, có một vấn đề trên LauchPad .

Nó hoạt động với tôi trên Windows khi buộc mật mã 3des-cbc và khóa trên Ubuntu.

Một chút của một hoại tử ở đây, nhưng tôi đã gặp điều này trên OpenSSH_7.8p1, trên Linux. Việc giới thiệu đánh dấu DSCP trong các bản phát hành OpenSSH gần đây dường như đang vấp ngã trong VMware NAT (Mạng được kết nối đã được đề cập là tốt trong các liên kết dưới đây).

Bây giờ bạn có thể giải quyết vấn đề này bằng cách thêm / cài đặt sau vào / etc / ssh / ssh_config :

IPQoS lowdelay throughput

Các yếu tố bổ sung sẽ là PuTTY (hoặc các máy khách SSH khác biệt) có thể không gặp phải sự cố từ cùng một máy chủ và cho đến nay MTU của bạn sẽ kiểm tra. I E:

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

Những bài đăng này rất hữu ích và đưa tôi đến nơi tôi cần:

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

ssh -c aes256-ctr hoạt động tốt;