SSH కీలు ఎలా నిర్వహించాలి

SSH కీలు ఎలా పనిచేస్తాయి

SSH కీ అనేది రెండు ఫైళ్ల జత: మీ పరికరంలో ఉండే ప్రైవేట్ కీ మరియు మీరు లాగిన్ అవ్వాలనుకునే ప్రతి సర్వర్‌కు కాపీ చేసే పబ్లిక్ కీ. మీరు కనెక్ట్ అయినప్పుడు, సర్వర్ పబ్లిక్ కీని ఉపయోగించి ఒక సవాలును పంపుతుంది. దానికి సరిపోలిన ప్రైవేట్ కీ మాత్రమే సమాధానం ఇవ్వగలదు. ప్రైవేట్ కీ మీ పరికరం నుండి బయటకు వెళ్లదు. కాబట్టి నెట్‌వర్క్ ద్వారా ఎలాంటి రహస్యం ప్రయాణించదు. దెబ్బతిన్న సర్వర్‌లో దొంగిలించడానికి ఏమీ ఉండదు. అందుకే పాస్‌వర్డ్‌ల కంటే కీలు మెరుగ్గా పనిచేస్తాయి. SSH కీలను సరిగ్గా నిర్వహించడం అనేది నాలుగు అలవాట్లపై ఆధారపడి ఉంటుంది: ఒక పరికరానికి ఒక కీ, sshd కావలసిన ఫైల్ అనుమతులు, ఎంపికలను పదేపదే టైప్ చేయకుండా ఉండటానికి ఒక ~/.ssh/config ఫైల్, మరియు ల్యాప్‌టాప్ పోయిన రోజున కీని ఎలా తొలగించాలో తెలుసుకోవడం.

ఈ గైడ్ Ubuntu 24.04లో ప్రతి అలవాటును వివరిస్తుంది. అయితే ఇందులోని దాదాపు ప్రతిదీ ఏదైనా Linux సర్వర్‌కు మరియు ఏదైనా ఇటీవలి OpenSSHకు వర్తిస్తుంది.

మనం ప్రారంభించడానికి ముందు ఒక పదజాలం గురించి చెప్పాలి, ఎందుకంటే ఇది నిజమైన పొరపాట్లను నివారిస్తుంది. పబ్లిక్ కీ రహస్యం కాదు. మీరు దాన్ని ఒక టికెట్‌లో అతికించవచ్చు, ఇమెయిల్ ద్వారా పంపవచ్చు లేదా ప్రచురించవచ్చు. దాన్ని ఉపయోగించి ఎవరూ లాగిన్ కాలేరు. ప్రైవేట్ కీయే రహస్యం. ఆ ఫైల్‌ను కాపీ చేసి, దానికి పాస్‌ఫ్రేజ్ ఉంటే దాన్ని తెలుసుకున్న ఎవరైనా, మీ సర్వర్‌ల దృష్టిలో మీరే అవుతారు.

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

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

ssh-keygen -t ed25519 -C "laptop"

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

ssh-keygen కీని ఎక్కడ సేవ్ చేయాలో అడుగుతుంది. డిఫాల్ట్ అయిన ~/.ssh/id_ed25519 ని అంగీకరించండి. అప్పుడు అది పాస్‌ఫ్రేజ్ కోసం అడుగుతుంది. ఒకటి సెట్ చేయండి; దిగువ పాస్‌ఫ్రేజ్ విభాగం రోజువారీ వినియోగంలో అది మీకు ఎలాంటి ఖర్చు కలిగించదో వివరిస్తుంది. మీకు రెండు ఫైళ్లు లభిస్తాయి: ~/.ssh/id_ed25519 ప్రైవేట్ కీ, మరియు ~/.ssh/id_ed25519.pub పబ్లిక్ కీ. పబ్లిక్ భాగాన్ని చూడండి:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

అది ఒకే వరుస: కీ రకం, కీ మెటీరియల్, మరియు మీ వ్యాఖ్య. ఆ వరుసే మీ సర్వర్‌లలో చేరుతుంది.

ప్రతి పరికరానికి ఒక కీ, ప్రతి సర్వర్‌కు ఒకటి కాదు

ప్రతి ఒక్కరూ ముందుగా అడిగే ప్రశ్న: ప్రతి సర్వర్‌కు నాకు కొత్త కీ కావాలా? లేదు. మీరు టైప్ చేసే ప్రతి పరికరానికి ఒక కీ సృష్టించండి. ఆ పరికరం చేరుకోవలసిన ప్రతి సర్వర్‌లో ఆ ఒక్క పబ్లిక్ కీని ఉంచండి. ఈ కీ ఆ పరికరాన్ని గుర్తిస్తుంది. ప్రతి సర్వర్‌లోని authorized_keys ఫైలు, లోపలకు అనుమతించబడిన పరికరాల జాబితా.

ఇది విస్తరించదగిన నమూనా. ప్రత్యామ్నాయాలు ఊహించిన విధంగా విఫలమవుతాయి. ఒక సర్వర్‌కు ఒక కీ అంటే, ఇరవై సర్వర్‌లను కలిగి ఉన్న ల్యాప్‌టాప్ ఇరవై ప్రైవేట్ కీలను మోసుకుంటుంది. ఏది ఏదో మీరు కోల్పోతారు. అన్ని పరికరాలు ఒకే కీని పంచుకోవడం మరింత చెడు. ల్యాప్‌టాప్ దొంగిలించబడినప్పుడు, మీ డెస్క్‌టాప్‌ను బయటకు లాక్ చేయకుండా మీరు ల్యాప్‌టాప్ యాక్సెస్‌ను రద్దు చేయలేరు. ఎందుకంటే అవి ఒకే ప్రైవేట్ కీని కలిగి ఉంటాయి. కాబట్టి మీరు అన్నిచోట్లా కీని భర్తీ చేసి, అన్ని పరికరాలకు ఒకేసారి మళ్లీ పంపాలి.

ఒక పరికరానికి ఒక కీ ఉంటే, పోయిన ల్యాప్‌టాప్ మీకు ఒక్క సర్వర్‌కు ఒక్క లైన్ ఖర్చు కట్టిస్తుంది. ల్యాప్‌టాప్ లైన్‌ను authorized_keys నుండి తొలగించండి. మిగతా ప్రతి పరికరం పనిచేస్తూనే ఉంటుంది. మీరు -C తో సెట్ చేసిన వ్యాఖ్య ఆ లైన్‌ను సులభంగా కనుగొనేలా చేస్తుంది.

ఈ నమూనా వెనుక ఉన్న నియమం: ఒక ప్రైవేట్ కీ ఒక పరికరంలో సృష్టించబడుతుంది. ఆ పరికరంతోనే అది అంతరిస్తుంది. ఒక ప్రైవేట్ కీని ఎప్పుడూ రెండవ మెషీన్‌కు కాపీ చేయవద్దు. దాన్ని ఎప్పుడూ సర్వర్‌కు అప్‌లోడ్ చేయవద్దు. కొత్త పరికరానికి యాక్సెస్ అవసరం ఉన్నప్పుడు, దానిలో కొత్త కీని సృష్టించండి.

పబ్లిక్ కీని సర్వర్‌లో ఉంచండి

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

ssh-copy-id matt@10.0.0.10

ఇది ఇంకా పనిచేస్తున్న దేనితోనైనా లాగిన్ అవుతుంది, సాధారణంగా పాస్‌వర్డ్‌తో, మీ పబ్లిక్ కీని సర్వర్‌లో ~/.ssh/authorized_keysకి జోడిస్తుంది, మరియు డైరెక్టరీ మరియు ఫైల్ లేకపోతే సరైన అనుమతులతో వాటిని సృష్టిస్తుంది. కొత్త SSH సెషన్‌ను తెరిచి దీన్ని పరీక్షించండి: అకౌంట్ పాస్‌వర్డ్‌ను అడగకుండా సర్వర్ మిమ్మల్ని లోపలికి అనుమతించాలి. మీ కీకి పాస్‌ఫ్రేజ్ ఉంటే, మీ స్వంత మెషీన్ దానిని అడగవచ్చు; ఆ ప్రాంప్ట్ లోకల్‌గా ఉంటుంది, ఇది సర్వర్ పాస్‌వర్డ్ కాదు.

పాస్‌వర్డ్ లాగిన్ ఇప్పటికే నిలిపివేయబడినప్పుడు, ssh-copy-id లోపలికి రాలేకపోతుంది, కాబట్టి మీరు ఆ లైన్‌ను మాన్యువల్‌గా జోడిస్తారు. ఇంకా పనిచేస్తున్న సెషన్ ద్వారా లేదా మీ ప్రొవైడర్ వెబ్ కన్సోల్ ద్వారా లాగిన్ అవ్వండి, మరియు సర్వర్‌లో ఇది రన్ చేయండి:

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

కోట్స్ లోపల మీ నిజమైన పబ్లిక్ కీని పేస్ట్ చేయండి, id_ed25519.pub నుండి పూర్తి ఒంటరి లైన్. authorized_keys అనేది ఒక లైన్‌కు ఒక పబ్లిక్ కీ, మరియు అదే పూర్తి యాక్సెస్ డేటాబేస్: ఒక పరికరాన్ని జోడించడం అనేది ఒక లైన్‌ను జోడించడం, మరియు ఒక పరికరాన్ని రద్దు చేయడం అనేది ఒక లైన్‌ను తొలగించడం. కొత్త సర్వర్‌లో, ఈ దశ కొత్త VPSలో మొదటి 10 నిమిషాలులో చేర్చడానికి చెందుతుంది, మీరు పాస్‌వర్డ్ లాగిన్‌ను ఆఫ్ చేయడానికి కొద్ది ముందు.

కీ లాగిన్‌ను భంగపరిచే అనుమతులు

కీ లాగిన్ విఫలమవడానికి ఇది అత్యంత సాధారణ మార్గం. క్లయింట్ వైపు నుండి ఇది నిశ్శబ్దంగా విఫలమవుతుంది. Ubuntu 24.04లో sshd అప్రమేయంగా StrictModes yesతో అమలవుతుంది. అంటే ఇతర వినియోగదారులు సవరించగలిగే authorized_keys ఫైల్‌ను ఇది ఉపయోగించదు. ఆ ఫైల్, ~/.ssh డైరెక్టరీ, లేదా మీ హోమ్ డైరెక్టరీని మీరు తప్ప మరెవరైనా రాయగలిగితే, sshd మీ కీని విస్మరిస్తుంది. తర్వాత పాస్‌వర్డ్ అడిగే దశకు తిరిగి వెళ్తుంది. క్లయింట్‌లో దీనికి ఎలాంటి వివరణ ఉండదు. (Ubuntu యొక్క OpenSSH ఒకే ఒక్క ప్రత్యేక సందర్భాన్ని అనుమతిస్తుంది: మీ స్వంత ప్రైవేట్ గ్రూప్ ద్వారా ఫైల్‌కు రాయడానికి అనుమతి ఉండటం. ఆ గ్రూప్‌లో మరే ఇతర వ్యక్తి ఉండరు. దీనిపై ఆధారపడకండి. దిగువ పేర్కొన్న మోడ్‌లను పాటించండి.) కారణం సర్వర్ లాగ్‌లో మాత్రమే కనిపిస్తుంది:

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

rsyslog లేని కనీస ఇమేజ్‌లో auth.log ఉండదు. అదే వివరం జర్నల్‌లో ఉంటుంది: sudo journalctl -u ssh | grep 'Authentication refused'.

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

పరిష్కారం అనేది రెండు అనుమతి మార్పులు, ఒక యాజమాన్య తనిఖీ. ఇవి సర్వర్‌లో ప్రభావిత వినియోగదారుగా అమలు చేయండి:

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

గుర్తుంచుకోవలసిన నియమం: .ssh డైరెక్టరీపై 700, దాని లోపల ఉన్న ప్రతిదానిపై 600. ఈ అదే సంఖ్యలు మీ స్వంత కంప్యూటర్‌కు కూడా వర్తిస్తాయి. ఎందుకంటే క్లయింట్ కూడా తనిఖీ చేస్తుంది. ఇతర వినియోగదారులు చదవగలిగే ప్రైవేట్ కీ ఉంటే, ssh దాన్ని స్పష్టంగా తిరస్కరిస్తుంది. ఈసారి ఎర్రర్ స్పష్టంగా కనిపిస్తుంది:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         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 అనుమతులతో సృష్టించండి. ప్రతి సర్వర్‌కు ఒక 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 ఏ కీని అందించాలో నిర్దేశిస్తుంది.

IdentitiesOnly yes గురించి ఒక వాక్యం చెప్పాలి. ఎందుకంటే అది ఒక గందరగోళ వైఫల్యాన్ని పరిష్కరిస్తుంది. మీ ఏజెంట్‌లో అనేక కీలు ఉన్నప్పుడు, క్లయింట్ వాటిని ఒక్కొక్కటిగా అందిస్తుంది. సర్వర్ ప్రతి ప్రయత్నాన్ని విఫల ప్రయత్నంగా లెక్కిస్తుంది. తగినంత కీలు లోడ్ అయినట్లయితే, సరైన కీ ప్రయత్నించబడక ముందే మీకు Received disconnect: Too many authentication failures వస్తుంది. IdentitiesOnly yes క్లయింట్‌ను IdentityFile‌లో పేర్కొన్న కీని మాత్రమే అందించేలా చేస్తుంది. కాబట్టి ఆ వైఫల్యం జరగదు.

పాస్‌ఫ్రేజ్‌లు మరియు ssh-agent

పాస్‌ఫ్రేజ్ డిస్క్‌లో ఉన్న ప్రైవేట్ కీ ఫైల్‌ను ఎన్‌క్రిప్ట్ చేస్తుంది. దీని లేకపోతే, ఆ ఫైల్‌ను కాపీ చేసుకున్న ఎవరైనా వెంటనే దాన్ని ఉపయోగించవచ్చు. ఉంటే, పాస్‌ఫ్రేజ్‌ను ఊహించే వరకు దొంగిలించిన ఫైల్ పనికిరాదు. ల్యాప్‌టాప్‌లు దొంగిలించబడతాయి కాబట్టి, ల్యాప్‌టాప్ బ్యాకప్‌లు లీక్ అవుతాయి కాబట్టి, ల్యాప్‌టాప్‌లో ఉన్న కీకి ఇదే మీరు కావలసిన రక్షణ.

పాస్‌ఫ్రేజ్ వల్ల ఆచరణలో ఎలాంటి నష్టం లేదని కారణం ssh-agent. ఏజెంట్ మీ డీక్రిప్ట్ చేసిన కీను మెమరీలో ఉంచుతుంది. కాబట్టి మీరు ఒక్క లాగిన్ సెషన్‌కు ఒకసారి పాస్‌ఫ్రేజ్ టైప్ చేస్తారు. తర్వాత ప్రతి కనెక్షన్ వెంటనే జరుగుతుంది. చాలా డెస్క్‌టాప్ Linux డిస్ట్రిబ్యూషన్‌లు మరియు macOS ఇప్పటికే మీ కోసం ఒక ఏజెంట్‌ను నడుపుతున్నాయి. దీనితో మీ కీను లోడ్ చేయండి:

ssh-add ~/.ssh/id_ed25519

ssh-add -l ఏజెంట్ ప్రస్తుతం కలిగి ఉన్న కీలను జాబితా చేస్తుంది. ఒక హెచ్చరిక: ఏజెంట్ ఫార్వర్డింగ్ (ssh -A) మీరు కనెక్ట్ అయి ఉన్నప్పుడు రిమోట్ సర్వర్‌ను మీ ఏజెంట్‌ను ఉపయోగించి ముందుకు ప్రామాణీకరించడానికి అనుమతిస్తుంది. కాబట్టి మీరు పూర్తిగా నమ్మకపడే సర్వర్‌ల వైపు మాత్రమే దాన్ని ప్రారంభించండి. మరియు అప్రమేయంగా దాన్ని ఆఫ్‌లో ఉంచండి.

భ్రమణం మరియు రద్దు: పోయిన ల్యాప్‌టాప్ అభ్యాసం

సాధారణ SSH కీని రద్దు చేయడం అంటే, దానిని కలిగి ఉన్న ప్రతి సర్వర్‌లోని authorized_keys నుండి ఆ వరుసను తొలగించడమే. తెలియజేయడానికి ఎలాంటి సర్టిఫికేట్ అథారిటీ లేదు, గడువు తేదీ కోసం ఎదురుచూడాల్సిన అవసరం లేదు. ఆ వరుస తొలగించబడిన క్షణం నుండి, ఆ కీతో కొత్త లాగిన్‌లు విఫలమవుతాయి.

ఇది అత్యవసర పరిస్థితి కానప్పుడు, ఈ అభ్యాసాన్ని ఇప్పుడే చేయండి. ఒక సర్వర్‌ను ఎంచుకోండి, ~/.ssh/authorized_keys తెరండి, మరియు కీని దాని వ్యాఖ్య ద్వారా గుర్తించండి. ఎడిటర్‌తో ఆ వరుసను తొలగించండి, లేదా వ్యాఖ్య ద్వారా దానిని ఫిల్టర్ చేయండి:

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

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

భ్రమణం అనేది వేరే క్రమంలో ఉన్న అదే కార్యకలాపం: పరికరంలో కొత్త కీని సృష్టించండి, దానిని ssh-copy-id తో ఇన్‌స్టాల్ చేయండి, కొత్త కీ లాగిన్ అవుతుందని నిర్ధారించుకోండి, తర్వాత పాత వరుసను తొలగించండి. ఒక పరికరం చేతులు మారినప్పుడు, కీ బహిర్గతం అయ్యి ఉండవచ్చునప్పుడు, లేదా ఎవరైనా బృందాన్ని విడిచిపెట్టినప్పుడు దీన్ని చేయండి. రెండు సర్వర్‌లలో దీన్ని మాన్యువల్‌గా చేయడం సరే; ఇరవై సర్వర్‌లలో అది ఆటోమేషన్ పని, మరియు బహుళ లినక్స్ సర్వర్‌లను నిర్వహించడం ఒకే పోలిన authorized_keys స్థితిని మొత్తం ఫ్లీట్‌కు ఎలా పంపాలో చూపిస్తుంది.

చేయకూడనివి

• అన్ని పరికరాల్లో ఒకే ప్రైవేట్ కీని పంచుకోవద్దు. ప్రతిచోటా కీని భర్తీ చేయకుండా ఒకే దొంగిలించబడిన పరికరాన్ని రద్దు చేయడం అసాధ్యమవుతుంది.

• ప్రైవేట్ కీని git రిపోజిటరీకి కమిట్ చేయవద్దు, అది ప్రైవేట్ అయినా సరే. ఆటోమేటెడ్ స్కానర్లు పబ్లిక్ రిపోజిటరీలను గమనిస్తూ ఉంటాయి. పుష్ చేసిన కొద్ది నిమిషాల్లోనే లీక్ అయిన కీలను ప్రయత్నిస్తాయి. తరువాత పబ్లిక్‌గా మార్చబడిన రిపోజిటరీ దాని మొత్తం చరిత్రను లీక్ చేస్తుంది.

• మరొక సర్వర్‌ను చేరుకోగలగడానికి మీ లాప్‌టాప్ ప్రైవేట్ కీని సర్వర్‌కు అప్‌లోడ్ చేయవద్దు. సర్వర్‌లోనే ప్రత్యేక కీని ఉత్పత్తి చేయండి. ఆ కీని అవసరమైన చోట అధికారికంగా మాత్రమే అనుమతించండి.

• ప్రైవేట్ కీని చాట్, ఇమెయిల్ లేదా టికెట్‌లో పేస్ట్ చేయవద్దు. పబ్లిక్ కీ, అంటే .pub ఫైలు, పంచుకోబడే ఏకైక భాగం.

మీ కీ మీకు నమ్మకంగా లాగిన్ చేయించగానే, తదుపరి అడుగు వేసి పాస్‌వర్డ్ ప్రామాణీకరణను ఆపేయండి. దీనివల్ల మీ సర్వర్‌పై నిరంతరం జరిగే అంచనా వేయడాలు అసలు విజయవంతం కాలేవు. దాని కోసం డ్రాప్-ఇన్ కాన్ఫిగరేషన్ VPSలో SSH హార్డెనింగ్లో ఉంది.

FAQ

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

సర్వర్ మీ పబ్లిక్ కీని ~/.ssh/authorized_keys లో కలిగి ఉంటుంది. లాగిన్ సమయంలో అది ఒక సవాలును పంపుతుంది. మీ క్లయింట్ ఆ సవాలును ప్రైవేట్ కీతో సంతకం చేస్తుంది. సర్వర్ ఆ సంతకాన్ని పబ్లిక్ కీతో నిర్ధారిస్తుంది. ప్రైవేట్ కీ మీ పరికరం నుండి ఎప్పుడూ బయటకు వెళ్ళదు. కాబట్టి ప్రసారంలో స్వాధీనం చేసుకోవడానికి ఏమీ ఉండదు. సర్వర్ నుండి దొంగిలించడానికి మళ్ళీ వాడగలిగేది కూడా ఏమీ ఉండదు. చెదురుమంది సర్వర్ కేవలం పబ్లిక్ కీలను మాత్రమే లీక్ చేస్తుంది. వాటిని ఎక్కడా లాగిన్ కావడానికి వాడలేరు.

నా అన్ని సర్వర్‌ల కోసం ఒకే SSH కీని వాడాలా?

ఒక కీ ఒకే పరికరంలో ఉంటే, అనేక సర్వర్‌లలో ఒకే కీని వాడటం సరైనదే. నియమం పరికరానికి ఒక కీ, సర్వర్‌కు ఒకటి కాదు. మీ లాప్‌టాప్ పబ్లిక్ కీ దానికి అవసరమైన ప్రతి సర్వర్‌లో ఉంచండి. మీ డెస్క్‌టాప్‌కు దాని స్వంత కీ ఉంటుంది. ఇది రద్దును సులభతరం చేస్తుంది. ఒక పరికరం పోవడం అంటే ప్రతి సర్వర్ నుండి ఒక గుర్తించదగిన వరుసను తొలగించడం అని అర్థం. మిగతా పరికరాలు పనిచేస్తూనే ఉంటాయి.

.ssh డైరెక్టరీ మరియు authorized_keys‌కు ఏ అనుమతులు ఉండాలి?

~/.ssh పై 700 సెట్ చేయండి. authorized_keys పై మరియు ప్రతి ప్రైవేట్ కీ పై 600 సెట్ చేయండి. వాటిని వాడే ఖాతాకు యాజమాన్యం ఉండాలి. sshd డిఫాల్ట్‌గా StrictModes yes తో నడుస్తుంది. కాబట్టి మీకు తప్ప మరెవరైనా రాయగలిగే ఫైల్ లేదా హోమ్ డైరెక్టరీ ఉంటే, అది మీ కీని నిశ్శబ్దంగా విస్మరిస్తుంది. సర్వర్ యాథ్ లాగ్ లేదా జర్నల్‌లో Authentication refused: bad ownership or modes మాత్రమే ఆధారం మిగులుతుంది.

సర్వర్ నుండి SSH కీని ఎలా తొలగించాలి?

కీకి అధికారం ఇచ్చిన ఖాతాలో ~/.ssh/authorized_keys నుండి ఆ కీ వరుసను తొలగించండి. సరైన వరుసను దాని వ్యాఖ్య ద్వారా, అంటే కీ మెటీరియల్ తర్వాత ఉన్న లేబుల్ ద్వారా కనుగొనండి. ఆ కీతో కొత్త లాగిన్‌లు వెంటనే విఫలమవుతాయి. కానీ ఇప్పటికే తెరిచిన సెషన్‌లు అలాగే ఉంటాయి. కాబట్టి ఆ పరికరం దొంగిలించబడితే, దాని ప్రత్యక్ష సెషన్‌లను కూడా మూసివేయండి. ఆ కీ కాపీ చేయబడిన ప్రతి సర్వర్‌లో ఇదే చేయండి.

నా SSH కీపై పాస్‌ఫ్రేజ్ అవసరమా?

లాప్‌టాప్ లేదా డెస్క్‌టాప్‌లో ఉన్న కీకి, అవును. పాస్‌ఫ్రేజ్ కీ ఫైల్‌ను ఎన్‌క్రిప్ట్ చేస్తుంది. కాబట్టి దొంగిలించబడిన లేదా లీక్ అయిన కాపీ ఒంటరిగా పనికిరాదు. ssh-agent అంటే ప్రతి కనెక్షన్‌కు కాకుండా ఒక్క సెషన్‌కు ఒకసారి టైప్ చేయాలి. సర్వర్‌లో ఎవరి పర్యవేక్షణ లేకుండా నడిచే ఆటోమేషన్ వాడే కీలకు సాధారణంగా పాస్‌ఫ్రేజ్ ఉండదు. ఎందుకంటే టైప్ చేయడానికి ఎవరూ ఉండరు. టార్గెట్ ఖాతా ఏమి చేయగలదో పరిమితం చేయడం ద్వారా వాటిని రక్షించండి.