এসএসএইচ পুতিনে কাজ করে তবে টার্মিনাল নয়


24

আমি যখন টার্মিনালে এটি ছড়িয়ে দেওয়ার চেষ্টা করি: ssh username@sub.domain.comআমি নিম্নলিখিত ত্রুটিটি পেয়েছি:
Connection closed by 69.163.227.82

আমি যখন পুটি ব্যবহার করি তখন আমি সার্ভারে সংযোগ করতে সক্ষম হয়েছি। কেন এটি হচ্ছে, এবং আমি কীভাবে এটি টার্মিনালে কাজ করতে পারি?

ssh -v ব্যবহারকারীর নাম@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

কি ssh -v username@sub.domain.comদেখায়?
জেমস স্নেরিংগার

আমি মূল প্রশ্নটি আপডেট করেছি। এছাড়াও সার্ভারের একটি পাসওয়ার্ড জিজ্ঞাসা করা উচিত, লগইন করার জন্য কোনও ssh কী প্রয়োজন নেই।
আমার লন

আপনি পুটিতে ডিফল্ট থেকে কোনও সেটিংস পরিবর্তন করেছেন?
ক্রুগ

এছাড়াও, আপনি চেষ্টা করেছেন user@domain.com? ছেড়ে দিন sub
ক্রুগ

1
আপনি ওপেনএসএসএইচ-এর সেন্ট্রিফাই বিল্ড ব্যবহার করছেন, যা বোঝায় যে আপনার সিস্টেমটি AD- সংহত। অ্যাক্টিভ ডিরেক্টরিটি কার্বেরোস ব্যবহার করে এবং ওপেনএসএসএইচ অভিযোগ করছে যে এটি কার্বেরোস কেডিসিকে খুঁজে পাচ্ছে না, সুতরাং এটি জামিনযোগ্য। তোমার /etc/krb5.confচেহারা কেমন?
জেমস স্নেরিঞ্জার

উত্তর:


23

নিম্নলিখিত URL টির মাধ্যমে আমার জন্য সমাধানটি খুঁজে পেয়েছে: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connication-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

সাইফার বা হোস্টকিএলগোরিদম কেউই নিজেরাই কাজ করেনি, বেশ নিশ্চিত যে ম্যাকরা আমাকে এটিকে কাজ করার জন্য শীর্ষে ফেলেছে, তবে আমি নিশ্চিত হতে পারি না, সমাধান করার জন্য বেশ কয়েক ঘন্টা রেখে দিন। আমি আশা করি এটি কমপক্ষে অন্য কাউকে সহায়তা করতে পারে।


সম্পাদনা করুন: এটি (কখনও কখনও) সমস্যার সমাধান করে তবে সম্ভবত আপনি যেভাবে চান তেমন নয়। --jcwenger

এই সেটিংগুলি (পার্শ্ব প্রতিক্রিয়া হিসাবে) এসএস ক্লায়েন্টের প্যাকেটগুলি নির্গত করার পদ্ধতিতে পরিবর্তন ঘটে এবং এর ফলে ছোট প্যাকেট নির্গত হয় happen এটি সমস্যার সমাধান করছে না; এটি ঠিক কখনও কখনও এটি তৈরি করে যাতে আসল সমস্যা (বোকা ফায়ারওয়াল বিধি প্রয়োগের সাথে মিথস্ক্রিয়তার এমটিইউ খণ্ডিত) ট্রিগার না হয়।

সঠিক সমাধানটি এমন একটি এমটিইউ সেট করা যা শেষ প্রান্তে কাজ করে।

কোনও বিভাজন না ঘটে তা নিশ্চিত করার জন্য ম্যানুয়ালি এমটিইউকে অল্প সংখ্যায় সেট করা কোনও ক্লিনার নয় (ব্যবহারকারী হিসাবে আমাদের নেটওয়ার্ক দলগুলির কারণে সৃষ্ট সমস্যাগুলি মোকাবিলার জন্য ম্যানুয়ালি পদক্ষেপ নিতে হবে না) ... তবে এটি কমপক্ষে সরাসরি ডিল করছে এসএসএইচ-এর সিফার সেটিংসকে এমনভাবে স্ক্র্যাভ করার পরিবর্তে নির্ভরযোগ্য এবং প্রবণতাজনক উপায়ে প্রকৃত কারণটি, পার্শ্ব প্রতিক্রিয়া হিসাবে, যখন তারাগুলি সারিবদ্ধ হয়, তখন এটি বড় প্যাকেট তৈরি না করার কারণ হয়।

এছাড়াও, এসএসএইচ এমন একমাত্র জিনিস নয় যা বড় প্যাকেট তৈরি করে। এমটিইউ সেট করা একই বিষয়টিকে অন্য প্রোটোকলগুলিতেও ঘটতে বাধা দেয়।


5
ধন্যবাদ, আমার ক্ষেত্রে কেবল শেষ লাইনটি MACs hmac-md5,hmac-sha1,hmac-ripemd160যথেষ্ট ছিল
টমবার্ট

গিথুব - গিট টান / গিট পুশ - এ আমার কিছুই হয়নি। Ssh -T -v git@github.com চেষ্টা করেও একই ত্রুটি পেয়েছি। এটি সমাধানের জন্য এটি ব্যবহার করুন। ধন্যবাদ!
জেসন

আমারও অনুরূপ সমস্যা হয়েছিল এবং এই সমাধানটি চেষ্টা করেছিলাম। এর একটি পার্শ্ব প্রতিক্রিয়া হ'ল পরিচিত হোস্টের যে কোনও সংযোগের পরে হোস্ট কী পরিবর্তনকে দোষ দেওয়া হবে।
lfagundes

এই সমস্ত প্যাচগুলি লক্ষণটির চিকিত্সা করছে এবং কারণটি নয়। সাইফারের আকার হ্রাস করার ফলে এমটিইউ খণ্ডন রোধ করার সম্ভাবনা রয়েছে ... যা আসল সমস্যা, এটি নীচে @ জাগগুলি দ্বারা উত্থাপিত হয়েছিল।
jcwenger

"HostKeyAlgorithms ssh-rsa, ssh-dss" লাইনটি / etc / ssh / ssh_config যুক্ত করে জাইসেল মডেমটিতে এসএসএইচ সক্ষম না হওয়ায় আমার সমস্যাটি স্থির করে। উপরের টেটবক্সের অন্যান্য সমস্ত লাইন আমার মেশিনে ইতিমধ্যে ছিল। বখশিষের জন্য ধন্যবাদ!
জেফ রাইট


6

এটি এমটিইউ ইস্যুটিকে কিছু মান হার্ডকোড ছাড়াই স্থির করেছে, এটি এটি ssh এবং এটি দ্বারা প্রভাবিত অন্য কোনও প্রোটোকলের জন্য এটি ঠিক করবে। মূল হিসাবে নিম্নলিখিতটি চালান:

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

আপনি সমস্যাটি এবং সমাধান সম্পর্কে এখানে এবং এখানে আরও পড়তে পারেন ।


ব্যাখ্যা: "এটি প্রমাণিত হয়েছে যে কার্নেল / প্রোক ফাইল সিস্টেমটি 'ফাইল' / প্রোক / সিএস / নেট / আইপিভি 4 / টিসিপি_ম্টু_প্রবিলিংয়ের মান পরিবর্তন করে টিসিপি এমটিইউ প্রোব সক্ষম ও নিষ্ক্রিয় করার একটি সহজ উপায় সরবরাহ করে 0 ; 1 = সক্ষম যখন একটি ব্ল্যাকহোল রাউটার সনাক্ত হয়; 2 = সর্বদা সক্ষম থাকে ""
জর্জ

1

কিছু খুঁজছেন কি এবং নিচের পরামর্শ পাওয়া এখানে :

আপনার / etc / ssh / ssh_config (not sshd_config) এর নীচের লাইনটি মন্তব্য করেছে না তা নিশ্চিত করার চেষ্টা করুন:

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

আপনি সেই ফাইলটি ডিফল্টর দিকে ফিরিয়ে আবার চেষ্টা করার চেষ্টা করতে পারেন, যেমন openssh-clientপ্যাকেজের নাম আইআইআরসি আনইনস্টল করুন এবং পুনরায় ইনস্টল করুন ।


এটি ঠিক করে নি :(
আমার লন

1

এটি সমাধানের জন্য নেটওয়ার্ক ইন্টারফেস এমটিইউ পরিবর্তন করুন। এটি উবুন্টু 14.04 এর জন্য একটি বাগ।

এটি আমার পক্ষে কাজ করেছে:

sudo ip li set mtu 1200 dev wlan0

বা:

sudo ifconfig wlan0 mtu 1200

ssh ভিপিএন হোস্টের সাথে সংযোগ করতে ব্যর্থ হয়েছে - এসএসএইচ 2_MSG_KEX_ECDH_REPLY প্রত্যাশায় ঝুলছে


1

আইপিভি 4 দিয়ে জোর করে এই সমস্যাটি সমাধান করতে সক্ষম হয়েছি

ssh -4 username@host.xyz

যেহেতু আমি একটি ম্যাকে আছি আমি জানি না যে এখানে এমটিইউ সেটিংস কী কীভাবে আছে বা কীভাবে সেগুলি পরিবর্তন করা যায়, তবে ভেবেছিলাম যে অন্যরা এতে লাভবান হতে পারে।


এই বিকল্পটি ssh কে কেবলমাত্র আইপি 4 ব্যবহার করতে বাধ্য করে। আমিও ম্যাক এ আছি এবং এটি আমার সমস্যা সমাধান করে নি।
জর্জ

0

আমি আজই এই সমস্যাটি উইন্ডোজ (গিট দিয়ে বিতরণ করা) এবং উবুন্টুতে শুরু করেছি।

এটি ওপেনএসএইচ- তে একটি বাগ হিসাবে দেখা যাচ্ছে, লাউচপ্যাডে একটি সমস্যা রয়েছে

এটি উইন্ডোজে 3 ডিজে-সিবিসি সাইফার এবং উবুন্টু-এর চাবি জোর করে আমার জন্য কাজ করেছিল।


0

এখানে কিছুটা নেक्रो, তবে আমি লিনাক্সের ওপেনএসএসএইচ_7.8 পি 1 এ এর ​​মুখোমুখি হয়েছি। ওপেনএসএসএইচ-এর সাম্প্রতিক প্রকাশগুলিতে ডিএসসিপি চিহ্নিতকরণের প্রবর্তনটি ভিএমওয়্যার এনএটি-এ বিগড়ে চলেছে বলে মনে হচ্ছে (ব্রিজড নেটওয়ার্কিং নীচের লিঙ্কগুলিতে ভাল বলে উল্লেখ করা হয়েছিল)।

নিম্নলিখিতটি / etc / ssh / ssh_config এ সংযুক্ত / সেট করে আপনি এই মুহুর্তে কাজ করতে পারেন :

IPQoS lowdelay throughput

অতিরিক্ত কারণগুলি হ'ল পুটি (বা অন্যান্য স্বতন্ত্র এসএসএইচ ক্লায়েন্ট) একই হোস্ট থেকে সমস্যাটির মুখোমুখি না হতে পারে এবং আপনার এমটিইউ এখন পর্যন্ত পরীক্ষা করে দেখেছে। অর্থাৎ,

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

এই পোস্টগুলি বিশেষ সহায়ক ছিল এবং আমাকে যেখানে আমার দরকার ছিল সেখানে নিয়ে গিয়েছিলাম:

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


-2

ssh -c aes256-ctr ভাল কাজ করে;


আপনি কেন বিশ্বাস করেন যে এই আদেশটি সমস্যার সমাধান করবে?
স্কট
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.