SSH कनेक्शन समस्या "होस्ट कुंजी सत्यापन विफल हुआ ..." त्रुटि के साथ

Question

मैं एसएसएच के माध्यम से अपने लैन में एक और उबंटू मशीन से कनेक्ट कर सकता हूं। तब पीसी के दोनों में मैंने ओपनश-सर्वर स्थापित किया था लेकिन दूसरे उबंटू कंप्यूटर से मैं एसएसएच के माध्यम से अपने पीसी से कनेक्ट नहीं कर सकता था और मैंने यह समस्या देखी:

होस्ट कुंजी सत्यापन विफल रहा ...

Comments

क्या आप होस्ट नाम या IP- पते का उपयोग करते हैं?

— थोरबजोरन रावन एंडरसन

समान नहीं, लेकिन मुझे एक ही त्रुटि मिली लेकिन एक अलग समस्या के कारण: serverfault.com/questions/494916/…

— zengr

यह एक उबंटू-विशिष्ट मुद्दा नहीं है। sshकमांड-लाइन से किसी के साथ भी हो सकता है ।

— MarkHu

Answer 1

"होस्ट कुंजी सत्यापन विफल" का अर्थ है कि दूरस्थ होस्ट की होस्ट कुंजी को बदल दिया गया था।

SSH दूरस्थ होस्ट की होस्ट कुंजी को स्टोर करता है ~/.ssh/known_hosts। आप या तो उस पाठ फ़ाइल को मैन्युअल रूप से संपादित कर सकते हैं और पुरानी कुंजी को हटा सकते हैं (आप त्रुटि संदेश में लाइन नंबर देख सकते हैं), या उपयोग करें

ssh-keygen -R hostname

से आदमी पेज :

-R hostname
किसी ज्ञात_hosts फ़ाइल से hostname से संबंधित सभी कुंजियों को निकालता है। यह विकल्प हैशेड होस्ट को हटाने के लिए उपयोगी है।

(जो मैंने SSH की ज्ञात_होस्ट फ़ाइल से किसी विशेष होस्ट कुंजी को हटाना संभव है? ) के उत्तर से सीखा ।

Comments

इसका मतलब यह भी हो सकता है कि आपके पास दूरस्थ होस्ट की होस्ट कुंजी नहीं है। उदाहरण के लिए, यदि मैं rm ~/.ssh/*, तो ssh -o BatchMode=yes root@somewhere, अगर और कुछ भी गलत नहीं है, तो मुझे Host key verification failed. महत्वपूर्ण नहीं होगा यदि आप हमेशा इंटरैक्टिव हों, लेकिन उसी त्रुटि का सामना करने वाली स्क्रिप्ट के लिए प्रासंगिक हो।

— रॉन बुर्क

अप्रत्याशित रूप से, ssh-keygen -R example.net:7999पैदावार Host example.net:7999 not found in known_hosts।

— एलेक्स

मैंने known_hostsफाइल निकाली और फिर से ssh। इसने काम कर दिया।

— ParisaN

फ़ाइल ~/.ssh/known_hostsअपठनीय है

— जोहो पिमेंटेल फेरेरा

Answer 2

यदि आप कुछ दूरस्थ / स्क्रिप्टिंग स्थितियों में चल रहे हैं, जहां आपको प्रॉम्प्ट-टू-ऐड-होस्टकी के लिए इंटरैक्टिव एक्सेस की कमी है, तो इस तरह से काम करें:

$ ssh -o StrictHostKeyChecking=no [e-mail] uptime

चेतावनी: ज्ञात मेजबानों की सूची में स्थायी रूप से 'something.example.com, 10.11.12.13' (RSA) जोड़ा गया।

Comments

+1, यह एक बदसूरत समाधान है, लेकिन स्वचालित निगरानी प्रक्रियाओं के कुछ मामलों में जो डायमेक आईपी से जुड़े उपकरणों के साथ काम करते हैं, यह एक सरल और स्वीकार्य समाधान है।

— निंसुओ

+1 उदाहरण के लिए, जेनकिंस निष्पादन के लिए, यह एक अच्छा समाधान है। साभार

— लोबो

@ लोबो अधिक सहमत नहीं हो सकता है, मैं इसे sh """ssh -o StrictHostKeyChecking=No ec2-user@someIpAddress-e2e sudo service tomcat restart"""

— जेनकिंस के

मेरी ज़िंदगी बचाई। जीवन रक्षक समाधान।

— user1735921

Answer 3

इसके अलावा कभी-कभी ऐसी स्थिति होती है जब आप सीरियल कंसोल पर काम कर रहे होते हैं, तो वर्बोज़ मोड में कमांड के ऊपर चेक करने से -vपता चलता है कि आपके /dev/ttyपास मौजूद नहीं है, जबकि यह करता है।

ssh -v user@hostname

ऊपर मामले में बस को हटाने /dev/ttyऔर की एक सिमलिंक बनाने /dev/ttyS0के लिए /dev/tty।

rm /dev/tty
ln -s /dev/ttyS0 /dev/tty

एक विकल्प के रूप में, id_rsa.pubदूरस्थ स्थान में जोड़ें , इसलिए पासवर्ड को संकेत नहीं दिया जाता है और आपको लॉगिन एक्सेस मिलता है।

Comments

-V पैरामीटर का उपयोग करने की सलाह देने के लिए +1; यह बहुत मदद कर सकता है जब ssh समस्याओं डिबगिंग।

— डेनियल कुल्मन

Answer 4

मेरे मामले में, यह एक udev समस्या के कारण था - कोई /dev/ttyडिवाइस नोड नहीं था । मेरे लिए समाधान सिर्फ था:

sudo mknod -m 666 /dev/tty c 5 0

Answer 5

टर्मिनल पर:

ssh -o StrictHostKeyChecking=no -i YourPublicKey.pem [e-mail] uptime

निम्न संदेश, या समान, दिखाई देगा:

Warning: Permanently added 'example.com, XX.XXX.XXX.XX' (ECDSA) to the list of known hosts.
 00:47:37 up 3 min,  0 users,  load average: 0.00, 0.00, 0.00

फिर, अपने EC2 को सामान्य से कनेक्ट करें:

ssh -i YourPublickey.pem [e-mail]

Comments

मुझे command-line line 0: Bad yes/no/ask argument.इसलिए मिला क्योंकि आप तर्क के रूप में 'नहीं' के बजाय गलत तरीके से 'नहीं' का उपयोग करते हैंStrictHostKeyChecking

— एक्सल ब्रेग्न्सबो

Answer 6

ठीक है, यह सिर्फ इसलिए कि दूसरे ubuntu को कुंजी द्वारा कनेक्शन की आवश्यकता होती है न कि पासवर्ड की।

मेरा सुझाव है कि आप sudo dpkg-reconfigure openssh-serverअपने पीसी पर उपयोग करें, और फिर इसे ठीक से काम करना चाहिए। यह ओपनश के लिए कॉन्फ़िगरेशन को रीसेट करेगा और डिफ़ॉल्ट पासवर्ड प्रमाणीकरण पर वापस आना चाहिए।

दूसरी संभावना यह है कि आपके पीसी में आपके अन्य ubuntu के लिए पहले से ही एक कुंजी है, और यह बदल गया है कि इस प्रकार अब पहचाना नहीं जा रहा है। इस स्थिति में, आपको .ssh/authorized_keysअपने ubuntu की पहचान करने वाली समस्याग्रस्त रेखा को हटाने के लिए फ़ाइल को संपादित करना होगा ।

Answer 7

यह एक पुराना धागा है और मैं अभी इस जवाब पर भागा हूं, मैं इसे हल करने के लिए मैंने जो कुछ भी किया है उसे जोड़ूंगा।

ssh-keygen -f "/home/USER/.ssh/known_hosts" -R HOSTNAME

मैंने सिर्फ उस त्रुटि संदेश को देखा, जो उसने मुझ पर फेंका था और उसने उसे मेजबानों की सूची से हटाने के लिए उस आदेश को चलाने के लिए कहा था। उसके बाद मैंने निम्नलिखित कार्य किया:

ssh-copy-id HOSTNAME

जब तक मैं सर्वर में ssh करने में सक्षम था, तब तक मैंने वहाँ से संकेतों का पालन किया।

Comments

इस आदेश के रूप में मुझे उबंटू 12.4 में सुझाव मिल रहा है।

— MaNKuR

Answer 8

इसका मतलब है कि आपकी दूरस्थ होस्ट कुंजी बदल गई थी (हो सकता है कि होस्ट पासवर्ड बदल दें),

आपके टर्मिनल ने रूट उपयोगकर्ता के रूप में इस कमांड को निष्पादित करने का सुझाव दिया

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]:4231

आपको अपने पीसी / सर्वर पर होस्ट सूची से उस होस्ट नाम को निकालना होगा। प्रतिलिपि का सुझाव दिया कि कमांड और रूट उपयोगकर्ता के रूप में निष्पादित करें।

$ sudo su                                                            // Login as a root user

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]:4231   // Terminal suggested command execute here
Host [www.website.net]:4231 found: line 16 type ECDSA
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

$ exit                                                               // Exist from root user

$ sudo ssh [e-mail] -p 4231                              // Try again

आशा है कि यह काम करता है।

Answer 9

आपको अपनी कुंजी इस तरह से बदलनी चाहिए: अपनी दी गई त्रुटि से, उदाहरण के लिए कौन-सी होस्ट-कुंजी बदली गई है: / User/user-name/.ssh/ogn_hosts में ECDSA कुंजी को बंद करने के लिए कहा कि 5 वीं कुंजी बदल गई है, इसलिए ऐसा करें:

sed -i '5d' ~/.ssh/known_hosts

सूचना: आपको जड़ होना चाहिए या सुडोल के लिए विशेषाधिकार होना चाहिए।

Comments

नहीं, जब तक आप इसे किसी और के लिए नहीं कर रहे हैं, तब तक इसे जड़ और सूडो की आवश्यकता नहीं है। आप फ़ाइल को अपने होम डायरेक्टरी में एडिट कर रहे हैं। दूसरा: काम करने के लिए कमांड के लिए जीएनयू सेड की आवश्यकता होती है।

— टेक्राफ

हो सकता है कि आप सही हों, लेकिन मैंने मैक ओएसएक्स से उबंटू-सर्वर पर एसएस करने की कोशिश की और मुझे ऐसा करना होगा। वैसे आपकी टिप्पणी के लिए धन्यवाद।

— आमिर .AG

Answer 10

आपको टारगेट होस्ट की rsa कुंजी को टारगेट /home/user/.ssh/known_hostsपर चलाकर सोर्स होस्ट में डालनी है

ssh-keyscan -t rsa @targethost

Answer 11

हो सकता है कि आपको बस "हां" दर्ज करने की आवश्यकता हो जब ssh पुष्टि करें कि आप कनेक्ट करना जारी रखना चाहते हैं।

बलो की तरह।

The authenticity of host 'xxx' can't be established.
ECDSA key fingerprint is yyy.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'xxx' (ECDSA) to the list of known hosts.
Enter passphrase for key '/Users/ysy/.ssh/id_rsa':

फिर अपना पासवर्ड डालें।

कृपया ध्यान दें "क्या आप वाकई कनेक्ट करना जारी रखना चाहते हैं (हां / नहीं)? हां "। आपको हाँ दर्ज करना चाहिए, दर्ज नहीं करना चाहिए।

Answer 12

होस्ट कुंजी जाँच को सख्ती से अक्षम करने के अलावा, आप टाइप करके भी जुड़ सकते हैं:

ssh -o LogLevel=quiet -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no <username@target_machine_ip_or_domain_name>

Answer 13

pico ~/.ssh/known_hosts और सभी लाइनों को हटा दें, बस फिर से कनेक्ट करें और आपको एक नई कुंजी मिलेगी।

Comments

यह एक खतरनाक समाधान है, क्योंकि आप अपने सभी होस्ट कुंजी को हटा देंगे। स्वीकृत समाधान, ssh-keygen -R hostnameबेहतर है।

— मसनफोर्ड २४'१४

Answer 14

मेरा समाधान इस ब्लॉग पोस्ट से आया है: SSH सिक्योर शेल क्लाइंट के लिए एल्गोरिथ्म वार्ता विफल रही

आपको फ़ाइल को इस प्रकार संशोधित करना होगा:

sudo nano /etc/ssh/sshd_config

और फिर निम्नलिखित जोड़ें:

# Ciphers
Ciphers aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour
KexAlgorithms diffie-hellman-group1-sha1

मूल रूप से आपने विभिन्न समाधानों की कोशिश की, जब तक कि आपको एक ऐसा न मिल जाए जो आपकी समस्या को हल कर सके। यदि उपरोक्त समाधान काम नहीं करते हैं, तो कृपया इसे आज़माएँ। यदि यह काम नहीं करता है, तो कृपया दूसरों को आज़माएँ।

Answer 15

बस "sudo vi /var/root/.ssh/ogn_hosts" करें और उस लाइन को हटा दें, जो एक होस्ट के लिए एक कुंजी रखती है जिसे आप फिर से कनेक्ट करने और पुन: कनेक्ट करने का प्रयास कर रहे हैं।

मैं आपकी विशेष स्थिति के बारे में नहीं जानता, लेकिन शायद यह त्रुटि इस तरह एक संदेश के साथ आई:

my_mac:~ oivanche$ sudo ssh pi@192.168.0.45
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:sx1Z4xyGY9venBP6dIHAoBj0VhDOo7TUVCE2xWXpzQk.
Please contact your system administrator.
Add correct host key in /var/root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /var/root/.ssh/known_hosts:74
ECDSA host key for 192.168.0.45 has changed and you have requested strict checking.
Host key verification failed.

यदि आप लॉग को और अधिक ध्यान से पढ़ेंगे, तो आप देखेंगे कि होस्ट से मिली कुंजी आपके पास पहले से मौजूद एक कुंजी के साथ विरोध कर रही है - इस मामले में यह जाने माने_होस्ट्स फाइल की लाइन 74 पर है (ईसीडीएसए कुंजी को / var / में बंद करना) जड़ / .ssh / known_hosts: 74)। ज्ञात_होस्ट्स से लाइन निकालें, परिवर्तन सहेजें और फिर से कनेक्ट करें।

Answer 16

chmod 666 /dev/tty 

अभी तक एक और tty समाधान है - कभी-कभी, इस डिवाइस फ़ाइल में गलत अनुमतियां हैं।