SSH Permission denied (publickey) లోపాన్ని సరిచేయడం

Permission denied (publickey) అంటే వాస్తవంగా ఏమిటి

Permission denied (publickey) అంటే మీ client ఒకటి లేదా అంతకంటే ఎక్కువ public keys పంపింది, కానీ server వాటిలో దేనినీ అంగీకరించలేదు అని అర్థం. Network సరిగానే ఉంది మరియు sshd నడుస్తోంది. తిరస్కరణ authentication లోని చివరి దశలో జరుగుతోంది. పరిష్కారాన్ని ఊహించి ఎంచుకోవాల్సిన అవసరం లేదు, ఎందుకంటే ssh -v మీ వద్ద ఉన్న ఐదు కారణాల్లో ఏది వర్తిస్తుందో చూపిస్తుంది.

కుండలీకరణాల్లోని పదాలు server అంగీకరించడానికి సిద్ధంగా ఉన్న methods. Permission denied (publickey) మాత్రమే కనిపిస్తే, ఆ serverలో password login నిలిపివేయబడిందని అర్థం. కాబట్టి fallback గా ఉపయోగించడానికి password ఉండదు. Permission denied (publickey,password) అంటే passwords అందుబాటులో ఉన్నాయి, కానీ వాటితో కూడా authentication విఫలమైంది అని అర్థం.

ఒకే message ఐదు వేర్వేరు లోపాలను సూచిస్తుంది. ఇది ఉద్దేశపూర్వకంగా అస్పష్టంగా ఉంటుంది. Server "అలాంటి user లేదు" లేదా "ఆ key install చేయబడలేదు" అని ప్రత్యుత్తరం ఇస్తే, valid accounts కోసం వెతికే వారికి అది ఉపయోగపడుతుంది. కాబట్టి వెంటనే keys మార్చడం లేదా config files సవరించడం ప్రారంభించవద్దు. ఒక command నడిపి, output లోని మూడు lines చదవండి. అప్పుడు ఐదు సాధ్యమైన కారణాల్లో ఒకటే మిగులుతుంది.

ముందుగా ssh -v నడిపి, మూడు పంక్తులను పరిశీలించండి

విఫలమైన command ను మళ్లీ నడపండి. అందులో -v ను జోడించండి:

ssh -v deploy@203.0.113.10

కుదించినప్పటికీ వాస్తవికంగా కనిపించే output ఇలా ఉంటుంది:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

మీకు అవసరమైన మొత్తం సమాచారం ఈ మూడు పంక్తుల్లో ఉంటుంది.

Authenticating to 203.0.113.10:22 as 'deploy' వాస్తవంగా ఉపయోగించబడే username. మీరు ఉపయోగించాలనుకున్న username కాదు. command line, ~/.ssh/config లేదా మీ local login name ఆధారంగా ssh నిర్ణయించిన username ఇది.

Authentications that can continue: publickey server అంగీకరించే methods జాబితా. ఏ key ను ప్రయత్నించే ముందు ఈ జాబితా పంపబడుతుంది. మొదటి జాబితాలో publickey లేకపోతే, server public key login ను నిలిపివేసింది. అందువల్ల ఏ key కూడా పనిచేయదు.

మీ client వాస్తవంగా పంపిన ప్రతి key కు Offering public key: ... ఒక పంక్తిని చూపిస్తుంది. ఆ key వచ్చిన file పేరు మరియు దాని SHA256 fingerprint అందులో ఉంటాయి. Offering పంక్తి లేని key server కు ఎప్పుడూ పంపబడలేదు.

ఇప్పుడు సమస్యను రెండు భాగాలుగా విభజించండి:

• మీరు ఆశించిన key కు Offering public key పంక్తి లేదు. లోపం మీ machine లో ఉంది, ఎందుకంటే server మీ key ను అసలు చూడలేదు.
• Key offer చేయబడింది, కానీ మళ్లీ Authentications that can continue: publickey కనిపించింది. Server ఆ key ను స్వీకరించి తిరస్కరించింది. అందువల్ల లోపం server లో ఉంది.

క్రింద ఉన్న కారణాలను, అవి సమాధానంగా తేలే తరచుదనం ఆధారంగా క్రమబద్ధీకరించాం.

కారణం 1: మీరు తప్పు username తో connect అవుతున్నారు

ఇదే అత్యంత సాధారణ కారణం. అయితే ఇది పెద్దగా ఆసక్తికరమైన కారణం కాదు. SSH (secure shell) server daemon అయిన sshd, ఒక account ఉనికిలో లేదని ఎప్పుడూ చెప్పదు. ఊహించిన username కోసం మొత్తం exchange ను నిర్వహించి, చివర్లో అదే message తో నిరాకరిస్తుంది. చెల్లుబాటు అయ్యే account పేర్లు బయటపడితే attacker కు సహాయం అవుతుంది. username లోని typo కూడా key పని చేయకపోవడం లాగానే కనిపిస్తుంది.

ముందుగా Authenticating to ... as line ను పరిశీలించండి. అందులో server account కు బదులుగా మీ laptop login కనిపిస్తే, command లో username ఇవ్వలేదు.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

మీ provider build చేసిన image ఆధారంగా default account మారుతుంది. August 2026 నాటికి, Ubuntu cloud images సాధారణంగా ubuntu account ను ship చేస్తాయి. Debian images debian లేదా admin ను ship చేస్తాయి. Rocky Linux మరియు AlmaLinux వరుసగా rocky మరియు almalinux ను ship చేస్తాయి. అనేక VPS providers మాత్రం మీ key ను నేరుగా root లో install చేస్తారు. ఏ account ను సృష్టించిందో మీ provider control panel లో నమోదు చేసి ఉంటుంది. Server వెలుపల నుంచి run చేసే ఏ command కూడా దాన్ని అడగలేదు.

~/.ssh/config లోని Host block కూడా username ను సెట్ చేస్తుంది. ఇది మీ local login name కంటే ప్రాధాన్యత పొందుతుంది:

Host vps-prod
  HostName 203.0.113.10
  User deploy

మీరు account ను స్వయంగా సృష్టించి, తరువాత దానితో login చేయలేకపోతే, key image యొక్క default user కోసం install అయి ఉండవచ్చు. అది కొత్త VPS లో మొదటి పది నిమిషాల్లో చేయాల్సిన దశ. దాన్ని సులభంగా దాటవేయవచ్చు. కొత్త VPS లో మొదటి పది నిమిషాలు

కారణం 2: మీరు పంపుతున్నట్లు అనుకుంటున్న key అసలు పంపబడుతున్నది కాదు

డిఫాల్ట్‌గా ssh ssh-agent లో ఉన్న keys తో పాటు ~/.ssh లోని నిర్దిష్ట filenames సమితిని మాత్రమే అందిస్తుంది: id_ed25519, id_ecdsa, id_rsa మరియు వాటి hardware, DSA variants. ~/.ssh/vps-prod గా సేవ్ చేసిన key కు పేరు స్పష్టంగా ఇవ్వకపోతే ssh దాన్ని గుర్తించదు. అందుకే verbose output లో దానికి సంబంధించిన Offering public key line కనిపించదు.

ఆ file కు పేరు ఇవ్వండి. Agent keys దాని స్థానంలో ఉపయోగించబడకుండా ఆపండి:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

Agent లో keys ఉన్నప్పుడు -i ను మాత్రమే ఇవ్వడం సరిపోదు. ఎందుకంటే ssh ముందుగా agent keys ను, చివరగా పేరుతో ఇచ్చిన file ను అందిస్తుంది. ఇది ముఖ్యమైన విషయం. ప్రతి తిరస్కరించిన key ను server MaxAuthTries పరిమితిలో లెక్కిస్తుంది. దీని default విలువ 6. Agent లో ఏడు keys ఉంటే, మీ సరైన key ను ప్రయత్నించేలోపే ఆ పరిమితి పూర్తవుతుంది. అప్పుడు message ఇలా మారుతుంది:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

IdentitiesOnly=yes మీరు ఇచ్చిన file కు మాత్రమే ప్రయత్నాన్ని పరిమితం చేస్తుంది. Agent లో ప్రస్తుతం ఉన్న keys ను ssh-add -l తో జాబితా చేయండి. అది సంవత్సరాలుగా పేరుకుపోయిన పాత keys ను కలిగి ఉంటే ssh-add -D తో వాటిని తొలగించండి. తరువాత settings ను file లో నమోదు చేయండి. అప్పుడు తదుపరి login flags గుర్తుంచుకోవడంపై ఆధారపడదు:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

Client వైపు మరో సమస్య కూడా ఉంది. మీ స్వంత machine లోని ఇతర accounts చదవగలిగే private key ను ssh ఉపయోగించదు. అది warning చూపించి key ను విస్మరిస్తుంది. అందువల్ల key ఎప్పుడూ అందించబడదు, server కు కూడా కనిపించదు:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod దీనిని సరిచేస్తుంది. USB stick లేదా Windows share ద్వారా key ను తరలించడం వల్ల mode కోల్పోవడం సాధారణం. Keys ఎక్కడ ఉంచాలి, వాటికి ఏ పేర్లు ఇవ్వాలి అనే వివరాలు SSH key management ప్రాథమికాలు లో ఉన్నాయి.

కారణం 3: public key, authorized_keys కు చేరలేదు

ssh -v ద్వారా key బయటకు పంపబడుతున్నట్లు కనిపించినా, server ఇంకా నిరాకరిస్తే, ఆ key account కు చెందిన authorized_keys file లో ఉందా అనేది తదుపరి పరిశీలన. SSH ద్వారా login చేసి చూడలేరు కాబట్టి, పరిశీలించడానికి provider console ను తెరవండి.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

authorized_keys file పై ssh-keygen -lf అమలు చేస్తే ప్రతి entry కు ఒక fingerprint ముద్రించబడుతుంది:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

వాటిని మీ Offering public key line లోని fingerprint తో పోల్చండి. అది ఆ జాబితాలో లేకపోతే, మీరు చేసిన పని గుర్తున్నా, ఆ account లో key install కాలేదు.

ఇది తప్పుగా జరిగే నాలుగు సాధారణ విధానాలు:

• మీరు .pub file కు బదులుగా private key ను paste చేశారు. Public key line ssh-ed25519 లేదా ssh-rsa తో ప్రారంభమవుతుంది. Private key -----BEGIN OPENSSH PRIVATE KEY----- తో ప్రారంభమవుతుంది.
• Paste చేసిన text అనేక lines గా wrap అయింది. ప్రతి entry ఖచ్చితంగా ఒకే line లో ఉండాలి. అందువల్ల wrap అయిన key అనేక విరిగిన entries గా చదవబడుతుంది, ఏదితోనూ match కాదు.
• మీరు deploy గా login చేస్తున్నప్పుడు key /root/.ssh/authorized_keys లోకి వెళ్లింది, లేదా దీనికి విరుద్ధంగా జరిగింది. ఈ file ప్రతి account కు విడిగా ఉంటుంది. అందరికీ ఉమ్మడిగా ఉపయోగించే file ఉండదు.
• Provider యొక్క "add my key" box, key ను image యొక్క default user కు మాత్రమే రాసింది. అందువల్ల మీరు తరువాత సృష్టించిన account లో ఖాళీ .ssh directory ఉంది.

Console నుంచి root గా key జోడించడానికి సురక్షితమైన విధానం:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

తర్వాత మళ్లీ sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys అమలు చేయండి. కొత్త fingerprint ఇప్పుడు జాబితాలో ఉండాలి. Password తో ఇంకా login చేయగల machine నుంచి ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 అదే పని చేసి, permissions ను కూడా మీ కోసం సరైన విధంగా అమర్చుతుంది.

కారణం 4: permissions చాలా విస్తృతంగా ఉన్నప్పుడు sshd authorized_keys ను ఎందుకు పట్టించుకోదు

StrictModes yes అనేది sshd default. దాని ప్రకారం, .ssh directory లేదా account యొక్క home directory owner కాకుండా మరెవరైనా రాయగలిగితే, sshd authorized_keys ను చదవడానికి నిరాకరిస్తుంది. కారణం స్పష్టంగా ఉంది: మీ home directory కు group లేదా world write access ఉంటే, ఆ access కలిగిన ఏ account అయినా authorized_keys ను మార్చి login ను స్వాధీనం చేసుకోగలదు. విశ్వసించలేని path లో key ఏదీ లేనట్లుగా sshd పరిగణిస్తుంది.

Client కు సాధారణ Permission denied message కనిపిస్తుంది. Server log లో అసలు కారణం నమోదు అవుతుంది:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

లేదా సమస్య file లోనే ఉన్నప్పుడు:

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

sshd అంగీకరించే permissions:

• Home directory: group-writable కాకూడదు, world-writable కాకూడదు. 755, 750 మరియు 700 అన్నీ pass అవుతాయి. 775 మరియు 777 fail అవుతాయి.
• ~/.ssh: mode 700.
• ~/.ssh/authorized_keys: mode 600.
• Ownership: మూడు items కూడా మీరు login చేసే account కు చెందినవిగా ఉండాలి; root కు చెందినవిగా ఉండకూడదు.

Mode ఎంత ముఖ్యమో ownership కూడా అంతే ముఖ్యం. /home/deploy/.ssh లోని file root కు చెందినదైతే అదే check fail అవుతుంది. sudo nano తో file create చేసి, ownership ను తిరిగి అప్పగించడం మరిచిపోయినప్పుడు ఇది జరుగుతుంది. రెండింటినీ ఒకేసారి సరిచేయండి:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

చివరి command ఫలితాన్ని చూపిస్తుంది. Home directory పై drwxr-xr-x లేదా అంతకంటే కఠినమైన mode, అలాగే .ssh పై drwx------ ఉండాలి. ఆ strings ఇంకా స్పష్టంగా కనిపించకపోతే, live server లో modes మార్చే ముందు drwxr-xr-x వంటి permission string ను ఎలా చదవాలి చూడండి.

Rocky Linux మరియు AlmaLinux లో SELinux (security-enhanced Linux) ను కూడా పరిశీలించాల్సిన కారణాల జాబితాలో చేర్చండి. అసాధారణ మార్గంలో సృష్టించిన .ssh directory కు తప్పు file label ఉండవచ్చు. అందువల్ల modes సరైనట్లు కనిపించినా sshd కు read access నిరాకరించబడుతుంది. sudo restorecon -Rv /home/deploy/.ssh labels ను తిరిగి అమర్చుతుంది. SELinux నిరాకరణకు కారణమైన component కాదో sudo ausearch -m avc -ts recent చూపిస్తుంది.

కారణం 5: sshd మిమ్మల్ని నిరాకరించేలా configured గా ఉంది

ప్రస్తుత Ubuntu లేదా Debian system లో /etc/ssh/sshd_config చదవడం మాత్రమే సరిపోదు. ఆ file Include /etc/ssh/sshd_config.d/*.conf తో ప్రారంభమవుతుంది. ఏ setting కు సంబంధించిన మొదటి value ను OpenSSH ఉపయోగిస్తుంది. అందువల్ల 50-cloud-init.conf వంటి drop-in file ముందుగా చదవబడుతుంది. Main file లో దిగువన మీరు మార్చిన విలువలపై అదే పైచేయి సాధిస్తుంది. అందుకే చేసిన మార్పు సరైనదిగా కనిపించినా, ఎలాంటి ప్రభావం ఉండకపోవచ్చు.

sshd వాస్తవంగా ఉపయోగిస్తున్న configuration ను అడగండి:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

సరైన output ఇలా ఉంటుంది:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

మీ output లో ఈ అంశాలను పరిశీలించండి:

• pubkeyauthentication no. ఎలాంటి key ను అంగీకరించదు. ssh -v లో మొదటి Authentications that can continue: list గా ఇది కనిపించవచ్చు; అందులో publickey ఉండదు.
• authorizedkeysfile వేరే స్థానాన్ని సూచిస్తోంది, ఉదాహరణకు /etc/ssh/authorized_keys/%u. అప్పుడు home directory లోని మీ file పూర్తిగా విస్మరించబడుతుంది. కారణం 4లోని mode నియమాలు కొత్త path కు వర్తిస్తాయి.
• allowusers లేదా allowgroups ఉన్నాయి. List లో లేని account ఏదైనా ఇదే error తో, అదనపు వివరణ లేకుండా నిరాకరించబడుతుంది. denyusers మరియు denygroups దీనికి విరుద్ధంగా అదే పని చేస్తాయి.
• మీరు root గా login చేయడానికి ప్రయత్నిస్తున్నప్పుడు permitrootlogin no ఉంది. prohibit-password ఉపయోగకరమైన మధ్యస్థ setting: root key ను ఉపయోగించవచ్చు, కానీ password ను ఉపయోగించలేడు.

ఎవరు connect అవుతున్నారనే దానిపై ఫలితం ఆధారపడుతుంది కాబట్టి, సాధారణ sshd -T output లో Match blocks కనిపించవు. ఒక నిర్దిష్ట connection గురించి అడగండి:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

పాత keys పై మరో setting ప్రభావం చూపుతుంది. OpenSSH 8.8 SHA-1 signatures (ssh-rsa) ను default గా అంగీకరించడం నిలిపివేసింది. అందువల్ల సంవత్సరాలుగా పనిచేసిన RSA key, server upgrade చేసిన వెంటనే పనిచేయడం ఆపివేయవచ్చు. Client కారణాన్ని స్పష్టంగా చెబుతుంది:

debug1: send_pubkey_test: no mutual signature algorithm

సరైన పరిష్కారం కొత్త key సృష్టించడం: ssh-keygen -t ed25519 -C "deploy@vps-prod". తరువాత పైన చూపిన విధంగా .pub file ను install చేయండి. Server పై PubkeyAcceptedAlgorithms +ssh-rsa ను set చేస్తే పాత signatures మళ్లీ enable అవుతాయి మరియు ఈరోజు server లోకి ప్రవేశించవచ్చు. అయితే దీన్ని తాత్కాలికంగా server ను చేరుకునే మార్గంగా మాత్రమే పరిగణించండి; పనికి ముగింపుగా కాదు. Server-side లో సమీక్షించాల్సిన మిగతా ముఖ్యమైన settings VPSలో SSH server ను harden చేయడం లో ఉన్నాయి.

ఇన్‌స్టాల్ చేసిన public key కు private key సరిపోతుందని ఎలా నిర్ధారించాలి

రెండు ఫైళ్లు ఒకే జతకు చెందినవో తెలియకపోవడం వల్లే ఈ error పై ఎక్కువగా ఊహాగానాలు చేయాల్సి వస్తుంది. ఒక command దీనికి సమాధానం ఇస్తుంది:

ssh-keygen -y -f ~/.ssh/vps-prod

ఇది private key నుంచి ఉత్పన్నమైన public key ను ముద్రిస్తుంది. దాని పక్కన ఉన్న .pub file ను ఇది ఎప్పుడూ చదవదు. అందువల్ల పాత .pub file చెబుతున్నదాన్ని కాకుండా private key నిజంగా ఏదో ఇది చూపిస్తుంది. key కు passphrase ఉంటే command దాన్ని అడుగుతుంది. దీంతో ఆ passphrase మీకు ఇంకా తెలుసని కూడా నిర్ధారించవచ్చు.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

మొదటి command ఒక public key file యొక్క fingerprint ను ముద్రిస్తుంది. రెండో command మీ agent వద్ద ఉన్న keys యొక్క fingerprints ను ముద్రిస్తుంది. ఇప్పుడు అదే string కు సంబంధించిన నాలుగు రూపాలను సరిపోల్చండి: ssh -v నుంచి వచ్చిన Offering public key line లోని fingerprint, మీ .pub file యొక్క fingerprint, server లోని authorized_keys పై ఉన్న ssh-keygen -lf లోని fingerprints, మరియు server log లోని fingerprint. ఇవి సరిపోలడం ఆగే చోటే సమస్యకు కారణం ఉంటుంది.

లాగిన్ విఫలమైనప్పుడు server log ను పరిశీలించండి

Client కు ఉద్దేశపూర్వకంగా ఉపయోగకరమైన సమాచారం ఏదీ ఇవ్వబడదు. అసలు కారణాన్ని server log లో రాస్తుంది. Console session లో log follower ను ప్రారంభించి, మీ laptop నుంచి విఫలమవుతున్న ssh command ను అమలు చేయండి.

sudo journalctl -u ssh -f

Ubuntu 24.04 లో rsyslog default గా install కాదు. అందువల్ల అక్కడ /var/log/auth.log ఉండకపోవచ్చు. Rocky Linux మరియు AlmaLinux లో unit పేరు sshd. అదే records /var/log/secure లో కూడా చేరతాయి.

sshd configuration లో LogLevel VERBOSE ను సెట్ చేసి, service ను reload చేయండి. ఆ తర్వాత ప్రతి ప్రయత్నంలో server వాస్తవంగా స్వీకరించిన fingerprint log అవుతుంది:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

ఈ line fault ఏ వైపు ఉందో తెలియజేస్తుంది. మీకు తెలిసిన fingerprint కనిపిస్తే, మీ key server కు చేరి అక్కడ reject అయింది. అందువల్ల causes 3, 4 మరియు 5 ను పరిశీలించండి. మీకు తెలియని fingerprint కనిపిస్తే, మీరు ఉద్దేశించని key ను client పంపింది. అందువల్ల cause 2 కు తిరిగి వెళ్లండి.

Log ఇంకా స్పష్టంగా లేకపోతే, మరో port పై debug mode లో రెండవ sshd ను ప్రారంభించండి. అది foreground లోనే ఉంటుంది, ఒక connection ను అందిస్తుంది, తన నిర్ణయ ప్రక్రియను ముద్రించి, తరువాత exit అవుతుంది:

sudo /usr/sbin/sshd -ddd -p 2222

అదే server లోని console session నుంచి loopback address ద్వారా దానికి connect అవ్వండి:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

127.0.0.1 ద్వారా connect చేయడం వల్ల firewall ఈ test లో జోక్యం చేసుకోదు. Debug output అది తెరిచిన file, సరిపోల్చిన fingerprint, మరియు ఖచ్చితమైన refusal ను చూపిస్తుంది. ఇందులో Authentication refused: bad ownership or modes for directory /home/deploy వంటి lines కూడా ఉంటాయి. సమాధానం తెలిసినప్పుడు Ctrl+C నొక్కండి. ఈ ప్రక్రియలో port 22 పై ఉన్న అసలు sshd కు ఎలాంటి మార్పు ఉండదు.

తమను తాము సిస్టమ్‌ నుంచి బయటకు లాక్ చేసుకోకుండా ఉండటం

సర్వర్ configuration ను సవరించే ప్రతి దశకు SSHపై ఆధారపడని తిరిగి ప్రవేశ మార్గం ఉండాలి. SSH ఇంకా పనిచేస్తున్నప్పుడే దీన్ని సిద్ధం చేయండి; అది విఫలమైన తర్వాత కాదు.

1. మీ provider console ను serial లేదా VNC (virtual network computing) ద్వారా తెరిచి, అక్కడ login చేయగలరని నిర్ధారించండి.
2. sudo ఉన్న account కు పనిచేసే local password మీకు తెలుసని నిర్ధారించుకోండి. అది లేకపోతే ముందుగా provider console నుంచి root password ను reset చేయండి.
3. ప్రస్తుత SSH session ను తెరిచి ఉంచండి. తెరిచి ఉన్న session systemctl restart ssh ను తట్టుకుని కొనసాగుతుంది. అందువల్ల కొత్త configuration తప్పుగా ఉంటే అది తిరిగి ప్రవేశించడానికి ఒక మార్గంగా ఉంటుంది.
4. restart చేయడానికి ముందు syntax ను తనిఖీ చేయండి: file చెల్లుబాటు అయితే sudo sshd -t ఏమీ output ఇవ్వదు. చెల్లుబాటు కాకపోతే file మరియు line number ను చూపిస్తుంది.
5. మొదటి terminal ను మూసే ముందు రెండవ terminal తెరిచి కొత్తగా login చేయండి. తప్పు configuration కొత్త logins ను అడ్డుకుంటుంది, కానీ ఇప్పటికే ఉన్న వాటిని ప్రభావితం చేయదు. కాబట్టి మీరు ప్రస్తుతం ఉపయోగిస్తున్న session మార్పు పనిచేసిందో లేదో నిర్ధారించలదు.

Debian మరియు Ubuntu పై sudo systemctl restart ssh తో restart చేయండి. Rocky Linux మరియు AlmaLinux పై sudo systemctl restart sshd ఉపయోగించండి. Ubuntu 24.04 లో sshd socket unit నుంచి ప్రారంభమవుతుంది. కాబట్టి Port లేదా ListenAddress లో మార్పు చేసిన తర్వాత అది అమలులోకి రావడానికి sudo systemctl restart ssh.socket కూడా అవసరం.

FAQ

మరో serverలో అదే key పనిచేస్తున్నప్పుడు Permission denied (publickey) ఎందుకు వస్తుంది?

key సరిగానే ఉంది; దాని చుట్టూ ఉన్న configurationలో ఏదో సమస్య ఉంది. ssh -v ను అమలు చేసి Offering public key line ను గుర్తించండి. మీ key అక్కడ కనిపించకపోతే, ssh దాన్ని పంపలేదు: ఆ file default nameతో ~/.ssh లో లేదు లేదా agentలో load కాలేదు. అందువల్ల -i /path/to/key -o IdentitiesOnly=yes ను జోడించండి. key అక్కడ కనిపించినా server ఇంకా నిరాకరిస్తే, ఆ key account యొక్క authorized_keys లో లేదు, దానికి వెళ్లే path group-writableగా ఉంది, లేదా sshd config ఆ userను నిరోధిస్తోంది. ఈ పరిస్థితులను server log వేరు చేసి చూపిస్తుంది.

SSH వాస్తవంగా ఏ keyని పంపుతోందో ఎలా చూడాలి?

ssh -v host ప్రతి keyకి ఒక debug1: Offering public key: lineను ప్రింట్ చేస్తుంది. ప్రతి lineలో source file మరియు SHA256 fingerprint ఉంటాయి. agentలో ఉన్న fingerprintsను ssh-add -l చూపిస్తుంది. ఒకే key file యొక్క fingerprintను ssh-keygen -lf ~/.ssh/id_ed25519.pub ప్రింట్ చేస్తుంది. private key నుంచి వాస్తవంగా ఉత్పత్తి అయ్యే public keyని ssh-keygen -y -f ~/.ssh/id_ed25519 ప్రింట్ చేస్తుంది. Login విజయవంతం కావాలంటే, Offering lineలోని fingerprint server యొక్క authorized_keys పై అమలు చేసిన ssh-keygen -lf outputలో కూడా కనిపించాలి.

sshd నా authorized_keys fileను ఎందుకు పట్టించుకోవడం లేదు?

StrictModes defaultగా onలో ఉంటుంది. అలాగే file, .ssh directory లేదా home directory group లేదా world ద్వారా writableగా ఉండవచ్చు, లేదా తప్పు accountకు చెందినదై ఉండవచ్చు. మరెవరైనా మార్చగలిగే pathను sshd నమ్మదు. అందువల్ల key ఏదీ లేనట్టుగా ప్రవర్తిస్తుంది. Home directory permissionను 755 లేదా అంతకంటే కఠినంగా ఉంచండి. .ssh ను 700 కు, authorized_keys ను 600 కు సెట్ చేయండి. ఈ మూడు paths కూడా login account యాజమాన్యంలో ఉండాలి. LogLevel VERBOSE తో server Authentication refused: bad ownership or modes for directory /home/deploy/.ssh ను నమోదు చేస్తుంది.

Server upgrade చేసిన వెంటనే నా key పనిచేయడం ఆగిపోయింది. ఏమి మారింది?

అది RSA key అయితే, కారణం ఎక్కువగా SHA-1 మార్పే. OpenSSH 8.8 defaultగా ssh-rsa SHA-1 signaturesను నిలిపివేసింది. కాబట్టి ఆ పద్ధతిలో మాత్రమే sign చేయగల keyను ఇప్పుడు నిరాకరిస్తుంది. Verbose client outputలో debug1: send_pubkey_test: no mutual signature algorithm కనిపిస్తుంది. ssh-keygen -t ed25519 తో ఆధునిక keyను సృష్టించి, దాని .pub fileను install చేయండి. వెంటనే access అవసరమైతే, serverలో PubkeyAcceptedAlgorithms +ssh-rsa ను జోడించడం ద్వారా పాత signaturesను మళ్లీ enable చేయవచ్చు. కొత్త key పనిచేసిన వెంటనే ఆ lineను తొలగించాలి.

నేను sshd_configను సవరించిన తర్వాత అసలు login చేయలేకపోతున్నాను. తిరిగి ఎలా ప్రవేశించాలి?

SSH ద్వారా వెళ్లని మీ provider consoleను ఉపయోగించండి. అక్కడ local passwordతో login చేసి, syntax error మరియు దాని line number చూడడానికి sudo sshd -t ను అమలు చేయండి. చేసిన మార్పును undo చేసి serviceను restart చేయండి. తరువాత ప్రస్తుతం అమలులో ఉన్న valuesను నిర్ధారించడానికి sudo sshd -T ను పరిశీలించండి. ఎందుకంటే /etc/ssh/sshd_config.d/ లోని file ప్రధాన configను override చేసి ఉండవచ్చు. Local password లేకపోతే, ముందుగా console నుంచి root passwordను reset చేసి, తరువాత fileను సరిచేయండి.