SSH key व्यवस्थापन कसे करावे?

SSH keys कसे काम करतात

SSH key ही दोन फाइल्सची जोडी आहे: एक private key जी तुमच्या डिव्हाइसवर राहते आणि एक public key जी तुम्ही लॉग इन करू इच्छिण्यातील प्रत्येक सर्व्हरवर कॉपी करता. जेव्हा तुम्ही कनेक्ट होता, तेव्हा सर्व्हर public key चा वापर करून एक challenge पाठवतो, ज्याचे उत्तर फक्त संबंधित private key देऊ शकते. private key कधीही तुमच्या डिव्हाइसबाहेर जात नाही, त्यामुळे नेटवर्कवर कोणतीही गुप्त माहिती पाठवली जात नाही आणि सर्व्हर हॅक झाला तरी चोरूण्यासारखे काहीच नसते. म्हणूनच keys पासवर्डपेक्षा सरस आहेत. SSH keys चे योग्य व्यवस्थापन करण्यासाठी चार सवयी महत्त्वाच्या आहेत: प्रत्येक डिव्हाइससाठी एक key, sshd ने आवश्यक केलेली file permissions, वारंवार options टाईप करणे टाळण्यासाठी ~/.ssh/config फाईल, आणि लॅपटॉप हरवल्यास की (key) कशी काढून टाकायची याचे ज्ञान.

हा मार्गदर्शक (guide) Ubuntu 24.04 वर आधारित आहे, परंतु येथे दिलेली माहिती जवळजवळ सर्व Linux सर्व्हर आणि कोणत्याही नवीन OpenSSH वर लागू होते.

सुरुवात करण्यापूर्वी एक तांत्रिक स्पष्टीकरण, जेणेकरून चुका टाळता येतील. public key ही गुप्त नसते. तुम्ही ती ticket मध्ये पेस्ट करू शकता, ईमेलद्वारे पाठवू शकता किंवा प्रसिद्ध (publish) करू शकता, तरीही कोणीही तिचा वापर करून लॉग इन करू शकत नाही. private key ही गुप्त असते. ज्याच्याकडे ती फाईल आणि तिची passphrase असेल, तो तुमच्या सर्व्हरसाठी तुम्हीच आहात.

की (key) तयार करा: ed25519 हा योग्य default पर्याय आहे

तुमच्या स्वतःच्या संगणकावर (सर्व्हरवर नाही), हे रन करा:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 द्वारे की प्रकार (key type) निवडला जातो. Ed25519 हा आधुनिक default पर्याय आहे: या कीज लहान आणि वेगवान असतात, तसेच 2014 पासूनच्या प्रत्येक OpenSSH रिलीजमध्ये याला सपोर्ट आहे. जर तुम्हाला ed25519 न समजणाऱ्या जुन्या डिव्हाइसशी संपर्क साधायचा असेल, तरच ssh-keygen -t rsa -b 4096 वापरा. -C "laptop" द्वारे कमेंट (comment) सेट केली जाते. कमेंटमुळे क्रिप्टोग्राफीवर कोणताही परिणाम होत नाही, परंतु दोन वर्षांनंतर सर्व्हरच्या authorized_keys फाईलमध्ये ही की ओळखण्यासाठी याचा उपयोग होतो, म्हणून की ज्या डिव्हाइसवर आहे त्याचे नाव द्या.

ssh-keygen की कुठे सेव्ह करायची हे विचारते. डिफॉल्ट, ~/.ssh/id_ed25519 स्वीकार करा. त्यानंतर ते passphrase विचारते. एक passphrase सेट करा; खालील passphrase विभाग स्पष्ट करतो की यामुळे दैनंदिन कामात कोणताही अडथळा येत नाही. शेवटी तुमच्याकडे दोन फाईल्स तयार होतील: ~/.ssh/id_ed25519 ही private key आहे, आणि ~/.ssh/id_ed25519.pub ही public key आहे. public भाग तपासा:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

ही एक ओळ आहे: की प्रकार, की मटेरियल आणि तुमची कमेंट. हीच ओळ तुमच्या सर्व्हरवर सेव्ह केली जाते.

प्रत्येक डिव्हाइससाठी एक की, सर्व्हरसाठी एक नाही

सर्वात पहिला प्रश्न: मला प्रत्येक सर्व्हरसाठी नवीन की लागेल का? नाही. तुम्ही ज्या प्रत्येक डिव्हाइसवर टाइप करता, त्यासाठी एक की तयार करा आणि त्या डिव्हाइसची पब्लिक की ज्या सर्व्हरला पोहोचण्याची गरज आहे, त्या सर्व सर्व्हर्सवर ठेवा. ही की त्या डिव्हाइसची ओळख पटवते. प्रत्येक सर्व्हरवरील authorized_keys फाईल ही प्रवेशासाठी परवानगी असलेल्या डिव्हाइसेसची यादी असते.

हे मॉडेल स्केलेबल आहे, तर इतर पर्याय ठराविक कारणांमुळे अपयशी ठरतात. 'एका सर्व्हरसाठी एक की' (one key per server) मॉडेलमध्ये, ज्या लॅपटॉपला 20 सर्व्हर्सना ॲक्सेस करायचा आहे, त्या लॅपटॉपमध्ये 20 प्रायव्हेट की असतील आणि कोणत्या की कशासाठी आहे याचा मागोवा घेणे कठीण होईल. सर्व डिव्हाइसेससाठी एकच की वापरणे अधिक धोकादायक आहे: जर लॅपटॉप चोरीला गेला, तर तुम्ही लॅपटॉपचा ॲक्सेस रद्द करू शकत नाही, कारण डेस्कटॉपला देखील लॉक करावे लागेल; कारण दोन्हीकडे एकच प्रायव्हेट की असते. त्यामुळे तुम्हाला सर्व ठिकाणी की बदलावी लागेल आणि एकाच वेळी सर्व डिव्हाइसेसवर ती पुन्हा वितरित करावी लागेल.

'एका डिव्हाइससाठी एक की' (one key per device) मॉडेलमध्ये, हरवलेला लॅपटॉप फक्त सर्व्हरवरील एक ओळ खर्च करतो: authorized_keys मधून लॅपटॉपची ओळ काढून टाका, आणि इतर सर्व डिव्हाइसेस काम करत राहतील. -C वापरून तुम्ही दिलेली कमेंट ती ओळ शोधणे सोपे करते.

या मॉडेलचे नियम: प्रायव्हेट की डिव्हाइसवर तयार केली जाते आणि त्या डिव्हाइससोबतच संपते. प्रायव्हेट की कधीही दुसऱ्या मशीनवर कॉपी करू नका आणि ती कधीही सर्व्हरवर अपलोड करू नका. जेव्हा नवीन डिव्हाइसला ॲक्सेसची गरज असेल, तेव्हा त्यावर नवीन की जनरेट करा.

सार्वजनिक की (public key) सर्व्हरवर ठेवा

सर्वात सोपा मार्ग ssh-copy-id आहे, जो OpenSSH सोबत येतो:

ssh-copy-id matt@10.0.0.10

हे सध्या कार्यरत असलेल्या पद्धतीने (सहसा पासवर्ड वापरून) लॉग इन करते, तुमची public key सर्व्हरवरील ~/.ssh/authorized_keys मध्ये जोडते, आणि जर आवश्यक डिरेक्टरी किंवा फाईल नसेल, तर योग्य permissions सह त्या तयार करते. नवीन SSH session उघडून याची चाचणी घ्या: सर्व्हरने खाते पासवर्ड न विचारता तुम्हाला प्रवेश दिला पाहिजे. जर तुमच्या की ला passphrase असेल, तर तुमचे स्वतःचे मशीन त्याबद्दल विचारू शकते; तो प्रॉम्प्ट स्थानिक (local) असतो आणि तो सर्व्हरचा पासवर्ड नसतो.

जेव्हा password login आधीच अक्षम (disabled) केलेले असते, तेव्हा ssh-copy-id लॉग इन करू शकत नाही, म्हणून तुम्हाला ही ओळ मॅन्युअली जोडावी लागेल. सध्या कार्यरत असलेल्या session द्वारे किंवा तुमच्या प्रोव्हायडरच्या web console द्वारे लॉग इन करा आणि सर्व्हरवर हे चालवा:

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

अवतरण चिन्हांच्या (quotes) मध्ये तुमची खरी public key पेस्ट करा, जी id_ed25519.pub मधून घेतलेली पूर्ण सिंगल लाईन आहे. authorized_keys मध्ये प्रति ओळ एक public key असते आणि तीच संपूर्ण access database आहे: नवीन डिव्हाइस जोडणे म्हणजे एक ओळ जोडणे, आणि डिव्हाइस काढून टाकणे म्हणजे एक ओळ हटवणे. नवीन सर्व्हरवर, ही पायरी नवीन VPS वरील पहिल्या 10 मिनिटांमध्ये येते, password login बंद करण्यापूर्वी.

key login मध्ये अडथळा आणणारे permissions

key login अयशस्वी होण्याचे हे सर्वात सामान्य कारण आहे आणि client कडून हे शांतपणे (silently) घडते. Ubuntu 24.04 वर sshd बाय डिफॉल्ट StrictModes yes सह चालते, याचा अर्थ इतर युजर्स एडिट करू शकतील अशा authorized_keys फाईलचा वापर करण्यास ते नकार देते. जर फाईल, ~/.ssh डिरेक्टरी किंवा तुमची home directory तुमच्याव्यतिरिक्त इतर कोणीही लिहू (write) शकत असेल, तर sshd तुमची key दुर्लक्षित करते आणि पासवर्ड विचारण्यास सुरुवात करते; client कडून याचे कोणतेही स्पष्टीकरण मिळत नाही. (Ubuntu च्या OpenSSH मध्ये फक्त एकच अपवाद आहे: तुमची स्वतःची private group ज्यामध्ये इतर कोणीही नाही, अशा फाईल 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

यावर उपाय म्हणून, प्रभावित युजर म्हणून सर्व्हरवर दोन permission बदल आणि एक ownership चेक रन करा:

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

लक्षात ठेवण्यासाठी नियम: .ssh डिरेक्टरी वर 700, आणि त्यातील सर्व गोष्टींवर 600. हेच नंबर्स तुमच्या स्वतःच्या कॉम्प्युटरवर देखील लागू होतात, कारण client देखील तपासायला घेते. इतर युजर्सना readable असलेल्या 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: पर्याय टाईप करणे थांबवा

तुमच्या स्वतःच्या संगणकावरील ~/.ssh/config फाईल प्रत्येक सर्व्हरला एक लहान नाव देते आणि तुम्ही वारंवार टाईप केलेले पर्याय लक्षात ठेवते. ही फाईल 600 permissions सह तयार करा आणि प्रत्येक सर्व्हरसाठी 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 बद्दल माहिती असणे आवश्यक आहे, कारण ते एक गोंधळ निर्माण करणारी त्रुटी सुधारते. जेव्हा तुमच्या agent कडे अनेक keys असतात, तेव्हा client ते एक एक करून सादर करतो, आणि सर्व्हर प्रत्येक प्रयोगाला अयशस्वी प्रयत्न मानतो. पुरेसे keys लोड असल्यास, योग्य key वापरण्यापूर्वीच तुम्हाला Received disconnect: Too many authentication failures प्राप्त होतो. IdentitiesOnly yes मुळे client फक्त IdentityFile मध्ये दिलेली key सादर करतो, ज्यामुळे ही त्रुटी येऊ शकत नाही.

Passphrases आणि ssh-agent

Passphrase मुळे डिस्कवरील private key फाईल एन्क्रिप्ट होते. Passphrase शिवाय, फाईल कॉपी करणारी कोणीही व्यक्ती तिचा लगेच वापर करू शकते; Passphrase असल्यास, तो चोरलेला फाईल जोपर्यंत passphrase ओळखला जात नाही तोपर्यंत निरुपयोगी ठरतो. लॅपटॉपवरील की साठी, हीच नेमकी सुरक्षा आवश्यक आहे, कारण लॅपटॉप चोरीला जाऊ शकतात आणि लॅपटॉपचे backups लीक होऊ शकतात.

ssh-agent मुळे प्रत्यक्ष वापरामध्ये passphrase साठी कोणताही अतिरिक्त खर्च येत नाही. Agent तुमची decrypted key मेमरीमध्ये ठेवतो, त्यामुळे तुम्हाला प्रत्येक लॉगिन सेशनसाठी फक्त एकदाच passphrase टाईप करावा लागतो आणि त्यानंतरचे सर्व कनेक्शन त्वरित होतात. बहुतेक desktop Linux distributions आणि macOS मध्ये आधीच agent कार्यरत असतो. तुमची key यामध्ये लोड करण्यासाठी खालील कमांड वापरा:

ssh-add ~/.ssh/id_ed25519

ssh-add -l मध्ये agent कडे सध्या असलेल्या keys ची यादी मिळते. एक खबरदारी: agent forwarding (ssh -A) मुळे तुम्ही कनेक्टेड असताना रिमोट सर्व्हर तुमच्या agent चा वापर पुढील authentication साठी करू शकतो, म्हणून फक्त पूर्ण विश्वास असलेल्या सर्व्हर्ससाठीच हे सक्षम करा आणि डीफॉल्टनुसार ते बंद ठेवा.

Rotating and revoking: the lost laptop drill

साधी SSH key revoke करणे म्हणजे सर्व सर्व्हर्सवरील authorized_keys मधून त्या की ची ओळ काढून टाकणे होय. यामध्ये कोणतीही certificate authority असते किंवा expiry date ची वाट पाहावी लागत नाही. ती ओळ हटवल्याबरोबर, त्या की वापरून होणारे नवीन logins fail होतात.

आता ही प्रक्रिया सराव म्हणून करून पहा, जेव्हा परिस्थिती तातडीची नसेल. एक सर्व्हर निवडा, ~/.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 केलेली device वापरून login करण्याचा प्रयत्न करा आणि तो fail होतोय याची खात्री करा, आणि दुसऱ्या device वरून login अजूनही होतेय याची खात्री करा. एक गोष्ट लक्षात ठेवा: key काढून टाकल्यामुळे आधीपासून सुरू असलेले sessions बंद होत नाहीत, कारण key ची तपासणी फक्त login वेळी केली जाते. जर तुम्ही चोरी झालेली device revoke करत असाल, तर सर्व्हरवरील who देखील तपासा आणि तुम्हाला न ओळखता येणारे सर्व sessions बंद करा.

Rotation ही प्रक्रिया थोड्या वेगळ्या क्रमाने केली जाणारी तीच प्रक्रिया आहे: device वर नवीन key generate करा, ssh-copy-id वापरून ती install करा, नवीन key ने login होतेय याची खात्री करा आणि नंतर जुनी ओळ हटवा. जेव्हा एखादी device दुसऱ्या कोणाकडे जाते, जेव्हा एखादी key expose झाली असावी, किंवा जेव्हा एखादी व्यक्ती टीम सोडते, तेव्हा ही प्रक्रिया करा. दोन सर्व्हर्सवर ही प्रक्रिया मॅन्युअली करणे ठीक आहे; परंतु 20 सर्व्हर्ससाठी automation आवश्यक आहे. managing multiple Linux servers मध्ये संपूर्ण fleet वर एकच authorized_keys state कशी लागू करायची हे दिले आहे.

काय करू नये

• सर्व उपकरणांसाठी (devices) एकाच private key चा वापर करू नका. यामुळे एखादे उपकरण चोरीला गेल्यास, सर्वत्र की बदलल्याशिवाय ती revoke करणे अशक्य होते.

• private key कोणत्याही git repository मध्ये commit करू नका, अगदी ते private असले तरीही. Automated scanners सार्वजनिक repositories वर लक्ष ठेवून असतात आणि push केल्यानंतर काही मिनिटांतच लीक झालेल्या keys शोधण्याचा प्रयत्न करतात; तसेच, एखादे repository नंतर public झाले तर त्याची संपूर्ण history लीक होऊ शकते.

• एका server ला दुसऱ्या server शी जोडण्यासाठी तुमच्या laptop ची private key त्या server वर upload करू नका. त्या server वर स्वतंत्र key तयार करा आणि त्या key ला फक्त आवश्यक तिथेच authorize करा.

• private key कधीही chat, email किंवा ticket मध्ये paste करू नका. फक्त public key, म्हणजेच .pub फाईल, हीच शेअर करण्यासाठी वापरली जाते.

एकदा तुमची key विश्वसनीयपणे log in झाली की, पुढचे पाऊल म्हणून password authentication बंद करा, जेणेकरून तुमच्या server वर होणारे सततचे guessing attempts अयशस्वी होतील. त्यासाठीची drop-in configuration SSH hardening on a VPS मध्ये दिली आहे.

FAQ

पासवर्ड न पाठवता SSH keys कशा प्रकारे काम करतात?

सर्व्हर तुमच्या public key ला ~/.ssh/authorized_keys मध्ये साठवतो. लॉगिन करताना सर्व्हर एक challenge पाठवतो, तुमचा client त्या challenge ला private key ने sign करतो, आणि सर्व्हर public key वापरून त्या signature ची पडताळणी करतो. private key कधीही तुमच्या device मधून बाहेर जात नाही, त्यामुळे ट्रान्झिटमध्ये तो intercept करणे किंवा सर्व्हरवरून तो चोरणे शक्य नसते. जर सर्व्हर हॅक झाला, तर फक्त public keys लीक होऊ शकतात, ज्याचा वापर कोठेही लॉगिन करण्यासाठी करता येत नाही.

मी माझ्या सर्व सर्व्हर्ससाठी एकच SSH key वापरली पाहिजे का?

जर ती key एकाच device वर असेल, तर अनेक सर्व्हर्ससाठी एकच key वापरणे योग्य आहे. नियम असा आहे की प्रत्येक device साठी एक key असावी, प्रत्येक server साठी नाही: तुमच्या laptop ची public key त्या सर्व सर्व्हर्सवर असावी ज्यावर laptop ला प्रवेश हवा आहे, आणि तुमच्या desktop ची स्वतःची वेगळी key असावी. यामुळे revocation (रद्द करणे) सोपे होते, कारण एखादे device गमावल्यास फक्त प्रत्येक server मधून एक ओळ काढून टाकणे आवश्यक असते आणि इतर devices व्यवस्थित काम करत राहतात.

.ssh directory आणि authorized_keys साठी कोणती permissions असावीत?

~/.ssh वर 700 आणि authorized_keys वर 600 सेट करा, तसेच प्रत्येक private key वर देखील हेच असावे. ही सर्व files त्या account च्या मालकीच्या असाव्यात जे ती वापरते. sshd बाय डिफॉल्ट StrictModes yes सह चालते, त्यामुळे जर तुमच्याव्यतिरिक्त इतर कोणालाही एखाद्या file किंवा home directory मध्ये write करण्याची परवानगी असेल, तर sshd तुमची key silently ignore करते. याचा एकमेव पुरावा सर्व्हरच्या auth log किंवा journal मध्ये Authentication refused: bad ownership or modes स्वरूपात आढळतो.

मी सर्व्हरवरून SSH key कशी काढू?

ज्या account साठी ती key authorize केली होती, त्या account च्या ~/.ssh/authorized_keys मधील ती ओळ डिलीट करा. key material नंतर असलेल्या comment (label) द्वारे योग्य ओळ शोधा. त्या key ने केलेले नवीन logins लगेच fail होतील, परंतु आधीपासून सुरू असलेले sessions सुरूच राहतील, त्यामुळे जर device चोरीला गेले असेल, तर त्या device चे सर्व active sessions देखील बंद करा. ज्या सर्व सर्व्हर्सवर ती key कॉपी केली होती, तिथे ही प्रक्रिया पुन्हा करा.

माझ्या SSH key ला passphrase ची गरज आहे का?

Laptop किंवा desktop वरील key साठी, हो. passphrase मुळे key file encrypt होते, ज्यामुळे चोरी केलेली किंवा लीक झालेली copy स्वतःहून निरुपयोगी ठरते. ssh-agent मुळे तुम्हाला प्रत्येक connection ऐवजी फक्त एकदाच passphrase टाईप करावा लागतो. सर्व्हरवर unattended automation साठी वापरल्या जाणाऱ्या keys ला सहसा passphrase नसते, कारण तिथे टाईप करण्यासाठी कोणताही मनुष्य उपलब्ध नसतो; अशा keys सुरक्षित ठेवण्यासाठी target account च्या permissions मर्यादित ठेवा.