SSH पोटीन में काम करता है, लेकिन टर्मिनल में नहीं

Question

जब मैं इसे टर्मिनल में भेजने की कोशिश करता ssh [e-mail]हूं : मुझे निम्न त्रुटि मिलती है:
Connection closed by 69.163.227.82

जब मैं पोटीन का उपयोग करता हूं, तो मैं सर्वर से कनेक्ट करने में सक्षम हूं। ऐसा क्यों हो रहा है, और मैं इसे टर्मिनल में काम करने के लिए कैसे प्राप्त कर सकता हूं?

ssh -v [e-mail]

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

Comments

क्या ssh -v [e-mail]दिखाता है?

— जेम्स स्नीनरिंग

मैंने मुख्य प्रश्न को अद्यतन किया। इसके अलावा सर्वर को पासवर्ड के लिए पूछना चाहिए, लॉगिन करने के लिए कोई ssh कीज़ नहीं हैं।

— मेरे लॉन

क्या आपने PuTTY में डिफ़ॉल्ट से कोई सेटिंग बदल दी है?

— क्रुग

इसके अलावा, क्या आपने कोशिश की है [e-mail]? बाहर छोड़ दो sub।

— क्रुग

आप OpenSSH के Centrify के निर्माण का उपयोग कर रहे हैं, जिसका अर्थ है कि आपका सिस्टम AD-एकीकृत है। सक्रिय निर्देशिका Kerberos का उपयोग करता है, और OpenSSH शिकायत कर रहा है कि यह Kerberos KDC नहीं ढूँढ सकता है, इसलिए यह बाहर चल रहा है। आपका /etc/krb5.confलुक कैसा लगता है?

— जेम्स स्नेनरिंग

Answer 1

निम्न 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

न तो सिफर, या HostKeyAl एल्गोरिदम ने अपने दम पर काम किया, बहुत यकीन है कि एमएसीएस ने मुझे यह काम करने के लिए शीर्ष पर रखा, लेकिन मुझे यकीन नहीं हो रहा है, इसे हल करने में कई घंटे लग सकते हैं। मुझे उम्मीद है कि यह कम से कम किसी और की मदद कर सकता है।

---

संपादित करें: यह (कभी-कभी) समस्या को ठीक करता है, लेकिन संभवत: उस तरीके से नहीं जैसा आप चाहते हैं। --jcwenger

ये सेटिंग एक साइड इफेक्ट के रूप में दिखाई देती हैं, जिस तरह से ssh क्लाइंट पैकेट्स को उत्सर्जित करता है, और ऐसा करने के लिए यह अन्य पैकेटों को उत्सर्जित करता है। यह समस्या को ठीक नहीं कर रहा है; यह सिर्फ, कभी-कभी, यह बनाता है ताकि वास्तविक समस्या (MTU विखंडन बेवकूफ फ़ायरवॉल नियम कार्यान्वयन के साथ बातचीत) ट्रिगर न हो।

सही समाधान एक MTU सेट करना है जो अंत तक काम करता है।

किसी भी विखंडन को सुनिश्चित करने के लिए MTU को छोटी संख्या में मैन्युअल रूप से सेट करने के बाद कोई क्लीनर नहीं है (हम उपयोगकर्ताओं को मैन्युअल रूप से हमारी नेटवर्क टीमों की वजह से समस्याओं का सामना करने के लिए कदम नहीं उठाने चाहिए) ... लेकिन यह कम से कम सीधे काम कर रहा है वास्तविक और विश्वसनीय तरीके से वास्तविक कारण, एसएसएच की सिफर सेटिंग्स को एक तरह से खराब करने के बजाय, एक साइड इफेक्ट के रूप में, जब तारों को संरेखित करता है, तो यह बड़े पैकेट नहीं बनाने के लिए होता है।

इसके अलावा, SSH केवल एक चीज नहीं है जो बड़े पैकेट बनाती है। एमटीयू की स्थापना अन्य प्रोटोकॉल के लिए भी यही बात रखती है।

Comments

धन्यवाद, मेरे मामले में बस आखिरी पंक्ति MACs hmac-md5,hmac-sha1,hmac-ripemd160पर्याप्त थी

— टॉमबार्ट

मुझे जीथब के साथ समस्या थी - गिट पुल / गिट पुश - कुछ भी नहीं हुआ। Ssh -T -v [e-mail] पर कोशिश की और वही त्रुटि मिली। इसे हल करने के लिए इसका इस्तेमाल किया। धन्यवाद!

— जेसन

मुझे इसी तरह की समस्या थी और इस समाधान की कोशिश की। एक साइड इफेक्ट यह है कि किसी ज्ञात होस्ट से कोई भी कनेक्शन तब होस्ट कुंजी परिवर्तन का आरोप लगाएगा।

— ffagundes

ये सभी पैच लक्षण का इलाज कर रहे हैं और इसका कारण नहीं है। साइफर के आकार को कम करने से एमटीयू के विखंडन को रोकने की क्षमता होती है ... जो कि वास्तविक समस्या है, जिसे नीचे @jagguli द्वारा लाया गया है।

— jcwenger

"HostKeyAl एल्गोरिदम ssh-rsa, ssh-dss" को / etc / ssh / ssh_config में जोड़कर SSH को Zyxel मॉडेम में सक्षम नहीं करने के साथ मेरा मुद्दा ठीक किया गया। उपरोक्त टेटबॉक्स की अन्य सभी लाइनें मेरी मशीन पर पहले से ही थीं। टिप के लिए धन्यवाद!

— जेफ राइट

Answer 2

यह मेरे लिए काम किया ...

ifconfig eth0 mtu 576

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

Answer 3

इस MTU के मुद्दे को कुछ मूल्य को हार्डकोड किए बिना तय किया, यह इसे ssh और इसके द्वारा प्रभावित किसी अन्य प्रोटोकॉल के लिए ठीक कर देगा। जैसे रूट निम्नलिखित चलाए:

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

आप यहां और यहां के मुद्दे और समाधान के बारे में अधिक पढ़ सकते हैं ।

Comments

स्पष्टीकरण: "यह पता चलता है कि कर्नेल / proc फ़ाइल सिस्टम 'फ़ाइल' / proc / sys / net / ipv4 / tcp_mtn_probing के मान को बदलकर TCP MTU प्रोबिंग को सक्षम और अक्षम करने का एक आसान तरीका प्रदान करता है। 0 = अक्षम का मान। ; 1 = सक्षम जब एक ब्लैक होल राउटर का पता चलता है; 2 = हमेशा सक्षम। "

— जोरज

Answer 4

क्या कुछ देखने और निम्नलिखित सुझाव यहां दिए गए हैं :

यह सुनिश्चित करने का प्रयास करें कि आपके / etc / ssh / ssh_config (NOT sshd_config) में निम्नलिखित पंक्ति नहीं है:

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

आप उस फ़ाइल को डिफ़ॉल्ट पर वापस लाने का प्रयास कर सकते हैं और पुनः प्रयास कर सकते हैं, अर्थात openssh-clientपैकेज के नाम पर IIRC को अनइंस्टॉल और पुनर्स्थापित कर सकते हैं ।

Comments

यह ठीक नहीं किया :(

— मेरे लॉन

Answer 5

इसे हल करने के लिए नेटवर्क इंटरफ़ेस MTU बदलें। यह ubuntu 14.04 के लिए एक बग है।

यह मेरे लिए काम किया:

sudo ip li set mtu 1200 dev wlan0

या:

sudo ifconfig wlan0 mtu 1200

ssh VPN होस्ट से कनेक्ट करने में विफल रहता है - 'SSH2_MSG_KEX_ECDH_PLPL' की अपेक्षा पर लटका हुआ है '

Answer 6

मैं IPv4 का उपयोग करने के लिए मजबूर करके इस मुद्दे को हल करने में सक्षम था

ssh -4 [e-mail]

चूंकि मैं एक मैक पर हूं, मुझे नहीं पता कि यहां एमटीयू सेटिंग्स क्या हैं या उन्हें कैसे बदलना है, लेकिन सोचा कि दूसरों को इससे फायदा हो सकता है।

Comments

यह विकल्प केवल IP4 का उपयोग करने के लिए ssh को बाध्य करता है। मैं मैक पर भी हूं और इसने मेरी समस्या का समाधान नहीं किया है।

— जोरज

Answer 7

मुझे यह समस्या आज शुरू हुई, विंडोज पर (जीआईटी के साथ वितरित ssh) और उबंटू।

यह ओपनएसएसएच पर एक बग प्रतीत होता है, लॉचपैड पर एक मुद्दा है ।

इसने विंडोज पर मेरे लिए 3des-cbc सिफर और उबंटू की कुंजी के लिए काम किया।

Answer 8

यहाँ एक छोटा सा नेक्रो, लेकिन मैंने इसका सामना लिनक्स पर OpenSSH_7.8p1 पर किया। ओपनएसएसएच की हालिया रिलीज में डीएससीपी अंकन की शुरूआत वीएमवेयर नेट (ट्रिपड नेटवर्किंग में नीचे दिए गए लिंक में ठीक होने का उल्लेख किया गया था) में तीन गुना हो रही है।

आप निम्नलिखित के लिए / 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 / uNd48nGO37A

Answer 9

ssh -c aes256-ctr ठीक काम करता है;

Comments

आप क्यों मानते हैं कि यह आदेश समस्या को हल करेगा?

— स्कॉट