SSH keys कैसे मैनेज करें: गाइड और सुरक्षा टिप्स

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

SSH key दो फाइलों का एक जोड़ा होती है: एक private key जो आपके डिवाइस पर रहती है और एक public key जिसे आप हर उस सर्वर पर कॉपी करते हैं जहाँ आप लॉग इन करना चाहते हैं। जब आप कनेक्ट करते हैं, तो सर्वर public key का उपयोग करके एक challenge भेजता है जिसका उत्तर केवल संबंधित private key ही दे सकती है। private key कभी भी आपके डिवाइस से बाहर नहीं जाती, इसलिए नेटवर्क पर कोई secret नहीं भेजा जाता है, और किसी breached सर्वर के पास चुराने के लिए कुछ भी उपयोगी नहीं होता है। यही कारण है कि keys पासवर्ड से बेहतर होती हैं। SSH keys को अच्छी तरह से मैनेज करने के लिए चार आदतें जरूरी हैं: प्रति डिवाइस एक key, sshd द्वारा मांगी गई file permissions, एक ~/.ssh/config फाइल ताकि आपको बार-बार options टाइप न करने पड़ें, और यह जानना कि लैपटॉप खो जाने पर key को कैसे हटाना है।

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

शुरू करने से पहले शब्दावली का एक बिंदु, क्योंकि यह गंभीर गलतियों को रोकता है। public key secret नहीं होती है। आप इसे किसी टिकट में पेस्ट कर सकते हैं, ईमेल द्वारा भेज सकते हैं, या प्रकाशित कर सकते हैं, और कोई भी इसके साथ लॉग इन नहीं कर सकता है। private key ही secret होती है। जो कोई भी उस फाइल को कॉपी कर लेता है, और यदि उसका passphrase है तो उसे भी जान लेता है, तो आपके सर्वर के लिए वह आप ही हैं।

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

अपने कंप्यूटर पर, सर्वर पर नहीं, यह command चलाएँ:

ssh-keygen -t ed25519 -C "laptop"

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

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

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

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

हर सर्वर के लिए नहीं, हर डिवाइस के लिए एक key

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

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

हर डिवाइस के लिए एक key होने पर, खोए हुए लैपटॉप के कारण आपको प्रति सर्वर केवल एक लाइन हटानी पड़ती है: authorized_keys से लैपटॉप की लाइन हटा दें, और बाकी सभी डिवाइस काम करते रहेंगे। -C के साथ जो comment आप सेट करते हैं, उसी से उस लाइन को ढूँढना आसान हो जाता है।

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

सर्वर पर public key डालें

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

ssh-copy-id matt@10.0.0.10

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

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

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

quotes के अंदर अपनी असली public key paste करें, जो id_ed25519.pub की पूरी single line है। authorized_keys में प्रति line एक public key होती है, और यही पूरा access database है: किसी device को जोड़ने का मतलब एक line जोड़ना है, और किसी device का access रद्द करने का मतलब एक line हटाना है। एक नए सर्वर पर, यह चरण नए VPS पर पहले 10 मिनट के दौरान, password login बंद करने से ठीक पहले किया जाना चाहिए।

वे अनुमतियाँ जो key login को विफल करती हैं

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

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

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

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

इसका समाधान दो अनुमतियों में बदलाव और ownership की जाँच है, जिसे सर्वर पर प्रभावित उपयोगकर्ता के रूप में चलाएँ:

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

याद रखने का नियम: .ssh निर्देशिका पर 700, और इसके अंदर की हर चीज़ पर 600। यही संख्याएँ आपके अपने कंप्यूटर पर भी लागू होती हैं, क्योंकि client भी जाँच करता है। अन्य उपयोगकर्ताओं द्वारा पढ़ी जा सकने वाली private key के कारण ssh सीधे key को अस्वीकार कर देता है, और इस बार त्रुटि स्पष्ट होती है:

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

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

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

आपके अपने कंप्यूटर पर मौजूद एक ~/.ssh/config फ़ाइल हर सर्वर को एक छोटा नाम देती है और उन विकल्पों को याद रखती है जिन्हें आप बार-बार टाइप करते हैं। इसे 600 अनुमतियों के साथ बनाएँ और प्रति सर्वर एक Host ब्लॉक जोड़ें:

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 का उपयोग होता है, और वही छोटा नाम scp, rsync, और git में भी काम करता है, क्योंकि वे सभी इस फ़ाइल को पढ़ते हैं। HostName वास्तविक पता है, User आपको अकाउंट का नाम टाइप करने से बचाता है, और IdentityFile यह निर्धारित करता है कि कौन सी की (key) पेश करनी है।

IdentitiesOnly yes एक वाक्य का हकदार है, क्योंकि यह एक भ्रमित करने वाली विफलता को ठीक करता है। जब आपके एजेंट के पास कई कीज़ होती हैं, तो क्लाइंट उन्हें एक-एक करके पेश करता है, और सर्वर हर पेशकश को एक विफल प्रयास के रूप में गिनता है। यदि पर्याप्त कीज़ लोड हैं, तो सही की आज़माने से पहले ही आपको Received disconnect: Too many authentication failures मिल जाता है। IdentitiesOnly yes क्लाइंट को केवल IdentityFile में नामित की पेश करने के लिए मजबूर करता है, जिससे यह विफलता नहीं हो सकती।

Passphrases और ssh-agent

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

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

ssh-add ~/.ssh/id_ed25519

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

की रोटेशन और रिवोकेशन: लैपटॉप खो जाने पर अभ्यास

एक साधारण SSH key को revoke करने का अर्थ केवल हर उस सर्वर से उसकी लाइन को authorized_keys से हटाना है जहाँ वह मौजूद है। इसके लिए किसी certificate authority को सूचित करने या expiry date का इंतज़ार करने की आवश्यकता नहीं होती है। जिस क्षण वह लाइन हट जाती है, उस key के साथ नए logins विफल हो जाते हैं।

अभी इस अभ्यास को करें, जब यह कोई आपातकालीन स्थिति न हो। एक सर्वर चुनें, ~/.ssh/authorized_keys खोलें, और उसकी comment के आधार पर key को ढूँढें। एक editor के साथ उस लाइन को हटा दें, या comment के माध्यम से उसे filter करके निकाल दें:

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

फिर उस डिवाइस से पुष्टि करें जिसे आपने अभी revoke किया है कि login अब विफल हो रहा है, और किसी अन्य डिवाइस से पुष्टि करें कि login अभी भी काम कर रहा है। एक विवरण ध्यान में रखें: key हटाने से पहले से खुले sessions बंद नहीं होते हैं, क्योंकि key की जाँच केवल login के समय की जाती है। यदि आप किसी चोरी हुए डिवाइस को revoke कर रहे हैं, तो सर्वर पर who की भी जाँच करें और किसी भी ऐसे session को समाप्त करें जिसे आप नहीं पहचानते हैं।

रोटेशन एक अलग क्रम में की जाने वाली वही प्रक्रिया है: डिवाइस पर एक नई key generate करें, इसे ssh-copy-id के साथ install करें, पुष्टि करें कि नई key से login हो रहा है, और फिर पुरानी लाइन को हटा दें। ऐसा तब करें जब डिवाइस का मालिक बदले, जब key के उजागर होने की संभावना हो, या जब कोई टीम छोड़े। दो सर्वरों पर इसे मैन्युअल रूप से करना ठीक है; बीस सर्वरों पर यह automation का काम है, और managing multiple Linux servers दिखाता है कि कैसे पूरे fleet में एक ही authorized_keys state को push किया जाए।

क्या न करें

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

• किसी git repository में private key commit न करें, भले ही वह private repository हो। स्वचालित scanners public repositories पर नजर रखते हैं और push के कुछ ही मिनटों के भीतर लीक हुई keys का उपयोग करने का प्रयास करते हैं। यदि भविष्य में repository को public किया जाता है, तो उसका पूरा इतिहास लीक हो जाता है।

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

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

एक बार जब आपकी key आपको विश्वसनीय रूप से login करने देती है, तो अगला कदम उठाएं और password authentication को बंद कर दें। इससे आपके सर्वर पर लगातार होने वाले password guessing के प्रयास पूरी तरह विफल हो जाएंगे। इसके लिए आवश्यक configuration VPS पर SSH hardening में दी गई है।

FAQ

SSH keys बिना पासवर्ड भेजे कैसे काम करती हैं?

सर्वर आपकी public key को ~/.ssh/authorized_keys में रखता है। लॉगिन के समय, सर्वर एक challenge भेजता है, आपका client उस challenge को private key के साथ sign करता है, और सर्वर public key का उपयोग करके उस signature की पुष्टि करता है। private key कभी भी आपके device से बाहर नहीं जाती, इसलिए transit के दौरान intercept करने के लिए कुछ नहीं होता और सर्वर से चुराने के लिए कोई ऐसी चीज़ नहीं होती जिसे दोबारा इस्तेमाल किया जा सके। एक breached सर्वर से केवल public keys लीक होती हैं, जिनका उपयोग कहीं भी लॉगिन करने के लिए नहीं किया जा सकता।

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

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

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

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

मैं सर्वर से SSH key कैसे हटाऊँ?

जिस account के लिए key अधिकृत (authorised) थी, उसके ~/.ssh/authorized_keys से key वाली line को हटा दें। key material के बाद दिए गए comment (label) के आधार पर सही line ढूँढें। उस key के साथ नए लॉगिन तुरंत विफल हो जाएंगे, लेकिन जो sessions पहले से खुले हैं वे खुले रहेंगे, इसलिए यदि device चोरी हो गया था, तो उस device के लिए किसी भी live session को समाप्त कर दें। जिस-जिस सर्वर पर key कॉपी की गई थी, उन सभी पर यही प्रक्रिया दोहराएं।

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

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