SSH कीज़: सर्वर पर बिना पासवर्ड लॉगिन की सेटिंग

SSH-कुंजी फ़ाइलों की एक जोड़ी है: निजी कुंजी (private key) आपके पास रहती है, और सार्वजनिक कुंजी (public key) सर्वर पर जाती है। कनेक्ट होते समय सर्वर जाँचता है कि आपके पास उन्हीं में से किसी एक से मेल खाती निजी कुंजी है, और बिना पासवर्ड के आने देता है। यह पासवर्ड से ज़्यादा सुविधाजनक है और कहीं ज़्यादा सुरक्षित: कुंजी को ब्रूट-फ़ोर्स से तोड़ना लगभग असंभव है। नीचे SSH कीज़ का सेटअप है, कुंजी बनाने से लेकर पासवर्ड लॉगिन बंद करने तक, और उन गलतियों के हल भी जिन पर लोग सबसे ज़्यादा अटकते हैं।

कुंजी से प्रमाणीकरण कैसे काम करता है

ये कुंजियाँ अक्षमित (asymmetric) होती हैं। सार्वजनिक कुंजी (id_ed25519.pub) किसी को भी दिखाई जा सकती है, उससे निजी कुंजी दोबारा नहीं बनती। निजी कुंजी (id_ed25519) आपकी मशीन से कभी बाहर नहीं जाती और नेटवर्क पर नहीं भेजी जाती।

लॉगिन के समय क्लाइंट बताता है कि वह किस कुंजी से आना चाहता है। सर्वर यूज़र की ~/.ssh/authorized_keys फ़ाइल में वह सार्वजनिक कुंजी खोजता है, और मिलने पर क्लाइंट से सेशन के डेटा पर निजी कुंजी से हस्ताक्षर माँगता है। हस्ताक्षर सार्वजनिक कुंजी से जाँचा जाता है, और लॉगिन मंज़ूर होता है। इस पूरी प्रक्रिया में पासवर्ड कहीं नहीं भेजा जाता।

चरण 1. कुंजी बनाएँ: ssh-keygen

अपने कंप्यूटर पर (Linux, macOS या Windows 10/11 जिसमें OpenSSH है) चलाएँ:

ssh-keygen -t ed25519 -C "alena@laptop"

-t एल्गोरिदम तय करता है, और -C टिप्पणी, जो सार्वजनिक कुंजी के आख़िर में जुड़ती है और बाद में यह पहचानने में मदद करती है कि कुंजी किसकी है। Ed25519 आज का अनुशंसित एल्गोरिदम है: कुंजियाँ छोटी, तेज़ और भरोसेमंद हैं। अगर सर्वर बहुत पुराना है और Ed25519 सपोर्ट नहीं करता, तो कम से कम 3072 बिट वाली RSA लें: ssh-keygen -t rsa -b 4096।

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alena/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alena/.ssh/id_ed25519
Your public key has been saved in /home/alena/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Xq3v0m6c1y2pVv8m3N0uYv9yQm0e6dFv5gH2rZt1aBc alena@laptop

पासफ़्रेज़ चाहिए या नहीं

पासफ़्रेज़ निजी कुंजी को डिस्क पर एन्क्रिप्ट करता है। अगर लैपटॉप चोरी हो जाए या फ़ाइल लीक हो जाए, तो बिना पासफ़्रेज़ के कुंजी बेकार है। निजी उपयोग की कुंजी पर पासफ़्रेज़ ज़रूर लगाएँ, और हर कनेक्शन पर उसे दोबारा डालने से बचने के लिए ssh-agent इस्तेमाल करें: यह सेशन भर के लिए खुली कुंजी मेमोरी में रखता है।

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l      # लोड की गई कुंजियों की सूची

बिना पासफ़्रेज़ की कुंजियाँ स्वचालन के लिए ठीक हैं, जैसे CI या बैकअप स्क्रिप्ट। ऐसी कुंजी को सर्वर पर सीमित करना बेहतर है (इस पर आगे)।

चरण 2. सार्वजनिक कुंजी सर्वर पर भेजें: ssh-copy-id

सबसे आसान तरीक़ा ssh-copy-id है। यह पासवर्ड से एक आख़िरी बार जुड़ता है, आपकी सार्वजनिक कुंजी सर्वर की ~/.ssh/authorized_keys में जोड़ता है और सही अधिकार सेट करता है।

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/alena/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
deploy@203.0.113.10's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'deploy@203.0.113.10'"
and check to make sure that only the key(s) you wanted were added.

अगर सर्वर किसी गैर-मानक पोर्ट पर है, तो -p 2222 जोड़ें।

अगर ssh-copy-id उपलब्ध नहीं है

Windows में ssh-copy-id नहीं होता। कुंजी एक कमांड से हाथ से भेजी जा सकती है:

cat ~/.ssh/id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

क्लाउड प्रदाता अक्सर सर्वर बनाते समय ही सार्वजनिक कुंजी पूछ लेते हैं, और वह cloud-init के ज़रिए authorized_keys में पहुँच जाती है।

चरण 3. लॉगिन जाँचें

ssh deploy@203.0.113.10

अगर पासवर्ड अब नहीं माँगा जाता (या केवल कुंजी का पासफ़्रेज़ माँगा जाता है), तो सब ठीक है। नए सर्वर से पहली बार जुड़ने पर SSH होस्ट कुंजी का फ़िंगरप्रिंट दिखाता है और पूछता है कि क्या उस पर भरोसा है। yes कहने पर फ़िंगरप्रिंट ~/.ssh/known_hosts में सेव हो जाता है, और आगे अगर सर्वर की कुंजी बदलेगी तो SSH चेतावनी देगा।

यह देखने के लिए कि क्लाइंट कौन-सी कुंजियाँ आज़मा रहा है और सर्वर क्यों मना कर रहा है, कनेक्शन विस्तार से चलाएँ:

ssh -v deploy@203.0.113.10

~/.ssh/config: सर्वर के छोटे नाम

जब सर्वर कई हों, तो हर बार यूज़र, IP, पोर्ट और कुंजी का पाथ लिखना थकाऊ है। यह सब ~/.ssh/config में लिखा जाता है:

Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host bastion
    HostName bastion.example.com
    User alena

Host db-internal
    HostName 10.0.0.15
    User admin
    ProxyJump bastion

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

अब ssh prod काफ़ी है, और scp, rsync व Git भी ये नाम समझते हैं: rsync -av ./site/ prod:/var/www/।

• IdentitiesOnly yes — केवल बताई गई कुंजी इस्तेमाल करना। इसके बिना क्लाइंट एजेंट की सभी कुंजियाँ आज़माता है, और सर्वर कोशिशों की सीमा पूरी होने पर सही कुंजी तक पहुँचने से पहले ही कनेक्शन बंद कर सकता है।
• ProxyJump — एक कमांड से बीच के सर्वर (बैस्टियन) के ज़रिए अंदरूनी सर्वर से जुड़ना।
• ServerAliveInterval — हर 60 सेकंड में «पिंग» भेजना, ताकि निष्क्रियता में कनेक्शन न टूटे।

फ़ाइल के अधिकार 600 होने चाहिए, वरना SSH उसे पढ़ने से मना कर सकता है: chmod 600 ~/.ssh/config।

Agent forwarding: कब चाहिए और क्यों खतरनाक है

कभी-कभी सर्वर से आगे और कनेक्ट करना पड़ता है, जैसे किसी निजी रिपॉज़िटरी से git pull। निजी कुंजी वहाँ कॉपी करना ठीक नहीं है। इसके बजाय ssh -A या ForwardAgent yes इस्तेमाल होता है: सर्वर को सेशन भर के लिए आपके एजेंट तक पहुँच मिलती है। पर उस सर्वर पर जिस किसी के पास root है, वह भी कनेक्शन के दौरान एजेंट का इस्तेमाल कर सकता है। इसलिए फ़ॉरवर्डिंग केवल भरोसेमंद होस्ट पर चालू करें, और बीच के सर्वर से गुज़रने के लिए ProxyJump लें: वह एजेंट नहीं खोलता।

चरण 4. पासवर्ड लॉगिन बंद करें

जब तक पासवर्ड से लॉगिन चालू है, सर्वर ब्रूट-फ़ोर्स का निशाना बना रहता है। जब आप पक्का कर लें कि कुंजी से लॉगिन होता है, तब पासवर्ड बंद करें। ज़रूरी: जब तक नई विंडो में लॉगिन की जाँच न हो जाए, मौजूदा सेशन बंद न करें, वरना पहुँच खो सकती है।

/etc/ssh/sshd_config खोलें (या अगर मुख्य कॉन्फ़िग Include से /etc/ssh/sshd_config.d/ जोड़ता है, तो वहाँ फ़ाइल बनाएँ) और लिखें:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

PermitRootLogin no root से लॉगिन पूरी तरह रोकता है: एडमिनिस्ट्रेटर अपने यूज़र से लॉगिन करते हैं और sudo से अधिकार बढ़ाते हैं। अगर root के बिना काम नहीं चलता, तो PermitRootLogin prohibit-password लें, जिसमें root केवल कुंजी से आ सकता है।

सिंटैक्स जाँचें और सर्विस को दोबारा लोड करें:

sudo sshd -t
sudo systemctl reload ssh      # Debian/Ubuntu में; RHEL जैसे सिस्टम में — sshd

अगर कॉन्फ़िग सही है, तो sshd -t कुछ नहीं कहता। अब नई विंडो में जाँचें कि कुंजी से लॉगिन चलता है, और पासवर्ड से सर्वर मना करता है:

$ ssh -o PubkeyAuthentication=no deploy@203.0.113.10
deploy@203.0.113.10: Permission denied (publickey).

अतिरिक्त सुरक्षा

पासवर्ड बंद करना सबसे मुख्य उपाय है। इसके बाद आम तौर पर पोर्ट 22 को फ़ायरवॉल से सीमित किया जाता है (ufw allow from 198.51.100.0/24 to any port 22) और fail2ban लगाया जाता है, जो कई विफल कोशिशों के बाद IP को ब्लॉक कर देता है। SSH की सुरक्षा की स्थिति sudo fail2ban-client status sshd दिखाता है।

स्वचालन की कुंजी को authorized_keys में कुंजी से पहले विकल्पों से सीमित किया जा सकता है: उदाहरण के लिए from="198.51.100.7",no-port-forwarding,no-pty ssh-ed25519 AAAA... backup केवल एक पते से और बिना इंटरैक्टिव शेल के लॉगिन की अनुमति देता है।

आम गलतियाँ और उनके हल

Permission denied (publickey)

यह सबसे आम गलती है। कारण, सबसे आम से दुर्लभ तक:

1. सर्वर पर गलत अधिकार। sshd authorized_keys को नज़रअंदाज़ करता है, अगर डायरेक्टरी या फ़ाइल दूसरों के लिए लिखने योग्य है। हल: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, और होम डायरेक्टरी ग्रुप या बाक़ी लोगों के लिए लिखने योग्य न हो।
2. गलत मालिक। अगर फ़ाइलें sudo से बनाई गईं, तो वे root की हैं। हल: sudo chown -R deploy:deploy /home/deploy/.ssh।
3. कुंजी गलत यूज़र के लिए। आपने कुंजी root के लिए कॉपी की, और लॉगिन deploy से कर रहे हैं, या उलटा।
4. क्लाइंट गलत कुंजी भेज रहा है। ssh -v देखें: Offering public key लाइनों में दिखता है कि कौन-सी कुंजियाँ आज़माई जा रही हैं। सही कुंजी -i या IdentityFile से दें।
5. कॉपी में कुंजी ख़राब हुई। सार्वजनिक कुंजी एक ही लाइन में होनी चाहिए। क्लिपबोर्ड से कॉपी करते समय आई नई लाइन उसे तोड़ देती है।

सर्वर की तरफ़ का कारण लॉग बताता है: sudo journalctl -u ssh -n 30 (RHEL में -u sshd)। वहाँ ऐसी लाइनें मिलती हैं: Authentication refused: bad ownership or modes for directory /home/deploy/.ssh।

UNPROTECTED PRIVATE KEY FILE

क्लाइंट ऐसी निजी कुंजी इस्तेमाल करने से मना करता है, जिसे दूसरे यूज़र पढ़ सकते हैं। हल: chmod 600 ~/.ssh/id_ed25519।

REMOTE HOST IDENTIFICATION HAS CHANGED

होस्ट की कुंजी known_hosts में सेव की गई कुंजी से मेल नहीं खाती। यह सर्वर दोबारा इंस्टॉल करने या IP बदलने के बाद होता है, लेकिन यही संदेश «बीच में बैठे व्यक्ति» वाले हमले में भी दिखता है। पक्का करें कि सर्वर सच में दोबारा बनाया गया था, फिर पुरानी प्रविष्टि हटाएँ: ssh-keygen -R 203.0.113.10।

Too many authentication failures

एजेंट ने सर्वर को बहुत सारी कुंजियाँ भेज दीं, और सर्वर ने MaxAuthTries की सीमा पर कनेक्शन बंद कर दिया। हल: ~/.ssh/config में IdentitiesOnly yes और साफ़ IdentityFile।

निष्कर्ष

SSH कीज़ का सेटअप पाँच मिनट का काम है: ssh-keygen -t ed25519, ssh-copy-id, लॉगिन की जाँच, फिर PasswordAuthentication no और दूसरी खुली सेशन के साथ sshd को लोड करना। ~/.ssh/config लंबी कमांड से बचाता है, और 700/600 के अधिकार «Permission denied» की ज़्यादातर गलतियाँ सुलझा देते हैं। SSH, rsync और सर्वर की फ़ायरवॉल व fail2ban से सुरक्षा हमारे लिनक्स कोर्स में व्यवहार में सिखाई जाती है।