SSH key నిర్వహణ ప్రాథమికాలు: సురక్షిత వినియోగం

SSH keys ఎలా పనిచేస్తాయి

SSH key రెండు files జతగా ఉంటుంది: మీ device లోనే ఉండే private key మరియు మీరు login చేయాలనుకునే ప్రతి server కు copy చేసే public key. మీరు connect అయినప్పుడు, server public key ను ఉపయోగించి ఒక challenge పంపుతుంది. దానికి సరిపోలే private key మాత్రమే సమాధానం ఇవ్వగలదు. Private key ఎప్పుడూ మీ device ను విడిచిపెట్టదు. అందువల్ల network ద్వారా secret ఏదీ ప్రయాణించదు. అలాగే server breached అయినా దొంగిలించడానికి ఉపయోగకరమైన secret అక్కడ ఉండదు. అందుకే keys, passwords కంటే మెరుగైనవి. SSH keys ను సరిగ్గా నిర్వహించడం నాలుగు అలవాట్లపై ఆధారపడి ఉంటుంది: ప్రతి device కు ఒక key, sshd కోరే file permissions, options ను మళ్లీ మళ్లీ type చేయకుండా చేసే ~/.ssh/config file, అలాగే laptop కనిపించకుండా పోయిన రోజే key ను ఎలా తొలగించాలో తెలుసుకోవడం.

ఈ guide ప్రతి అలవాటును Ubuntu 24.04 పై వివరిస్తుంది. అయితే ఇక్కడి దాదాపు అన్నీ ఏ Linux server కు, ఇటీవలి OpenSSH version కు వర్తిస్తాయి.

ప్రారంభించే ముందు vocabulary లోని ఒక విషయాన్ని స్పష్టంగా తెలుసుకోవాలి. Public key secret కాదు. దాన్ని ticket లో paste చేయవచ్చు, email ద్వారా పంపవచ్చు లేదా publish చేయవచ్చు. దానితో ఎవరూ login చేయలేరు. Private key మాత్రం secret. ఆ file ను copy చేసుకున్న వ్యక్తికి, అది passphrase తో రక్షించబడి ఉంటే ఆ passphrase కూడా తెలిసి ఉంటే, మీ servers దృష్టిలో అతడే మీరు.

కీని సృష్టించండి: ed25519 సరైన డిఫాల్ట్

సర్వర్‌లో కాకుండా, మీ స్వంత కంప్యూటర్‌లో ఈ ఆదేశాన్ని అమలు చేయండి:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 కీ రకాన్ని ఎంచుకుంటుంది. Ed25519 ఆధునిక డిఫాల్ట్. ఈ కీలు చిన్నవి, వేగవంతమైనవి. 2014 నుంచి వచ్చిన ప్రతి OpenSSH release వీటికి మద్దతు ఇస్తుంది. ed25519 అర్థం కాని పాత పరికరంతో తప్పనిసరిగా మాట్లాడాల్సి వచ్చినప్పుడు మాత్రమే ssh-keygen -t rsa -b 4096 కు మారండి. -C "laptop" comment ను సెట్ చేస్తుంది. ఈ comment కు cryptographic పని ఏదీ లేదు. అయితే రెండు సంవత్సరాల తర్వాత server లోని authorized_keys file లో ఈ కీని గుర్తించడానికి ఇది ఉపయోగపడుతుంది. అందువల్ల కీ ఉన్న పరికరం పేరును ఇవ్వండి.

ssh-keygen కీని ఎక్కడ సేవ్ చేయాలో అడుగుతుంది. డిఫాల్ట్ అయిన ~/.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 material, మరియు మీ comment. మీ servers లో చివరకు చేరేది ఈ line.

ప్రతి server కు ఒకటి కాదు, ప్రతి device కు ఒక key

అందరూ ముందుగా అడిగే ప్రశ్న: ప్రతి server కోసం కొత్త key అవసరమా? అవసరం లేదు. మీరు టైప్ చేసే ప్రతి device కోసం ఒక key సృష్టించండి. ఆ device చేరాల్సిన ప్రతి server లో అదే public key ను ఉంచండి. ఆ key ఆ device ను గుర్తిస్తుంది. ప్రతి server లోని authorized_keys file లో అనుమతించబడిన devices జాబితా ఉంటుంది.

ఇదే సులభంగా విస్తరించగల model. ప్రత్యామ్నాయ పద్ధతులు ఊహించదగిన సమస్యలకు దారితీస్తాయి. ప్రతి server కు ఒక key ఉంటే, 20 servers ఉన్న laptop లో 20 private keys ఉంటాయి. ఏ key ఏ server కు చెందినదో గుర్తించడం కష్టమవుతుంది. మీ అన్ని devices కోసం ఒకే key పంచుకోవడం ఇంకా ప్రమాదకరం. Laptop దొంగిలించబడితే, అదే private key మీ desktop లో కూడా ఉంటుంది. అందువల్ల desktop access ను నిలిపివేయకుండా laptop access ను revoke చేయలేరు. కాబట్టి key ను ప్రతిచోటా మార్చి, అన్ని devices కు ఒకేసారి పంపిణీ చేయాలి.

ప్రతి device కు ఒక key ఉంటే, laptop పోయినప్పుడు ప్రతి server లో ఒక line ను మాత్రమే తొలగించాలి: authorized_keys నుంచి laptop కు చెందిన line ను తొలగించండి. మిగతా devices అన్నీ పనిచేస్తూనే ఉంటాయి. -C తో మీరు సెట్ చేసే comment వల్ల ఆ line ను సులభంగా గుర్తించవచ్చు.

ఈ model వెనుక ఉన్న నియమం: private key ఒక device లో సృష్టించబడుతుంది, ఆ device తోనే దాని వినియోగం ముగియాలి. Private key ను ఎప్పుడూ రెండో machine కు copy చేయకండి. దాన్ని ఎప్పుడూ server కు upload చేయకండి. కొత్త device కు access అవసరమైతే, ఆ device లో కొత్త key ను generate చేయండి.

సర్వర్‌పై public key ను ఉంచండి

సులభమైన విధానం ssh-copy-id. ఇది OpenSSH తో వస్తుంది:

ssh-copy-id matt@10.0.0.10

ఇది పనిచేస్తున్న authentication పద్ధతిని ఉపయోగించి login అవుతుంది. సాధారణంగా అది password అయి ఉంటుంది. తరువాత మీ public key ను సర్వర్‌లోని ~/.ssh/authorized_keys కు జతచేస్తుంది. directory లేదా file లేకపోతే, సరైన permissions తో వాటిని సృష్టిస్తుంది. కొత్త SSH session తెరిచి పరీక్షించండి. సర్వర్ account password అడగకుండా login చేయనివ్వాలి. మీ key కి passphrase ఉంటే, మీ స్వంత machine దానిని అడగవచ్చు. ఆ prompt localది; అది సర్వర్ password కాదు.

Password login ఇప్పటికే నిలిపివేసి ఉంటే, ssh-copy-id login కాలేదు. అందువల్ల ఆ line ను చేతితో జతచేయాలి. ఇంకా పనిచేస్తున్న session ద్వారా లేదా మీ provider యొక్క web console ద్వారా login అయి, సర్వర్‌లో ఈ command ను అమలు చేయండి:

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 ను append చేయడం. ఒక device ప్రాప్యతను రద్దు చేయడం అంటే ఆ line ను delete చేయడం. కొత్త serverలో, password login ను ఆపివేయడానికి వెంటనే ముందు, ఈ దశను కొత్త VPSలో మొదటి 10 నిమిషాలు లో పూర్తి చేయాలి.

కీ ఆధారిత login ను విఫలమయ్యే permissions

కీ ఆధారిత login విఫలమయ్యే అత్యంత సాధారణ కారణం ఇదే. Client వైపు ఎలాంటి స్పష్టమైన సందేశం లేకుండానే ఇది విఫలమవుతుంది. Ubuntu 24.04లో sshd డిఫాల్ట్‌గా StrictModes yes తో నడుస్తుంది. ఇతర users మార్చగలిగే authorized_keys file ను ఉపయోగించడానికి అది నిరాకరిస్తుంది. ఆ file, ~/.ssh directory లేదా మీ home directory ను మీ తప్ప మరెవరైనా రాయగలిగితే, sshd మీ key ను పట్టించుకోదు. బదులుగా password అడుగుతుంది. Clientలో దీనికి ఎలాంటి వివరణ కనిపించదు. (Ubuntu యొక్క OpenSSH ఒకే నిర్దిష్ట పరిస్థితిని మాత్రమే అనుమతిస్తుంది: మీ స్వంత private group కు చెందినవారు మాత్రమే ఉండే group ద్వారా file కు write permission ఉండటం. దానిపై ఆధారపడవద్దు. కింది 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 మార్పులు మరియు ownership check అవసరం. ప్రభావిత user గా serverలో వీటిని అమలు చేయండి:

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

గుర్తుంచుకోవాల్సిన నియమం: 700 ను .ssh directory పై అమలు చేయాలి. దాని లోపల ఉన్న ప్రతిదానిపై 600 అమలు చేయాలి. మీ స్వంత computer పై కూడా ఇదే numbers వర్తిస్తాయి, ఎందుకంటే client కూడా permissions ను తనిఖీ చేస్తుంది. ఇతర users చదవగలిగే private key ను ssh పూర్తిగా తిరస్కరిస్తుంది. ఈసారి 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 ఫైల్ ప్రతి server కు ఒక చిన్న పేరు ఇస్తుంది. మీరు తరచుగా టైప్ చేసే ఎంపికలను కూడా అది గుర్తుంచుకుంటుంది. ఈ ఫైల్‌ను 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 ఉపయోగించవచ్చు. అదే చిన్న పేరు scp, rsync, git లో కూడా పనిచేస్తుంది, ఎందుకంటే అవన్నీ ఈ ఫైల్‌ను చదువుతాయి. HostName అసలు address ను సూచిస్తుంది. User account name ను మళ్లీ టైప్ చేయాల్సిన అవసరాన్ని తొలగిస్తుంది. IdentityFile అందించాల్సిన key ఏదో నిర్దిష్టంగా నిర్ణయిస్తుంది.

IdentitiesOnly yes గురించి ప్రత్యేకంగా ఒక విషయం గుర్తుంచుకోవాలి. ఇది గందరగోళానికి దారితీసే ఒక విఫలతను నివారిస్తుంది. మీ agent లో అనేక keys ఉంటే, client వాటిని ఒక్కొక్కటిగా అందిస్తుంది. Server ప్రతి offer ను failed attempt గా లెక్కిస్తుంది. తగినన్ని keys load అయి ఉంటే, సరైన key ప్రయత్నించకముందే Received disconnect: Too many authentication failures వస్తుంది. IdentitiesOnly yes ఉపయోగిస్తే IdentityFile లో పేర్కొన్న key ను మాత్రమే client అందిస్తుంది. అందువల్ల ఈ విఫలత సంభవించదు.

Passphrases మరియు ssh-agent

Passphrase డిస్క్‌లోని private key file ను encrypt చేస్తుంది. Passphrase లేకపోతే, ఆ file ను copy చేసిన ఎవరైనా వెంటనే ఉపయోగించవచ్చు. Passphrase ఉంటే, దాన్ని ఊహించే వరకు దొంగిలించిన file ఉపయోగం ఉండదు. Laptop లోని key కు ఇది సరైన రక్షణ. ఎందుకంటే laptops దొంగిలించబడవచ్చు, అలాగే వాటి backups బయటపడవచ్చు.

ఆచరణలో passphrase వల్ల అదనపు ఇబ్బంది లేకపోవడానికి కారణం ssh-agent. Agent decrypt చేసిన key ను memory లో ఉంచుతుంది. అందువల్ల ప్రతి login session కు passphrase ను ఒక్కసారి నమోదు చేస్తే సరిపోతుంది. తరువాతి ప్రతి connection వెంటనే ఏర్పడుతుంది. చాలా desktop Linux distributions మరియు macOS ఇప్పటికే మీ కోసం agent ను నడుపుతాయి. ఈ command తో మీ key ను అందులో load చేయండి:

ssh-add ~/.ssh/id_ed25519

ssh-add -l ప్రస్తుతం agent వద్ద ఉన్న keys ను చూపిస్తుంది. ఒక జాగ్రత్త: agent forwarding (ssh -A) ప్రారంభించి మీరు remote server కు connected గా ఉన్నప్పుడు, ఆ server మీ agent ను ఉపయోగించి తదుపరి server కు authenticate కావచ్చు. కాబట్టి పూర్తిగా నమ్మే servers వైపు మాత్రమే దీన్ని enable చేయండి. Default గా దీన్ని off లో ఉంచండి.

రద్దు మరియు rotation: పోయిన laptop కోసం అభ్యాసం

సాధారణ SSH key ను revoke చేయడం అంటే, దాన్ని కలిగి ఉన్న ప్రతి server లోని authorized_keys నుంచి దాని line ను తొలగించడం మాత్రమే. సంప్రదించాల్సిన certificate authority ఉండదు. గడువు ముగిసే వరకు వేచి ఉండాల్సిన అవసరం ఉండదు. ఆ line తొలగించిన వెంటనే, ఆ key తో కొత్త logins విఫలమవుతాయి.

ఇది అత్యవసర పరిస్థితి కానప్పుడే ఇప్పుడే అభ్యాసంగా చేయండి. ఒక server ను ఎంచుకుని, ~/.ssh/authorized_keys ను తెరిచి, comment ద్వారా ఆ key ను కనుగొనండి. Editor తో ఆ line ను తొలగించండి లేదా comment ద్వారా దాన్ని filter చేసి తొలగించండి:

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

మీరు ఇప్పుడే revoke చేసిన device నుంచి login విఫలమవుతోందని నిర్ధారించండి. మరో device నుంచి login ఇంకా పనిచేస్తోందని కూడా నిర్ధారించండి. ఒక విషయం గుర్తుంచుకోండి: ఇప్పటికే తెరిచి ఉన్న sessions ను key తొలగించడం ద్వారా మూసివేయలేరు. ఎందుకంటే key ను login సమయంలో మాత్రమే తనిఖీ చేస్తారు. దొంగిలించబడిన device కు సంబంధించిన key ను revoke చేస్తుంటే, server లోని who ను కూడా తనిఖీ చేసి, మీకు గుర్తు లేని session ఏదైనా ఉంటే ముగించండి.

Rotation లోనూ ఇదే పని జరుగుతుంది, కానీ క్రమం వేరుగా ఉంటుంది: device లో కొత్త key ను generate చేయండి, ssh-copy-id తో దాన్ని install చేయండి, కొత్త key తో login అవుతోందని నిర్ధారించండి, తరువాత పాత line ను తొలగించండి. Device మరొకరి చేతికి మారినప్పుడు, key బహిర్గతమై ఉండవచ్చని అనుమానం ఉన్నప్పుడు లేదా ఎవరైనా team నుంచి వెళ్లిపోయినప్పుడు ఇలా చేయండి. రెండు servers పై దీన్ని చేతితో చేయడం సరే. ఇరవై servers పై చేయాల్సి వస్తే automation ఉపయోగించాలి. అనేక Linux servers నిర్వహణ మొత్తం fleet కు ఒకే authorized_keys state ను పంపే విధానాన్ని చూపిస్తుంది.

ఏవి చేయకూడదు

• మీ అన్ని పరికరాల కోసం ఒకే private key ను ఉపయోగించవద్దు. ఒక పరికరం దొంగిలించబడినప్పుడు, ప్రతిచోటా key ను మార్చకుండా ఆ ఒక్క పరికరానికి మాత్రమే access ను రద్దు చేయడం సాధ్యం కాదు.

• private key ను git repository లో commit చేయవద్దు, అది private repository అయినా సరే. Automated scanners public repositories ను పర్యవేక్షిస్తాయి. Push చేసిన కొన్ని నిమిషాల్లోనే leaked keys ను ఉపయోగించడానికి ప్రయత్నిస్తాయి. Repository ను తరువాత public గా మార్చినా, దాని మొత్తం history బయటపడుతుంది.

• మరొక server ను చేరుకోవడానికి మీ laptop యొక్క private key ను server కు upload చేయవద్దు. Server పైనే ప్రత్యేక key ను generate చేయండి. ఆ key అవసరమైన చోట మాత్రమే దానికి authorization ఇవ్వండి.

• private key ను chat, email లేదా ticket లో paste చేయవద్దు. ఎప్పుడైనా share చేయాల్సినది public key మాత్రమే; అదే .pub file.

మీ key ద్వారా మీరు విశ్వసనీయంగా login చేయగలిగిన తర్వాత, తదుపరి దశగా password authentication ను నిలిపివేయండి. అప్పుడు మీ server పై నిరంతరం జరిగే password guessing విజయవంతం కావడం పూర్తిగా ఆగిపోతుంది. దానికి అవసరమైన drop-in configuration VPS పై SSH hardening లో ఉంది.

FAQ

పాస్‌వర్డ్ పంపకుండానే SSH keys ఎలా పనిచేస్తాయి?

సర్వర్ మీ public key ను ~/.ssh/authorized_keys లో ఉంచుతుంది. Login సమయంలో అది ఒక challenge పంపుతుంది. మీ client private key తో ఆ challenge ను sign చేస్తుంది. తరువాత సర్వర్ public key తో ఆ signature ను verify చేస్తుంది. Private key మీ device ను ఎప్పుడూ విడిచిపెట్టదు. అందువల్ల network మార్గంలో దాన్ని intercept చేయడం సాధ్యం కాదు. సర్వర్ నుంచి దొంగిలించినా మళ్లీ ఉపయోగించగల రహస్య సమాచారం ఉండదు. Breached server నుంచి public keys మాత్రమే బయటపడతాయి. వాటితో ఎక్కడా login చేయడం సాధ్యం కాదు.

నా అన్ని servers కు ఒకే SSH key ఉపయోగించాలా?

ఆ key ఒకే device లో ఉంటే, అనేక servers కోసం ఒకే key ఉపయోగించడం సరైనదే. నియమం ప్రతి server కు ఒక key కాదు; ప్రతి device కు ఒక key. మీ laptop కు చెందిన public key ను ఆ laptop అవసరమైన ప్రతి server లో ఉంచాలి. మీ desktop కు ప్రత్యేక key ఉండాలి. ఇలా చేస్తే key ను revoke చేయడం సులభమవుతుంది. ఒక device పోయినప్పుడు ప్రతి server నుంచి గుర్తించగల ఒక line ను మాత్రమే తొలగించాలి. మిగిలిన devices పనిచేస్తూనే ఉంటాయి.

.ssh directory మరియు authorized_keys కు ఏ permissions ఉండాలి?

~/.ssh పై 700 permissions ను, authorized_keys పై మరియు ప్రతి private key పై 600 permissions ను అమలు చేయండి. వీటి owner వాటిని ఉపయోగించే account అయి ఉండాలి. sshd డిఫాల్ట్‌గా StrictModes yes తో నడుస్తుంది. అందువల్ల మీకాకుండా మరెవరైనా రాయగల file లేదా home directory ఉంటే, అది మీ key ను మౌనంగా పరిగణనలోకి తీసుకోదు. Server యొక్క auth log లేదా journal లో కనిపించే ఏకైక గుర్తు Authentication refused: bad ownership or modes అవుతుంది.

Server నుంచి SSH key ను ఎలా తొలగించాలి?

ఆ key ఏ account కోసం authorised చేయబడిందో, ఆ account లోని ~/.ssh/authorized_keys నుంచి దాని line ను తొలగించండి. Key material తరువాత ఉన్న label అయిన comment ద్వారా సరైన line ను గుర్తించండి. ఆ key తో చేసే కొత్త logins వెంటనే విఫలమవుతాయి. అయితే ఇప్పటికే open గా ఉన్న sessions కొనసాగుతాయి. ఆ device దొంగిలించబడితే, దానికి సంబంధించిన live session ను కూడా ముగించండి. ఆ key copy చేసిన ప్రతి server లో ఇదే విధానాన్ని పునరావృతం చేయండి.

నా SSH key పై passphrase అవసరమా?

Laptop లేదా desktop లో ఉన్న key కు passphrase అవసరం. Passphrase key file ను encrypt చేస్తుంది. అందువల్ల దొంగిలించిన లేదా leak అయిన copy ఒక్కదానితో ఉపయోగపడదు. ssh-agent వల్ల ప్రతి connection సమయంలో కాకుండా, ప్రతి session కు ఒకసారి మాత్రమే దాన్ని నమోదు చేయాలి. Server లో unattended automation ఉపయోగించే keys కు సాధారణంగా passphrase ఉండదు. ఎందుకంటే దాన్ని నమోదు చేయడానికి అక్కడ ఎవరూ ఉండరు. అలాంటి keys ను target account చేయగల పనులను పరిమితం చేయడం ద్వారా రక్షించండి.