अधिकृत कुंजी में जोड़े गए सार्वजनिक कुंजी के साथ भी ssh नहीं किया जा सकता है

Question

मेरे पास एक डिजिटल ओशन ड्रॉपलेट है जिसे मैं खुद को एसएचएस एक्सेस देने की कोशिश कर रहा हूं। मुझे यकीन नहीं है कि यह पहले क्या किया गया था। मैंने डिजिटल महासागर UI के माध्यम से अपनी सार्वजनिक कुंजी जोड़ने की कोशिश की है। यह काम नहीं किया, मैं मिलता रहा permission denied (publickey)।

मैंने डिजिटल महासागर कंसोल के माध्यम से सर्वर तक पहुंच बनाई और मैन्युअल रूप से मेरी सार्वजनिक कुंजी को जोड़ा /root/.ssh/authorized_keys। मैं तो ssh का उपयोग करने की कोशिश की ssh root@x.x.x.x। यह काम नहीं किया (अनुमति से इनकार)।

इसलिए मैंने एक नया उपयोगकर्ता जोड़ने का प्रयास किया, निर्देशिका को निर्देशिका और फ़ाइल पर /home/me/.sshअनुमतियों के साथ बनाया । फिर मैंने कोशिश की । यह भी काम नहीं किया।700.ssh600authorized_keysssh me@x.x.x.x

Ssh डेमन को फिर से शुरू करने से कुछ भी नहीं बदलता है।

मुझे किसकी याद आ रही है?

संपादित करें:

यहाँ verbose ssh आउटपुट है।

https://gist.github.com/jaesung2061/a37cfd68308414cede8abf7f0137daa9

2 संपादित करें:

LogLevel DEBUG3 उत्पादन:

Comments

कनेक्शन से वर्बोज़ लॉग पोस्ट करें, sshd_config की आपकी सामग्री और सर्वर लॉग में ssh से संबंधित संभावित त्रुटियाँ।

— जकूज़ी

@Jakuje मैंने आउटपुट जोड़ा है ... मैंने आपकी टिप्पणी को पहले नोटिस नहीं किया था।

— जेफ

कुंजी अस्वीकार कर दी है। संभावित समस्याओं के लिए सर्वर लॉग (संभवतः के साथ की जाँच करें LogLevel DEBUG3में sshd_config)। मुझे संदेह है कि ये अनुमति मुद्दे हैं, लेकिन इसके कई कारण हो सकते हैं।

— जकुज

यह कहता है[date omitted] www sssh[15029]: Connection closed by x.x.x.x port 55519 [preauth]

— जेफ

अधिकृत_की फ़ाइल की अनुमतियाँ क्या हैं? ls -ld ~ ~/.ssh ~/.ssh/authorized_keys? वर्बोज़ संशोधित करने, पुनः आरंभ ssh सेवा फ़ाइल ऊपर उल्लेख किया है सर्वर से लॉग इन करने के लिए, फिर से कनेक्ट करने और लॉग पोस्ट (में भी होना चाहिए auth.log।

— Jakuje

Answer 1

ग्राहक विन्यास

सेट अप ~/.ssh/config

के लिए होस्ट प्रविष्टियों को सेट करना sshवास्तव में आसान है और आपको बहुत परेशानी से बचाएगा। यहाँ एक उदाहरण है:

Host digitaloceanbox
Hostname 111.111.111.111
User root
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/digitalocean-rsa
ForwardX11 yes


Host github github.com
Hostname github.com
User git
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/github-rsa
ForwardX11 no

इस उदाहरण में, हम सेटअप में digitaloceanboxऔर githubऔर github.comइसलिए है कि हम निम्न कमांड कर सकते हैं:

1. ssh github
2. ssh digitaloceanbox

यदि हम कॉन्फ़िगर फ़ाइल में निर्दिष्ट एक से अधिक उपयोगकर्ता के रूप में लॉगिन करना चाहते हैं, तो हम सिर्फ user@भीख मांगने का काम करते हैं:

• ssh user@digitaloceanbox

sshकुंजी उत्पन्न करना

ssh-keygen -t rsa -b 4096 -C user@homemachine
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):  /home/user/.ssh/digitalocean-rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/digitalocean-rsa
Your public key has been saved in /home/user/.ssh/digitalocean-rsa.pub.
The key fingerprint is:
SHA256:p9PYE/tveF2n//bLbp3ogYDtMtYEC5ziQiPxeob6fbo user@homemachine

ध्यान दें कि मैंने उस निजी कुंजी का पूरा पथ निर्दिष्ट किया है जिसे मैं संकेत देते समय उत्पन्न करना चाहता हूं ssh-keygen। मैंने टिप्पणी ( -C) भी परिभाषित की है जो मुझे दूरस्थ मशीनों पर कुंजियों को आसानी से पहचानने की अनुमति देती है।

यह दो फाइलें बनाएगा:

1. .ssh/digitalocean-rsa
   • निजी कुंजी। इसे कभी साझा न करें ।
2. .ssh/digitalocean-rsa.pub
   • सार्वजनिक कुंजी। यह वही है जो आप सर्वर पर स्टोर करने के लिए प्रमाणित करते हैं।

जब आप अपनी sshकुंजी प्रदान करते हैं , तो सुनिश्चित करें कि यह .pubसंस्करण है !! जब आप अपने साथ जोड़ते हैं ~/.ssh/config, तो आपके द्वारा सिस्टम में जोड़ी गई सार्वजनिक कुंजी से मेल खाने वाली सही निजी कुंजी जोड़ना सुनिश्चित करें।

---

सर्वर कॉन्फ़िगरेशन

अधिकांश इंस्टॉलेशन सार्वजनिक कुंजी प्रमाणीकरण सक्षम होंगे। यदि आप सभी विली नीली चीजें करना शुरू करते हैं, तो आप कुछ समस्याओं में भाग सकते हैं। जहां ओपी उनकी समस्या में है, मैं सुझाव देता हूं कि ओपी /root/.ssh/शुरू करने के लिए निर्देशिका को हटा देता है ।

यह अनुशंसित नहीं है कि आप sshरिमोट सिस्टम पर रूट उपयोगकर्ता तक पहुंचने के लिए उपयोग करते हैं। यह अनुशंसा की जाती है कि आप sshकिसी अन्य उपयोगकर्ता में, और फिर अपने पासवर्ड ( sudo su -) का उपयोग कर रूट करने के लिए आगे बढ़ें ।

का उपयोग कर होस्ट करने के लिए कुंजी जोड़ें ssh-copy-id

चाहे आप किसी अन्य उपयोगकर्ता को बनाने और sshउस उपयोगकर्ता या मूल उपयोगकर्ता के रूप में उपयोग करने का निर्णय लेते हों , निम्नलिखित sshसर्वर पर चाबियाँ रखने का अनुशंसित तरीका है :

1. ssh-copy-id -i /home/user/.ssh/digitalocean-rsa.pub user@digitaloceanbox

यह sshdनिर्देशिका और आवश्यक अनुमतियों के साथ आवश्यक फ़ाइलों को बनाने की अनुमति देता है। इसका मतलब यह है कि आपके पास अनुमतियों को गड़बड़ करने या विवरण को याद रखने की आवश्यकता के लिए शून्य मौका है। बस चाबियाँ अपलोड करने के लिए उपकरण का उपयोग करें।

पासवर्ड प्रमाणीकरण अक्षम करें

कहा जा रहा है कि, एक बार जब आप अपने आप को चाबी देंगे और सत्यापित करेंगे कि आप कुंजियों का उपयोग करके कनेक्ट करने में सक्षम हैं, तो यह अनुशंसा की जाती है कि आप पासवर्ड प्रमाणीकरण को अक्षम करें sshdऔर सेवा को पुनरारंभ करें:

1. संपादित करें /etc/ssh/sshd_config
2. PasswordAuthentication no
3. sudo systemctl restart sshd

नए उपयोगकर्ताओं के बारे में क्या?

यदि आप पासवर्ड प्रमाणीकरण अक्षम करते हैं, तो आप नए उपयोगकर्ताओं को कैसे कुंजी दे सकते हैं? एक तरीका /etc/skelनिर्देशिका में टेम्पलेट फ़ाइलों को जोड़ना है । एक बार जब आप उपयोगकर्ता को एक कुंजी देंगे, तो निम्न कार्य करें:

1. sudo cp -r .ssh/ /etc/skel/
2. ls /etc/skel/.ssh
3. किसी भी फ़ाइल को संपादित करें /etc/skel/.ssh/ताकि वे रिक्त हों, जब तक कि आप हर नए बनाए गए उपयोगकर्ता के लिए स्वचालित रूप से अपने आप को कुंजी नहीं देना चाहते।

जब आप नए उपयोगकर्ता बनाते हैं sudo useradd -m newuser, तो उस उपयोगकर्ता के पास होगा .ssh/authorized_keys, जिसे आप संपादित कर सकते हैं और उसके पास उचित अनुमतियां होंगी।

डिबगिंग

आप sshdलॉग फ़ाइल देख सकते हैं यह देखने के लिए कि कनेक्शन विफल क्यों है या अस्वीकार कर दिया गया है:

1. sudo tail -f /var/log/auth.log

जब आप इस आदेश को चला रहे हों, तो लॉगिन का प्रयास करने के लिए दूसरे टर्मिनल का उपयोग करें। कई बार दिए गए संदेश समस्या को ठीक करने या ऑनलाइन समाधान खोजने में मदद करने के लिए पर्याप्त होते हैं।

Comments

डिबगिंग कदम ने मेरे लिए काम किया। रूट निर्देशिका में गलत अनुमतियाँ (700 होने की आवश्यकता थी)

— naisanza

Answer 2

Ssh चाबियों के साथ स्वामित्व, फ़ाइल और निर्देशिका अनुमतियों के बारे में काफी उपयुक्त है।

~ / .ssh / का स्वामी के पास होना चाहिए और इसकी 700 अनुमतियां होनी चाहिए। ~ /। ssh / अधिकृत_की मालिक के पास होनी चाहिए और 600 अनुमतियाँ होनी चाहिए।

तो, रूट के लिए:

sudo chown root:root -R /root/.ssh/
sudo chmod 700 /root/.ssh/
sudo chmod 600 /root/.ssh/authorized_keys

मेरे लिए उपयोगकर्ता:

sudo chown me:me -R /home/me/
sudo chmod 700 /home/me/.ssh/
sudo chmod 600 /home/me/.ssh/authorized_keys

और फिर दोबारा कोशिश करें।

बेशक आपको / etc / ssh / sshd_config में भी जांचना चाहिए कि क्या रूट को बिल्कुल लॉग इन करने की अनुमति है, या सिर्फ ssh कीज़ के साथ।

यदि आपके पास है :

PasswordAuthentication no

फिर आप सेट कर सकते हैं:

PermitRootLogin yes

और फिर sshd को पुनरारंभ करें:

/etc/init.d/sshd restart

और फिर प्रयत्न करें।

ध्यान दें कि ssh के साथ, sshd डेमॉन को तब भी फिर से शुरू किया जा सकता है, जब इसके लिए ssh सत्र का उपयोग किया जाए।

आपकी अपलोड की गई लॉग फ़ाइल स्निपेट्स को देखकर, ऐसा लगता है कि आप MacOSX का उपयोग कर रहे हैं? क्या आप एक नई ssh कुंजी बना सकते हैं?

इसके अलावा, मुझे अतीत में पता चला कि जब मेरे पास अपने उपयोगकर्ता के लिए मेरे स्थानीय कंप्यूटर पर एक से अधिक निजी ssh कुंजी है, तो यह कभी-कभी ssh के साथ दूरस्थ रूप से लॉग इन करना असंभव बनाता है। इसे हल करने के लिए फ़ाइल ~ / .shsh / config में स्थानीय कंप्यूटर पर प्रविष्टियाँ बनाने में बहुत मदद मिली। उदाहरण के लिए :

Host my-vps
  HostName my-vps-ip-address-here
  IdentityFile ~/.ssh/id_rsa-my-private-key-location
  User my-username-here

उसके बाद अपने स्थानीय कंप्यूटर पर कमांड लाइन पर प्रयास करें:

ssh -v my-vps

Ssh कुंजियों का उपयोग करते समय, साथ ही कुछ अन्य लॉगिन के लिए कोई ssh कुंजियाँ नहीं हैं, आप ssh कुंजियों के साथ प्रविष्टियों के अलावा, ~ / ssh / config फाइल में ssh कुंजी के बिना ssh लॉगिन को भी परिभाषित कर सकते हैं, उदाहरण के लिए:

Host pi
  Hostname 192.168.1.111
  Port 22
  User pi
  PasswordAuthentication yes
  PreferredAuthentications password

यह मेरे लिए ठीक काम करता है। यह भी परिभाषित करना संभव है कि कमांड लाइन पर किस कुंजी का उपयोग करना है:

ssh -v root@10.111.111.254 -i .ssh/id_rsa

यह डिबगिंग को आसान बना सकता है, और कमांड लाइन पर यह हमेशा स्थानीय कंप्यूटर पर काम करना चाहिए।

Comments

इस समाधान के अलावा, मुझे अपने होम फोल्डर के लिए भी अनुमति sudo chmod 700 /home/me/

— बदलनी पड़ी

तुम एक जीवन रक्षक हो, @ अल्बर्ट-जे! IdentityFileलाइन मुझे एक घंटे की लीक से बाहर हो गया।

— ज़ेव

अनुमति की बात मुझे हर बार मिलती है। धन्यवाद!

— cs94njw

Answer 3

Ssh डेमन कॉन्फ़िगरेशन को दोबारा जांचें (इसमें होना चाहिए /etc/ssh/sshd_config):

PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

यह भी देखने के लिए कि क्या वे उपयोगकर्ता और समूहों के लिए श्वेत सूचियों के रूप में कार्य करते हैं, यह देखने के लिए कॉन्फ़िगरेशन फ़ाइल की जाँच करें कि क्या AllowUsers या AllowGroups सेट किए गए हैं।

इसके अलावा, मैंने देखा कि आप रूट उपयोगकर्ता के लिए एक कुंजी जोड़ने की कोशिश कर रहे हैं। डिफ़ॉल्ट रूट लॉगिन द्वारा अक्षम किया जाना चाहिए, लेकिन आप इसे PermitRootLogin फ़ील्ड के माध्यम से भी बदल सकते हैं ।

Comments

इनमें से कोई भी काम नहीं कर रहा है: / मुझे अभी भी मिल रहा हैPermission denied (publickey)

— जेफ

Answer 4

आपके द्वारा लिंक किए गए लॉग के अनुसार, मुझे लगता है कि आपको निजी कुंजी फ़ाइल नहीं ढूंढने में क्लाइंट की समस्या है ।

• पहले जाँचें कि फ़ाइल ~/.ssh/id_rsaआपके स्थानीय मशीन पर मौजूद है, और सही एक _ है (यदि आपके पास अधिक है)।

• .sshफ़ोल्डर की अनुमतियों की जांच करें ( drwx------यदि होना चाहिए , तो नहीं sudo chmod 700 ~/.ssh) और इसकी सामग्री ( -rw-------यदि नहीं, तो होनी चाहिए sudo chmod 600 ~/.ssh/*) । रिमोट मशीन के लिए भी वही अनुमतियां लागू करें।

इसके अतिरिक्त, आप अपनी इच्छित निजी कुंजी का उपयोग करके बल देने की कोशिश कर सकते हैं , इसे सीधे पैरामीटर के sshसाथ दे सकते हैं -i।

• आप अनुसरण की तरह कुछ चला सकते हैं:

  ssh -i /path/to/your/private-key root@X.X.X.X

  या

  ssh -i ~/.ssh/id_rsa myRemoteUser@X.X.X.X

आप ssh manpage ( man sshअपने टर्मिनल पर रन ) पर अधिक जानकारी प्राप्त कर सकते हैं ।

यह भी ध्यान रखें कि यदि आप rootउपयोगकर्ता के रूप में लॉगिन करना चाहते हैं, तो लॉगिन करने से पहले आपका रूट खाता सक्षम होना चाहिए, इसके साथ sudo passwd rootया आपके सर्वर एडमिनिस्ट्रेशन टूल के लिए एक पासवार्ड बनाना (Ubutntu में रूट खाता डिफ़ॉल्ट रूप से अक्षम है) । आप Ubuntu Wiki पर अधिक जानकारी प्राप्त कर सकते हैं ।

आशा करता हूँ की ये काम करेगा।

Answer 5

मैंने पुन: स्थापित किया openssh-serverजो समस्या को ठीक करता है। दिए गए समाधान सभी महान हैं, लेकिन उन्होंने मेरे लिए काम नहीं किया। मुझे नहीं पता कि क्या समस्या पैदा कर रहा था, लेकिन मुझे लगता है कि पिछले डेवलपर ने कॉन्फ़िगरेशन को गड़बड़ कर दिया है और चीजों को बहुत खराब कर दिया है।

मुझे संदेह है कि मेरे जैसे विशिष्ट मुद्दे के साथ कोई भी होगा। हालाँकि, यदि आपके पास एक डिजिटल महासागर की छोटी बूंद है, तो आप SSH का उपयोग नहीं कर सकते हैं, और दिए गए समाधान कार्यों में से कोई भी काम नहीं करता है, इन आदेशों को डिजिटल महासागर कंसोल के माध्यम से चलाकर SSH सर्वर को पुनर्स्थापित करें। खबरदार यह एक विनाशकारी प्रक्रिया है और/etc/ssh/ आपकी (नहीं .sshनिर्देशिका) में पुरानी कॉन्फ़िगरेशन फ़ाइलों को मिटा देगा ।

apt-get purge openssh-server
apt-get autoremove
apt-get autoclean
apt-get install openssh-server

अपने ssh क्लाइंट / कुंजियों को क्रम में मानकर, आपको अपने सर्वर में SSH करने में सक्षम होना चाहिए।

Answer 6

यह मुद्दा मेरे लिए डिजिटल महासागर पर डेबियन छवि का उपयोग करके पॉप अप हुआ। किसी तरह संक्षिप्त सेट प्रक्रिया के दौरान, शायद जब मैं रूट पासवर्ड सेट करता हूं, तो मालिक /rootको उपयोगकर्ता के लिए बदल दिया गया था debian। मैंने निम्नलिखित को देखा /var/log/auth.log:

Jul 26 20:58:17 docker sshd[12576]: Authentication refused: bad ownership or modes for directory /root

बस निष्पादित करने chown root:root -R /rootसे समस्या हल हो गई।

HTH

Answer 7

बस एक बहुत ही इसी तरह की समस्या थी। इसने मेरे लिए काम किया - इस लाइन को / etc / ssh / sshd_config में जोड़ें

AuthorizedKeysFile %h/.ssh/authorized_keys 

फिर सामान्य तरीके से ssh को पुनरारंभ करें।