SSH keys कैसे manage करें

SSH keys कैसे काम करते हैं

SSH key दो files का एक pair है: एक private key जो आपके device पर रहती है, और एक public key जिसे आप हर उस server पर copy करते हैं जहाँ आप log in करना चाहते हैं। जब आप connect करते हैं, तो server public key का उपयोग करके एक challenge भेजता है जिसे केवल matching private key ही solve कर सकती है। Private key आपके device से कभी बाहर नहीं जाती, इसलिए network पर कोई secret नहीं भेजा जाता। यदि कोई server compromise हो जाता है, तो हमलावर के पास चुराने के लिए कुछ भी उपयोगी नहीं होता। यही कारण है कि keys, passwords से बेहतर हैं। SSH keys को सही ढंग से manage करने के लिए चार आदतें ज़रूरी हैं: प्रति device एक key, sshd द्वारा मांगी गई file permissions, options टाइप करने से बचने के लिए एक ~/.ssh/config file, और laptop खो जाने पर key को तुरंत remove करने का तरीका।

यह guide Ubuntu 24.04 पर इन सभी आदतों को कवर करती है, हालाँकि यहाँ दी गई लगभग सभी बातें किसी भी Linux server और किसी भी recent OpenSSH पर लागू होती हैं।

शुरू करने से पहले शब्दावली (vocabulary) का एक बिंदु, क्योंकि यह बड़ी गलतियों को रोकता है। Public key secret नहीं है। आप इसे किसी ticket में paste कर सकते हैं, email से भेज सकते हैं, या publish कर सकते हैं, और कोई भी इससे log in नहीं कर सकता। Private key ही secret है। यदि कोई उस file को copy कर लेता है, और यदि उसका passphrase है तो उसे जान लेता है, तो आपके servers के लिए वह व्यक्ति आप ही हैं।

एक key बनाएँ: ed25519 सही default है

अपने स्वयं के computer पर, server पर नहीं, इसे चलाएँ:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 key type चुनता है। Ed25519 आधुनिक default है: keys छोटे और fast होते हैं, और 2014 से सभी OpenSSH release द्वारा supported हैं। ssh-keygen -t rsa -b 4096 का उपयोग केवल तभी करें जब आपको किसी पुराने device से connect करना हो जो ed25519 को नहीं समझता। -C "laptop" एक comment सेट करता है। comment का कोई cryptographic कार्य नहीं है, लेकिन दो साल बाद आप server की authorized_keys file में इस key को इसी से पहचानेंगे, इसलिए उस device का नाम लिखें जिस पर यह key है।

ssh-keygen पूछेगा कि key कहाँ save करनी है। default, ~/.ssh/id_ed25519, को स्वीकार करें। इसके बाद यह passphrase मांगेगा। एक passphrase सेट करें; नीचे दिया गया passphrase section समझाता है कि इसके लिए आपको रोज़ाना कोई कीमत नहीं चुकानी पड़ती। अंत में आपके पास दो files होंगी: ~/.ssh/id_ed25519 private key है, और ~/.ssh/id_ed25519.pub public key है। public half को देखें:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

यह एक line है: key type, key material, और आपका comment। यही line आपके servers पर save होगी।

प्रत्येक device के लिए एक key, न कि प्रत्येक server के लिए एक

पहला सवाल जो हर कोई पूछता है: क्या मुझे हर server के लिए एक नई key की आवश्यकता है? नहीं। आप जिस भी device पर टाइप करते हैं, उसके लिए एक key बनाएँ, और उस public key को उन सभी servers पर रखें जहाँ उस device को पहुँचने की आवश्यकता है। यह key device की पहचान करती है। प्रत्येक server पर मौजूद authorized_keys file उन devices की सूची है जिन्हें अनुमति दी गई है।

यह एक scalable मॉडल है, जबकि अन्य विकल्प विफल हो जाते हैं। प्रत्येक server के लिए एक key होने का अर्थ है कि बीस servers वाले laptop में बीस private keys होंगी, और आप भूल जाएंगे कि कौन सी key किसकी है। सभी devices के लिए एक ही key का उपयोग करना और भी खराब है: यदि laptop चोरी हो जाता है, तो आप अपने desktop को लॉक किए बिना laptop की key को revoke नहीं कर सकते, क्योंकि दोनों में एक ही private key है। इसलिए, आपको हर जगह key बदलनी होगी और उसे एक साथ सभी devices पर फिर से वितरित करना होगा।

एक key प्रति device के साथ, खोए हुए laptop का नुकसान केवल प्रत्येक server की एक line के बराबर होगा: authorized_keys से laptop की line को हटा दें, और अन्य सभी devices काम करते रहेंगे। -C के साथ सेट किया गया comment उस line को खोजने में मदद करता है।

इस मॉडल के पीछे का नियम: एक private key device पर बनाई जाती है और उसी device के साथ समाप्त हो जाती है। private key को कभी भी दूसरी machine पर copy न करें, और इसे कभी भी server पर upload न करें। जब किसी नए device को access की आवश्यकता हो, तो उस पर एक नई key generate करें।

Server पर public key डालें

सबसे आसान तरीका ssh-copy-id है, जो OpenSSH के साथ आता है:

ssh-copy-id matt@10.0.0.10

यह उस विधि से login करता है जो अभी भी काम कर रही है (आमतौर पर password), server पर ~/.ssh/authorized_keys में आपकी public key जोड़ देता है, और यदि directory या file मौजूद नहीं हैं, तो उन्हें सही permissions के साथ बना देता है। एक नया SSH session खोलकर इसका परीक्षण करें: server को बिना account password मांगे आपको login करने देना चाहिए। यदि आपकी key में passphrase है, तो आपकी machine उसके लिए पूछ सकती है; वह prompt local होता है और server password नहीं है।

जब password login पहले से ही disabled होता है, तो ssh-copy-id login नहीं कर पाता, इसलिए आपको line मैन्युअल रूप से जोड़नी होगी। उस session के माध्यम से login करें जो अभी भी काम कर रहा है, या अपने provider के web console का उपयोग करें, और server पर यह चलाएँ:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Quotes के अंदर अपनी real public key पेस्ट करें, जो id_ed25519.pub से ली गई पूरी single line है। authorized_keys में प्रति line एक public key होती है, और यही पूरा access database है: किसी device को add करने का अर्थ है एक line जोड़ना, और किसी device को revoke करने का अर्थ है एक line हटाना। एक नए server पर, यह step एक नए VPS पर पहले 10 मिनट के अंतर्गत आता है, password login को off करने से ठीक पहले।

Key login को विफल करने वाली permissions

Key login विफल होने का यह सबसे सामान्य तरीका है, और client side पर यह बिना किसी सूचना के विफल हो जाता है। Ubuntu 24.04 पर sshd डिफ़ॉल्ट रूप से StrictModes yes के साथ चलता है, जिसका अर्थ है कि यह ऐसी authorized_keys file का उपयोग करने से मना कर देता है जिसे अन्य users edit कर सकते हैं। यदि file, ~/.ssh directory, या आपकी home directory को आपके अलावा कोई और write कर सकता है, तो sshd आपकी key को ignore कर देता है और password मांगना शुरू कर देता है, बिना client पर कोई स्पष्टीकरण दिए। (Ubuntu का OpenSSH केवल एक सीमित मामले को स्वीकार करता है: एक file group जिसे केवल आपकी अपनी private group द्वारा write किया जा सकता हो, जिसमें कोई अन्य शामिल न हो। इस पर निर्भर न रहें; नीचे दिए गए modes का पालन करें।) इसका कारण केवल server के log में दिखाई देता है:

sudo grep 'Authentication refused' /var/log/auth.log

rsyslog के बिना minimal image में auth.log नहीं होता है; वही line journal में होती है: sudo journalctl -u ssh | grep 'Authentication refused'।

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

इसका समाधान दो permission changes और एक ownership check है, जिसे server पर प्रभावित user के रूप में चलाएं:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

याद रखने योग्य नियम: .ssh directory पर 700, और उसके अंदर की सभी चीज़ों पर 600। यही numbers आपके अपने computer पर भी लागू होते हैं, क्योंकि client भी इसकी जाँच करता है। यदि कोई private key अन्य users द्वारा readable है, तो ssh उस key को सीधे अस्वीकार कर देता है, और इस बार error स्पष्ट रूप से दिखाई देता है:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 इसे ठीक करता है।

~/.ssh/config: options टाइप करना बंद करें

आपके अपने computer पर एक ~/.ssh/config file हर server को एक छोटा name देती है और आपके द्वारा बार-बार टाइप किए जाने वाले options को याद रखती है। इसे 600 permissions के साथ बनाएँ और प्रत्येक server के लिए एक Host block जोड़ें:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

अब ssh web1, ssh -p 22 matt@10.0.0.10 की जगह ले लेता है, और वही छोटा name scp, rsync, और git में भी काम करता है, क्योंकि वे सभी इस file को पढ़ते हैं। HostName असली address है, User आपको account name टाइप करने से बचाता है, और IdentityFile यह तय करता है कि कौन सी key इस्तेमाल करनी है।

IdentitiesOnly yes का उल्लेख करना ज़रूरी है, क्योंकि यह एक भ्रमित करने वाली failure को ठीक करता है। जब आपके agent के पास कई keys होती हैं, तो client उन्हें एक-एक करके पेश करता है, और server हर offer को एक failed attempt मानता है। यदि बहुत सारी keys loaded हैं, तो सही key के इस्तेमाल होने से पहले ही आपको Received disconnect: Too many authentication failures मिल जाएगा। IdentitiesOnly yes client को केवल वही key पेश करने के लिए मजबूर करता है जिसका name IdentityFile में दिया गया है, जिससे failure नहीं होता।

Passphrases और ssh-agent

Passphrase डिस्क पर मौजूद private key file को encrypt करता है। इसके बिना, कोई भी जो उस file को कॉपी करता है, वह तुरंत उसका उपयोग कर सकता है; passphrase होने पर, चोरी की गई file तब तक बेकार रहती है जब तक passphrase का अनुमान न लगा लिया जाए। Laptop पर मौजूद key के लिए, आपको ठीक इसी तरह के protection की आवश्यकता होती है, क्योंकि laptops चोरी हो जाते हैं और उनके backups leak हो जाते हैं।

व्यावहारिक रूप से passphrase का कोई खर्च न होने का कारण ssh-agent है। Agent आपकी decrypted key को memory में रखता है, इसलिए आपको प्रति login session केवल एक बार passphrase टाइप करना होता है और उसके बाद के सभी connections instant होते हैं। अधिकांश desktop Linux distributions और macOS पहले से ही आपके लिए एक agent चलाते हैं। अपनी key को इसमें load करने के लिए उपयोग करें:

ssh-add ~/.ssh/id_ed25519

ssh-add -l उन keys की सूची देता है जिन्हें agent वर्तमान में hold करता है। एक सावधानी: agent forwarding (ssh -A) remote server को आपके agent का उपयोग करके आगे authenticate करने की अनुमति देता है जब आप connected होते हैं, इसलिए इसे केवल उन्हीं servers के लिए enable करें जिन पर आप पूरी तरह भरोसा करते हैं, और इसे default में off रखें।

Rotating and revoking: the lost laptop drill

Ek plain SSH key ko revoke karne ka matlab hai uski line ko har us server se hata dena jahan authorized_keys mein wo मौजूद hai. Isme kisi certificate authority ko notify karne ki ya expiry date ka intezar karne ki zaroorat nahi hoti. Jaise hi wo line hat jati hai, us key ke saath naye logins fail ho jate hain.

Is drill ko abhi karein, jab tak koi emergency na ho. Ek server chunein, ~/.ssh/authorized_keys kholein, aur comment ke zariye key ko dhundhein. Editor ka upyog karke line ko delete karein, ya comment ke zariye use filter karein:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

Iske baad, jis device ko aapne revoke kiya hai usse confirm karein ki login fail ho raha hai, aur kisi dusre device se confirm karein ki login abhi bhi kaam kar raha hai. Ek baat ka dhyan rakhein: key hatane se pehle se open sessions band nahi hote, kyunki key ki checking sirf login ke samay hoti hai. Agar aap kisi chori hue device ko revoke kar rahe hain, to server par who bhi check karein aur kisi bhi anjaan session ko end kar dein.

Rotation wahi operation hai lekin alag order mein: device par ek nayi key generate karein, use ssh-copy-id ke saath install karein, confirm karein ki nayi key se login ho raha hai, aur phir purani line ko delete kar dein. Ise tab karein jab koi device badla jaye, jab kisi key ke expose hone ka khatra ho, ya jab koi team chhod kar jaye. Do servers par ise manually karna theek hai; lekin bees servers ke liye automation ki zaroorat hogi, aur managing multiple Linux servers batata hai ki kaise poore fleet par ek hi authorized_keys state ko push kiya jata hai.

क्या न करें

• एक ही private key का उपयोग अपने सभी devices पर न करें। यदि कोई एक device चोरी हो जाता है, तो key को हर जगह से बदलना पड़ेगा क्योंकि उसे revoke करना असंभव हो जाएगा।

• Private key को git repository में commit न करें, चाहे वह private ही क्यों न हो। Automated scanners public repositories पर नज़र रखते हैं और push करने के कुछ ही मिनटों में leaked keys को आज़माते हैं। यदि कोई repository बाद में public की जाती है, तो उसकी पूरी history leak हो जाती है।

• एक server तक पहुँचने के लिए अपने laptop की private key को server पर upload न करें। Server पर एक अलग key generate करें, और उस key को केवल वहीं authorise करें जहाँ उसकी आवश्यकता है।

• Private key को chat, email, या ticket में paste न करें। केवल public key, यानी .pub file, ही साझा की जानी चाहिए।

जब आपकी key आपको reliably log in करने दे, तब अगला कदम उठाएं और password authentication को बंद कर दें। इससे server पर होने वाले constant guessing attacks विफल हो जाएंगे। इसके लिए drop-in configuration SSH hardening on a VPS में उपलब्ध है।

FAQ

SSH keys बिना password भेजे कैसे काम करते हैं?

Server आपके public key को ~/.ssh/authorized_keys में सुरक्षित रखता है। Login के समय server एक challenge भेजता है, आपका client private key के साथ उस challenge को sign करता है, और server public key के माध्यम से signature को verify करता है। Private key आपके device से कभी बाहर नहीं जाती, इसलिए transit में इसे intercept करना संभव नहीं है और server से इसे चुराना भी मुमकिन नहीं है। यदि server breach हो जाता है, तो केवल public keys ही लीक होती हैं, जिनका उपयोग कहीं और login करने के लिए नहीं किया जा सकता।

क्या मुझे अपने सभी servers के लिए एक ही SSH key का उपयोग करना चाहिए?

यदि वह key केवल एक ही device तक सीमित है, तो कई servers के लिए एक ही key का उपयोग करना सही है। नियम यह है: प्रति device एक key, न कि प्रति server एक key। आपके laptop की public key उन सभी servers पर होनी चाहिए जहाँ laptop का उपयोग करना हो, और आपके desktop की अपनी अलग key होनी चाहिए। इससे revocation (निरस्तीकरण) सरल हो जाता है, क्योंकि किसी device के खो जाने पर आपको केवल प्रत्येक server से एक line हटानी होती है, और अन्य devices काम करते रहते हैं।

.ssh directory और authorized_keys की permissions क्या होनी चाहिए?

~/.ssh पर 700 और authorized_keys पर 600 set करें। इसके अलावा, प्रत्येक private key पर भी यही permissions होनी चाहिए, और इनका owner वही account होना चाहिए जो इनका उपयोग करता है। sshd डिफ़ॉल्ट रूप से StrictModes yes के साथ चलता है, इसलिए यदि आपके अलावा कोई और भी file या home directory में write कर सकता है, तो sshd आपकी key को silently ignore कर देगा। इसका एकमात्र प्रमाण server के auth log या journal में Authentication refused: bad ownership or modes होगा।

मैं server से SSH key कैसे हटाऊं?

जिस account के लिए key authorize की गई थी, उसके ~/.ssh/authorized_keys से key वाली line को delete कर दें। सही line को उसके comment (key material के बाद वाला label) से पहचानें। उस key के साथ नए logins तुरंत fail हो जाएंगे, लेकिन पहले से खुले हुए sessions खुले रहेंगे। यदि device चोरी हो गया है, तो उस device के सभी active sessions को भी बंद कर दें। इस प्रक्रिया को उन सभी servers पर दोहराएं जहाँ वह key copy की गई थी।

क्या मुझे अपनी SSH key पर passphrase की आवश्यकता है?

Laptop या desktop पर मौजूद key के लिए, हाँ। Passphrase key file को encrypt करता है, जिससे चोरी की गई या लीक हुई copy अपने आप में बेकार हो जाती है। ssh-agent का अर्थ है कि आपको हर connection के बजाय प्रति session केवल एक बार इसे टाइप करना होगा। Server पर unattended automation द्वारा उपयोग की जाने वाली keys में आमतौर पर कोई passphrase नहीं होती है, क्योंकि वहां टाइप करने के लिए कोई इंसान मौजूद नहीं होता; उन्हें उस target account की permissions को restrict करके सुरक्षित रखें।