SSH key management: मूलभूत नियम आणि सुरक्षित वापर

SSH keys कशा कार्य करतात

SSH key ही दोन फाइल्सची जोडी असते: private key तुमच्या device वरच राहते आणि ज्या प्रत्येक server वर तुम्हाला login करायचे आहे, त्या server वर तुम्ही public key कॉपी करता. तुम्ही connect झाल्यावर server public key वापरून challenge पाठवतो. त्याचे उत्तर फक्त संबंधित private key देऊ शकते. private key तुमच्या device वरून कधीही बाहेर जात नाही. त्यामुळे कोणतेही secret network वरून पाठवले जात नाही आणि breached server कडून चोरण्यासारखे उपयुक्त काहीही मिळत नाही. म्हणूनच keys passwords पेक्षा अधिक सुरक्षित असतात. SSH keys व्यवस्थित manage करण्यासाठी चार सवयी महत्त्वाच्या आहेत: प्रत्येक device साठी एक key, sshd ला आवश्यक असलेल्या file permissions, options वारंवार टाइप करणे थांबवण्यासाठी एक ~/.ssh/config file, आणि laptop हरवल्याच्या दिवशी key कशी काढायची याची माहिती.

हे guide Ubuntu 24.04 वरील प्रत्येक सवय स्पष्ट करते. मात्र येथे दिलेल्या जवळपास सर्व सूचना कोणत्याही Linux server आणि अलीकडील OpenSSH वर लागू होतात.

सुरुवात करण्यापूर्वी एक शब्दप्रयोग स्पष्ट करूया. त्यामुळे प्रत्यक्ष चुका टाळता येतात. public key secret नसते. तुम्ही ती ticket मध्ये paste करू शकता, email ने पाठवू शकता किंवा publish करू शकता. तिच्या आधारे कोणीही login करू शकत नाही. private key हे secret असते. ज्याच्याकडे त्या file ची कॉपी आहे आणि ती protected असल्यास तिचा passphrase माहीत आहे, तो तुमच्या servers च्या दृष्टीने तुम्हीच आहे.

की तयार करा: ed25519 हा योग्य default आहे

तुमच्या स्वतःच्या संगणकावर, सर्व्हरवर नाही, पुढील command चालवा:

ssh-keygen -t ed25519 -C "laptop"

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

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

तो एकाच ओळीत असतो: key type, key material आणि तुमचा comment. हीच ओळ तुमच्या servers वर जोडली जाते.

प्रति device एक key, प्रत्येक server साठी एक नाही

सर्वजण प्रथम हाच प्रश्न विचारतात: प्रत्येक server साठी मला नवीन key आवश्यक आहे का? नाही. तुम्ही ज्या प्रत्येक device वरून टाइप करता, त्या प्रत्येक device साठी एक key तयार करा आणि त्या device ला ज्या प्रत्येक server पर्यंत पोहोचायचे आहे, त्या सर्व server वर तीच public key ठेवा. key ही device ची ओळख पटवते. प्रत्येक server वरील authorized_keys file मध्ये प्रवेशास अनुमती असलेल्या devices ची यादी असते.

ही पद्धत मोठ्या प्रमाणावर वापरता येते. इतर पर्यायांमध्ये ठरावीक समस्या निर्माण होतात. प्रत्येक server साठी स्वतंत्र key असल्यास, वीस servers असलेल्या laptop मध्ये वीस private keys असतील. कोणती key कोणत्या server साठी आहे, हे लक्षात ठेवणे कठीण होईल. तुमच्या सर्व devices साठी एकच key वापरणे आणखी धोकादायक आहे. laptop चोरीला गेल्यास desktop चा प्रवेश कायम ठेवून laptop ची key revoke करता येत नाही, कारण दोन्ही devices कडे तीच private key असते. त्यामुळे ती key सर्वत्र बदलावी लागते आणि एकाच वेळी प्रत्येक device वर नव्याने वितरित करावी लागते.

प्रत्येक device साठी एक key असल्यास, laptop हरवल्यावर प्रत्येक server वरून फक्त एक ओळ हटवावी लागते: authorized_keys मधून laptop ची ओळ हटवा. इतर सर्व devices कार्यरत राहतात. -C वापरून सेट केलेली comment ही ओळ सहज शोधण्यास मदत करते.

या पद्धतीमागील नियम असा आहे: private key एखाद्या device वर तयार होते आणि त्या device सोबतच संपते. private key दुसऱ्या machine वर कधीही copy करू नका आणि ती server वर कधीही upload करू नका. नवीन device ला प्रवेश आवश्यक असल्यास, त्यावर नवीन key तयार करा.

सर्व्हरवर public key ठेवा

सोपे पर्याय म्हणजे ssh-copy-id. ते OpenSSH सोबत उपलब्ध होते:

ssh-copy-id matt@10.0.0.10

हे अद्याप कार्यरत असलेल्या पद्धतीने, सामान्यतः password वापरून, लॉग इन करते. त्यानंतर ते तुमची public key सर्व्हरवरील ~/.ssh/authorized_keys मध्ये जोडते. directory किंवा file उपलब्ध नसल्यास, योग्य permissions सह ते तयार करते. नवीन SSH session उघडून याची चाचणी करा. सर्व्हरने account password न विचारता प्रवेश द्यायला हवा. तुमच्या key ला passphrase असल्यास, तुमचे स्वतःचे machine त्याऐवजी तो विचारू शकते. हा prompt स्थानिक असतो; तो server password नसतो.

Password login आधीच disabled असल्यास, ssh-copy-id प्रवेश करू शकत नाही. त्यामुळे ही ओळ तुम्हाला manually जोडावी लागते. अद्याप कार्यरत असलेल्या session मधून किंवा तुमच्या 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 मध्ये प्रत्येक ओळीवर एक public key असते आणि तेच संपूर्ण access database असते. एखादे device जोडण्यासाठी एक ओळ append करा आणि access revoke करण्यासाठी ती ओळ delete करा. नवीन server वर, password login बंद करण्यापूर्वी, ही पायरी नवीन VPS वरील पहिल्या 10 मिनिटांत पूर्ण करा.

की-आधारित login मोडणाऱ्या permissions

की-आधारित login अयशस्वी होण्याची ही सर्वात सामान्य पद्धत आहे. Client कडून हे अयशस्वी होणे कोणताही स्पष्ट संदेश न देता घडते. Ubuntu 24.04 वर sshd default ने StrictModes yes सह चालते. त्यामुळे इतर users संपादित करू शकतील अशी authorized_keys file वापरण्यास ते नकार देते. File, ~/.ssh directory किंवा तुमची home directory तुमच्याशिवाय इतर कोणालाही लिहिता येत असेल, तर sshd तुमची key दुर्लक्षित करते आणि password विचारते. Client मध्ये याचे कोणतेही स्पष्टीकरण दिसत नाही. (Ubuntu चे OpenSSH फक्त एक मर्यादित प्रकरण स्वीकारते: तुमच्या स्वतःच्या private group कडून group-writable असलेली file, आणि त्या group मध्ये इतर कोणीही नसावे. त्यावर अवलंबून राहू नका; खालील modes वापरा.) याचे कारण फक्त server च्या 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 तपासा. हे काम server वर संबंधित user म्हणून करा:

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

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

तुमच्या स्वतःच्या संगणकावरील ~/.ssh/config फाइल प्रत्येक सर्व्हरसाठी लघुनाव देते आणि तुम्ही वारंवार टाइप करत असलेले पर्याय जतन करते. ती 600 permissions सह तयार करा आणि प्रत्येक सर्व्हरसाठी एक 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 ची जागा घेते. तसेच तेच लघुनाव scp, rsync आणि git मध्ये वापरता येते, कारण ही सर्व साधने ही फाइल वाचतात. HostName हा वास्तविक पत्ता आहे, User मुळे account name टाइप करण्याची गरज राहत नाही, आणि IdentityFile कोणती key offer करायची हे निश्चित करते.

IdentitiesOnly yes बद्दल एक वाक्य आवश्यक आहे, कारण ते गोंधळात टाकणारे अपयश टाळते. तुमच्या agent मध्ये अनेक keys असतील, तर client त्या एकामागोमाग offer करतो आणि server प्रत्येक offer ला failed attempt म्हणून मोजतो. पुरेशा keys loaded असतील, तर योग्य key वापरण्यापूर्वीच तुम्हाला Received disconnect: Too many authentication failures मिळते. IdentitiesOnly yes मुळे client ने IdentityFile मध्ये नमूद केलेली keyच offer करावी, असे निश्चित होते. त्यामुळे हे अपयश होऊ शकत नाही.

पासफ्रेज आणि ssh-agent

पासफ्रेज डिस्कवर असलेल्या private key फाइलचे encryption करते. पासफ्रेज नसल्यास, ही फाइल कॉपी करणारी कोणतीही व्यक्ती ती लगेच वापरू शकते. पासफ्रेज असल्यास, पासफ्रेजचा अंदाज येईपर्यंत चोरीला गेलेली फाइल निरुपयोगी राहते. Laptop वरील key साठी हेच आवश्यक संरक्षण आहे, कारण laptops चोरीला जाऊ शकतात आणि त्यांचे backups लीक होऊ शकतात.

प्रत्यक्षात पासफ्रेजमुळे कोणताही अतिरिक्त त्रास होत नाही, कारण ssh-agent. Agent तुमची decrypted key memory मध्ये ठेवतो. त्यामुळे प्रत्येक login session मध्ये पासफ्रेज एकदाच टाइप करावा लागतो आणि त्यानंतरचे प्रत्येक connection त्वरित सुरू होते. बहुतेक desktop Linux distributions आणि macOS तुमच्यासाठी agent आधीच चालवत असतात. तुमची key त्यात लोड करण्यासाठी:

ssh-add ~/.ssh/id_ed25519

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

रद्द करणे आणि बदलणे: हरवलेल्या लॅपटॉपसाठीची प्रक्रिया

साधी SSH key रद्द करण्यासाठी ती असलेल्या प्रत्येक सर्व्हरवरील authorized_keys मधून तिची ओळ काढणे पुरेसे आहे. यासाठी कोणत्याही certificate authority ला सूचित करण्याची किंवा expiry date ची प्रतीक्षा करण्याची गरज नसते. ती ओळ काढताच त्या key ने केलेले नवीन login अयशस्वी होतात.

आता ही प्रक्रिया करून पाहा, कारण सध्या आपत्कालीन परिस्थिती नाही. एखादा सर्व्हर निवडा, ~/.ssh/authorized_keys उघडा आणि comment द्वारे key शोधा. Editor वापरून ती ओळ हटवा किंवा comment नुसार ती फिल्टर करून काढा:

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

त्यानंतर, ज्या device वरून तुम्ही ती key नुकतीच रद्द केली आहे, तेथून login आता अयशस्वी होतो याची खात्री करा. दुसऱ्या device वरून login अजूनही यशस्वी होतो याचीही खात्री करा. एक महत्त्वाचा मुद्दा लक्षात ठेवा: key काढल्याने आधीपासून सुरू असलेली sessions बंद होत नाहीत, कारण key ची तपासणी फक्त login वेळी केली जाते. चोरीला गेलेल्या device ची key रद्द करत असल्यास, सर्व्हरवरील who देखील तपासा आणि ओळखू न येणारी कोणतीही session समाप्त करा.

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

काय करू नये

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

• private key git repository मध्ये commit करू नका, private repository असली तरीही. Automated scanners public repositories वर लक्ष ठेवतात आणि push केल्यानंतर काही मिनिटांत leaked keys वापरून पाहतात. नंतर repository public केल्यास तिचा संपूर्ण इतिहास उघड होतो.

• दुसऱ्या server पर्यंत पोहोचता यावे म्हणून तुमच्या laptop ची private key server वर upload करू नका. त्याऐवजी server वरच स्वतंत्र key generate करा आणि जिथे आवश्यक आहे तिथेच त्या key ला authorization द्या.

• private key chat, email किंवा ticket मध्ये paste करू नका. Public key आणि .pub file हेच कधीही share केले जाणारे एकमेव घटक आहेत.

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

FAQ

SSH keys पासवर्ड पाठविल्याशिवाय कशा कार्य करतात?

सर्व्हर तुमची public key ~/.ssh/authorized_keys मध्ये ठेवतो. लॉगिनच्या वेळी तो challenge पाठवतो. तुमचा client private key ने त्या challenge वर स्वाक्षरी करतो आणि सर्व्हर public key वापरून त्या स्वाक्षरीची पडताळणी करतो. Private key तुमचे device कधीही सोडत नाही. त्यामुळे ती network traffic मध्ये अडवता येत नाही आणि सर्व्हरवरून पुन्हा वापरता येईल अशी प्रत चोरता येत नाही. Breached server मधून फक्त public keys उघड होतात. त्यांचा वापर कुठेही लॉगिन करण्यासाठी करता येत नाही.

माझ्या सर्व्हरपैकी सर्वांसाठी मी तीच SSH key वापरावी का?

ती key एकाच device वर सुरक्षित राहात असेल, तर अनेक सर्व्हरवर तीच key वापरणे योग्य आहे. नियम प्रत्येक सर्व्हरसाठी एक key असा नाही; प्रत्येक device साठी एक key असा आहे. तुमच्या laptop ची public key त्या laptop ला आवश्यक असलेल्या प्रत्येक सर्व्हरवर ठेवा. तुमच्या desktop साठी स्वतंत्र key ठेवा. त्यामुळे key रद्द करणे सोपे राहते. एखादे device हरवल्यास प्रत्येक सर्व्हरमधून ओळखता येणारी एक ओळ काढावी लागते आणि इतर devices कार्यरत राहतात.

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

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

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

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

माझ्या SSH key वर passphrase आवश्यक आहे का?

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