SSH Permission denied (publickey) त्रुटी कशी दुरुस्त करावी

Permission denied (publickey) याचा नेमका अर्थ

Permission denied (publickey) याचा अर्थ असा की तुमच्या client ने एक किंवा अधिक public keys पाठवल्या; मात्र server ने त्यांपैकी एकही स्वीकारली नाही. Network व्यवस्थित आहे आणि sshd चालू आहे. नकार authentication च्या अंतिम टप्प्यावर मिळतो. उपाय अंदाजाने शोधण्याची गरज नाही, कारण ssh -v यावरून पाचपैकी कोणते कारण लागू आहे ते समजते.

कंसातील शब्द server ने स्वीकारण्यास तयार असलेल्या authentication पद्धती दर्शवतात. Permission denied (publickey) एवढेच दिसत असल्यास त्या server वर password login बंद आहे. त्यामुळे password चा पर्याय उपलब्ध नसतो. Permission denied (publickey,password) दिसत असल्यास password login उपलब्ध होते आणि त्या पद्धतीनेही authentication अयशस्वी झाले.

एकाच संदेशामागे पाच वेगवेगळ्या त्रुटी असू शकतात. हा संदेश जाणूनबुजून अस्पष्ट ठेवला आहे. "no such user" किंवा "that key is not installed" असा प्रतिसाद दिल्यास वैध account शोधणाऱ्या व्यक्तीला मदत होईल. त्यामुळे लगेच keys बदलू नका किंवा config files संपादित करू नका. एक command चालवा आणि output मधील तीन ओळी वाचा. त्यानंतर पाच संभाव्य कारणांपैकी एकच कारण उरेल.

प्रथम 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 ही key वापरण्यापूर्वी server कडून पाठवली जाणारी स्वीकारलेल्या methods ची यादी आहे. त्या पहिल्या यादीत publickey नसल्यास, server वर public key login बंद आहे. त्यामुळे कोणतीही key कार्य करू शकत नाही.

Offering public key: ... ही client ने प्रत्यक्ष पाठवलेल्या प्रत्येक 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 ने कनेक्ट होत आहात

हे सर्वात सामान्य कारण आहे आणि तपासण्यासाठी सर्वात सोपेही आहे. SSH (secure shell) server daemon असलेला sshd खाते अस्तित्वात नाही असे कधीही सांगत नाही. तो काल्पनिक username साठी संपूर्ण विनिमय प्रक्रिया चालवतो आणि शेवटी त्याच संदेशासह नकार देतो, कारण वैध account names उघड झाल्यास हल्लेखोराला मदत होते. username मधील टायपोमुळे key खराब असल्यासारखेच दिसते.

इतर काहीही करण्यापूर्वी Authenticating to ... as ओळ तपासा. त्यात server account ऐवजी तुमच्या laptop login चे नाव असल्यास, command मध्ये username दिलेले नाही.

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

तुमचा provider तयार करत असलेल्या image वर default account अवलंबून असतो. August 2026 पर्यंत Ubuntu cloud images मध्ये साधारणपणे ubuntu account असते, Debian images मध्ये debian किंवा admin असते, Rocky Linux आणि AlmaLinux मध्ये rocky आणि almalinux असतात, तर अनेक VPS providers तुमची key थेट root मध्ये install करतात. Provider चे control panel त्याने तयार केलेले account नोंदवते. Server च्या बाहेरून चालवलेली कोणतीही command त्याला विचारू शकत नाही.

~/.ssh/config मधील Host block देखील username सेट करतो. या block ला तुमच्या local login name पेक्षा प्राधान्य मिळते:

Host vps-prod
  HostName 203.0.113.10
  User deploy

तुम्ही account स्वतः तयार केले आणि त्यानंतर त्याने login करता आले नाही, तर key बहुधा image च्या default user साठी install झाली होती आणि त्या account मध्ये कॉपी केली गेली नव्हती. हा टप्पा नवीन VPS वरील पहिल्या दहा मिनिटांचा भाग आहे आणि तो सहजपणे वगळला जाऊ शकतो.

कारण 2: तुम्हाला पाठवायची वाटत असलेली key प्रत्यक्षात पाठवली जात नाही

मुलभूतरित्या ssh ssh-agent कडे असलेल्या keys आणि ~/.ssh मधील ठरावीक filenames मधील keys वापरून पाहतो: 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 शेवटी वापरून पाहतो. हे महत्त्वाचे आहे, कारण server प्रत्येक नाकारलेली key MaxAuthTries च्या मर्यादेत मोजतो. या मर्यादेचे default मूल्य 6 आहे. Agent मध्ये सात keys असल्यास योग्य key वापरून पाहण्यापूर्वीच मर्यादा संपते आणि संदेश पुढीलप्रमाणे बदलतो:

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 वापरून त्या काढून टाका. पुढील login वेळी flags लक्षात ठेवण्याची गरज पडू नये म्हणून settings जतन करा:

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

Client-side आणखी एक अडथळा असतो. तुमच्या स्वतःच्या 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: सार्वजनिक key अधिकृत authorized_keys पर्यंत पोहोचली नाही

ssh -v मध्ये key बाहेर पाठवली जात असल्याचे दिसत असेल आणि सर्व्हर तरीही नकार देत असेल, तर पुढील प्रश्न असा आहे की ती key त्या account च्या authorized_keys फाइलमध्ये आहे का. तपासणीसाठी तुमच्या provider चे console उघडा, कारण पाहण्यासाठी SSH द्वारे login करता येणार नाही.

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

authorized_keys फाइलवर ssh-keygen -lf चालवल्यास प्रत्येक entry साठी एक fingerprint दाखवला जातो:

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

त्यांची तुमच्या Offering public key line वरील fingerprint शी तुलना करा. ती यादीत नसेल, तर तुम्ही काय केले असे आठवत असले तरी ती key त्या account वर install झालेली नाही.

हे चार प्रकारे चुकू शकते. हे सर्व प्रकार सामान्य आहेत:

• तुम्ही .pub फाइलऐवजी private key paste केली. Public key line ssh-ed25519 किंवा ssh-rsa ने सुरू होते. Private key -----BEGIN OPENSSH PRIVATE KEY----- ने सुरू होते.
• Paste करताना मजकूर अनेक lines मध्ये विभागला गेला. प्रत्येक entry नेमक्या एका line वर असणे आवश्यक आहे. त्यामुळे विभागलेली key अनेक तुटलेल्या entries म्हणून वाचली जाते आणि कोणत्याही entry शी जुळत नाही.
• तुम्ही key /root/.ssh/authorized_keys मध्ये ठेवली, पण login deploy म्हणून करता, किंवा उलट. ही 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 तेच काम करते आणि modes तुमच्यासाठी योग्य प्रकारे सेट करते.

कारण 4: permissions खूप खुले असल्यास sshd authorized_keys कडे दुर्लक्ष का करतो

StrictModes yes हे sshd चे default आहे. त्यानुसार, .ssh directory किंवा account च्या home directory मध्ये owner व्यतिरिक्त इतर कोणालाही write करता येत असल्यास sshd authorized_keys वाचण्यास नकार देतो. कारण स्पष्ट आहे: तुमच्या home directory मध्ये group किंवा world ला write करता येत असल्यास, त्या प्रवेशासह कोणतेही account authorized_keys बदलून login वर नियंत्रण मिळवू शकते. sshd अविश्वसनीय path कडे key अस्तित्वातच नाही अशा प्रकारे पाहतो.

Client ला साधा Permission denied संदेश दिसतो. 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 कोणती रचना स्वीकारेल:

• Home directory: group-writable आणि world-writable नसावी. 755, 750 आणि 700 तिन्ही योग्य आहेत. 775 आणि 777 अयशस्वी ठरतात.
• ~/.ssh: mode 700.
• ~/.ssh/authorized_keys: mode 600.
• Ownership: या तिन्हींचा owner तुम्ही ज्या account ने login करता तेच account असावे; root नसावे.

Mode इतकेच ownership देखील महत्त्वाचे आहे. /home/deploy/.ssh मधील root च्या मालकीची file ही त्याच तपासणीत अयशस्वी ठरते. sudo nano वापरून ती तयार केल्यानंतर 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 वर suspects च्या यादीत SELinux (security-enhanced Linux) देखील समाविष्ट करा. असामान्य पद्धतीने तयार केलेल्या .ssh directory ला चुकीचा file label लागू होऊ शकतो. त्यामुळे modes योग्य दिसत असले तरी sshd ला read access नाकारला जातो. sudo restorecon -Rv /home/deploy/.ssh labels पुन्हा लागू करते आणि sudo ausearch -m avc -ts recent नकार देणारा component SELinux होता का ते दाखवते.

कारण 5: sshd ने तुमचा प्रवेश नाकारण्यासाठी configuration केले आहे

सध्याच्या Ubuntu किंवा Debian system वर /etc/ssh/sshd_config वाचणे पुरेसे नाही. ही file Include /etc/ssh/sshd_config.d/*.conf ने सुरू होते आणि कोणत्याही setting साठी OpenSSH ला सापडलेली पहिली value लागू होते. त्यामुळे 50-cloud-init.conf सारखी drop-in file आधी वाचली जाते आणि मुख्य file मध्ये नंतर केलेल्या कोणत्याही edit वर तीच लागू होते. म्हणून edit योग्य दिसू शकतो, पण प्रत्यक्षात कोणताही बदल होत नाही.

sshd प्रत्यक्षात वापरत असलेली configuration पाहण्यासाठी हा command चालवा:

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 पूर्णपणे दुर्लक्षित केली जाते आणि cause 4 मधील mode rules नव्या path वर लागू होतात.
• allowusers किंवा allowgroups उपलब्ध आहे. यादीत नसलेल्या कोणत्याही account ला हाच error आणि कोणतेही explanation न देता नाकारले जाते. denyusers आणि denygroups याच्या उलट पद्धतीने तेच करतात.
• तुम्ही root म्हणून login करण्याचा प्रयत्न करत असताना permitrootlogin no. prohibit-password ही उपयुक्त मधली setting आहे: root key वापरू शकतो, पण password वापरू शकत नाही.

साध्या sshd -T मध्ये Match blocks दिसत नाहीत, कारण त्यांचा परिणाम कोण connection करत आहे यावर अवलंबून असतो. विशिष्ट 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 सेट केल्यास जुन्या signatures पुन्हा सुरू होतात आणि आजच्या दिवशी प्रवेश मिळतो. त्यामुळे याकडे server पर्यंत पोहोचण्याचा तात्पुरता उपाय म्हणून पाहा; हे अंतिम समाधान नाही. Server-side settings मधील उर्वरित महत्त्वाच्या बाबी VPS वरील SSH server hardening मध्ये दिल्या आहेत.

खासगी key ही स्थापित public key शी जुळते हे कसे सिद्ध करावे

या त्रुटीमध्ये होणाऱ्या बहुतेक अंदाजांचे कारण म्हणजे दोन फाइल्स एकाच जोडीतील आहेत की नाही हे माहीत नसणे. एक command याचे उत्तर देतो:

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

यामुळे खासगी key मधून तयार केलेली public key दिसते. तो शेजारील .pub फाइल कधीही वाचत नाही. त्यामुळे जुन्या .pub फाइलमध्ये दिलेल्या माहितीकडे न पाहता खासगी key प्रत्यक्षात कोणती आहे हे समजते. key ला passphrase असल्यास command तो विचारतो. त्यामुळे passphrase अजूनही तुम्हाला माहीत आहे हेही सिद्ध होते.

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

पहिला command एका public key file चा fingerprint दाखवतो. दुसरा command agent कडे असलेल्या key चे fingerprints दाखवतो. आता त्याच string चे चार views एकमेकांशी जुळवा: ssh -v मधील Offering public key ओळीवरील fingerprint, तुमच्या .pub file चा fingerprint, सर्व्हरच्या authorized_keys वरील ssh-keygen -lf मधील fingerprints आणि सर्व्हर log मधील fingerprint. ज्या ठिकाणी हे जुळणे थांबते, तीच तुमची चूक आहे.

लॉगिन अयशस्वी होत असताना सर्व्हर लॉग वाचा

क्लायंटला मुद्दाम कोणतीही उपयुक्त माहिती दिली जात नाही. सर्व्हर खरे कारण लॉगमध्ये लिहितो. कन्सोल सत्रावर लॉग follower सुरू करा आणि त्यानंतर तुमच्या laptop वरून अयशस्वी होणारी ssh कमांड चालवा.

sudo journalctl -u ssh -f

Ubuntu 24.04 मध्ये rsyslog default ने install केलेले नसते. त्यामुळे तेथे /var/log/auth.log उपलब्ध नसेल. Rocky Linux आणि AlmaLinux मध्ये unit चे नाव sshd असते आणि त्याच नोंदी /var/log/secure मध्येही लिहिल्या जातात.

sshd configuration मध्ये LogLevel VERBOSE सेट करा आणि सेवा reload करा. त्यानंतर प्रत्येक प्रयत्नात सर्व्हरला प्रत्यक्ष मिळालेली fingerprint लॉग केली जाते:

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

या ओळीवरून fault कोणत्या बाजूला आहे हे समजते. तुम्हाला ओळखता येणारी fingerprint दिसल्यास तुमची key सर्व्हरपर्यंत पोहोचली आहे आणि सर्व्हरने ती नाकारली आहे. त्यामुळे कारण 3, 4 आणि 5 तपासा. तुम्हाला न ओळखणारी fingerprint दिसल्यास तुमच्या client ने अपेक्षित नसलेली key पाठवली आहे. त्यामुळे कारण 2 कडे परत जा.

लॉगमधून अजूनही स्पष्ट माहिती मिळत नसेल, तर दुसऱ्या port वर debug mode मध्ये दुसरा sshd चालवा. तो foreground मध्ये राहतो, एक connection स्वीकारतो, त्याची कारणमीमांसा दाखवतो आणि नंतर बंद होतो:

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

त्याच सर्व्हरवरील कन्सोल सत्रातून loopback address द्वारे त्याला connect करा:

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

127.0.0.1 द्वारे connect केल्याने firewall या चाचणीच्या बाहेर राहतो. Debug output मध्ये उघडलेली file, जिच्याशी तुलना केली ती fingerprint आणि नकाराचे नेमके कारण दिसते. त्यात Authentication refused: bad ownership or modes for directory /home/deploy सारख्या ओळीही असू शकतात. उत्तर मिळाल्यावर 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 काहीही दाखवत नाही. file वैध नसल्यास ते file आणि line number दाखवते.
5. पहिले terminal बंद करण्यापूर्वी दुसरे terminal उघडा आणि नव्याने login करा. चुकीची configuration नवीन login थांबवते, पण विद्यमान session सुरू ठेवते. त्यामुळे तुम्ही ज्या 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

दुसऱ्या सर्व्हरवर तीच key कार्यरत असताना मला Permission denied (publickey) का मिळते?

कारण key योग्य आहे; तिच्याशी संबंधित इतर काहीतरी चुकीचे आहे. ssh -v चालवा आणि Offering public key ओळ शोधा. तुमची key सूचीमध्ये नसेल, तर ssh ने ती पाठवलीच नाही: default नावाखाली ती ~/.ssh मध्ये नाही किंवा ती agent मध्ये लोड केलेली नाही. त्यामुळे -i /path/to/key -o IdentitiesOnly=yes जोडा. key सूचीमध्ये असेल आणि सर्व्हर तरीही नकार देत असेल, तर ती key खात्याच्या authorized_keys मध्ये नाही, तिचा path group-writable आहे किंवा sshd config वापरकर्त्याला प्रतिबंधित करते. सर्व्हर log या कारणांमध्ये स्पष्ट फरक दाखवतो.

SSH प्रत्यक्षात कोणती key पाठवत आहे हे कसे पाहावे?

ssh -v host प्रत्येक key साठी एक debug1: Offering public key: ओळ दाखवते. प्रत्येक ओळीत source file आणि SHA256 fingerprint असतो. agent कडे असलेल्या key चे 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 ओळीतील fingerprint सर्व्हरच्या authorized_keys वर चालवलेल्या ssh-keygen -lf च्या output मध्येही दिसला पाहिजे.

sshd माझ्या authorized_keys file कडे दुर्लक्ष का करते?

कारण StrictModes हे default ने सुरू असते. File, .ssh directory किंवा home directory group किंवा world साठी writable असते, अथवा चुकीच्या खात्याच्या मालकीची असते. दुसरा कोणी बदलू शकणाऱ्या path वर sshd विश्वास ठेवत नाही. त्यामुळे कोणतीही key अस्तित्वात नसल्याप्रमाणे ते वागते. Home directory ची permission 755 किंवा त्याहून कडक ठेवा. .ssh ची permission 700, authorized_keys ची permission 600 ठेवा. या तिन्हींची मालकी login account कडे द्या. LogLevel VERBOSE वापरल्यास सर्व्हर Authentication refused: bad ownership or modes for directory /home/deploy/.ssh नोंदवतो.

सर्व्हर upgrade केल्यानंतर लगेच माझी key कार्य करणे थांबली. काय बदलले?

ती RSA key असल्यास, बहुधा SHA-1 मधील बदलामुळे असे झाले आहे. OpenSSH 8.8 ने ssh-rsa SHA-1 signatures default ने बंद केली. त्यामुळे केवळ त्या पद्धतीने sign करणारी key आता नाकारली जाते. Verbose client output मध्ये debug1: send_pubkey_test: no mutual signature algorithm दिसते. ssh-keygen -t ed25519 वापरून आधुनिक key तयार करा आणि तिची .pub file install करा. त्वरित access आवश्यक असल्यास, सर्व्हरवर PubkeyAcceptedAlgorithms +ssh-rsa जोडून जुनी signatures पुन्हा सुरू करता येतात. नवीन key कार्यरत झाल्यावर ती ओळ काढून टाका.

मी sshd_config संपादित केले आणि आता अजिबात login करू शकत नाही. पुन्हा access कसा मिळवू?

तुमच्या provider चे console वापरा. ते SSH मधून जात नाही. तेथे local password ने login करा. Syntax error आणि त्याचा line number पाहण्यासाठी sudo sshd -t चालवा. बदल पूर्ववत करा आणि service restart करा. त्यानंतर चालू असलेल्या values ची पुष्टी करण्यासाठी sudo sshd -T तपासा. /etc/ssh/sshd_config.d/ मधील file मुख्य config वर overriding करत असू शकते. Local password नसल्यास, आधी console मधून root password reset करा. त्यानंतर file दुरुस्त करा.