SSH Permission denied (publickey) பிழையை சரி செய்வது

Permission denied (publickey) என்பதன் உண்மையான பொருள்

Permission denied (publickey) என்பது, உங்கள் client ஒன்று அல்லது அதற்கு மேற்பட்ட public keys-ஐ அனுப்பியதாகவும், server எதையும் ஏற்கவில்லை என்பதையும் குறிக்கிறது. Network சரியாக உள்ளது மற்றும் sshd இயங்கிக்கொண்டிருக்கிறது: authentication-ன் கடைசி கட்டத்தில்தான் இந்த மறுப்பு நிகழ்கிறது. இதற்கான தீர்வை ஊகித்துச் செய்யக்கூடாது, ஏனெனில் ssh -v உங்களுக்கு இருக்கும் ஐந்து காரணங்களில் எது என்பதைத் தெரிவிக்கும்.

அடைப்புக்குறிக்குள் உள்ள சொற்கள், server ஏற்கத் தயாராக இருந்த முறைகளைக் குறிக்கின்றன. Permission denied (publickey) மட்டும் இருந்தால், அந்த server-ல் password login முடக்கப்பட்டுள்ளது என்று பொருள், எனவே மீண்டும் முயற்சி செய்ய password வசதி இல்லை. Permission denied (publickey,password) என்பது, password வசதி வழங்கப்பட்டும் நீங்கள் அதில் தோல்வியடைந்துள்ளீர்கள் என்பதைக் குறிக்கிறது.

இந்த ஒரு செய்தி ஐந்து வெவ்வேறு பிழைகளை உள்ளடக்கியது, இது வேண்டுமென்றே தெளிவற்றதாக வைக்கப்பட்டுள்ளது. "no such user" அல்லது "that key is not installed" என்று server பதில் அளித்தால், அது செல்லுபடியாகும் கணக்குகளைத் தேடும் நபர்களுக்கு உதவியாக இருக்கும். எனவே, keys-ஐ மாற்றுவதையோ அல்லது config files-ஐத் திருத்துவதையோ செய்யாதீர்கள். ஒரே ஒரு command-ஐ இயக்கி, மூன்று வரிகள் கொண்ட output-ஐப் படியுங்கள்; அப்போது ஐந்து சாத்தியமான காரணங்களில் ஒன்று மட்டும் எஞ்சியிருக்கும்.

முதலில் ssh -v கட்டளையை இயக்கி, மூன்று வரிகளைப் படிக்கவும்

தோல்வியடைந்த கட்டளையை, -v சேர்த்து மீண்டும் இயக்கவும்:

ssh -v deploy@203.0.113.10

சுருக்கப்பட்ட ஆனால் யதார்த்தமான ஒரு வெளியீடு இவ்வாறு இருக்கும்:

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) ஆகும். நீங்கள் பயன்படுத்த நினைத்த பெயர் அல்ல: கட்டளை வரி (command line), ~/.ssh/config, அல்லது உங்கள் உள்ளூர் login பெயர் ஆகியவற்றிலிருந்து ssh கண்டறிந்த பெயர் இது.

Authentications that can continue: publickey என்பது சர்வர் ஏற்கும் அங்கீகார முறைகளின் பட்டியல்; எந்தவொரு சாவியும் (key) அனுப்பப்படுவதற்கு முன்பே இது அனுப்பப்படும். அந்த முதல் பட்டியலில் publickey இல்லையென்றால், சர்வரில் public key login முடக்கப்பட்டுள்ளது என்று அர்த்தம், எனவே எந்தச் சாவியும் வேலை செய்யாது.

Offering public key: ... என்பது உங்கள் client அனுப்பிய ஒவ்வொரு சாவிக்கும் ஒரு வரியைக் குறிக்கும்; அது எந்தக் கோப்பிலிருந்து வந்தது மற்றும் அதன் SHA256 fingerprint ஆகியவற்றை இது காட்டும். Offering வரி இல்லாத ஒரு சாவி சர்வர்க்கு அனுப்பப்படவில்லை என்று பொருள்.

இப்போது சிக்கலை இரண்டாகப் பிரிக்கவும்:

• நீங்கள் எதிர்பார்க்கும் சாவிக்கு Offering public key வரி இல்லை. உங்கள் கணினியிலேயே தவறு உள்ளது, ஏனெனில் சர்வர் உங்கள் சாவியைப் பார்க்கவே இல்லை.
• சாவி வழங்கப்படுகிறது, ஆனால் மீண்டும் Authentications that can continue: publickey வருகிறது. சர்வர் அந்தச் சாவியைப் பெற்றுக்கொண்டது, ஆனால் அதை நிராகரித்துவிட்டது; எனவே தவறு சர்வர் பக்கத்தில் உள்ளது.

கீழே கொடுக்கப்பட்டுள்ள காரணங்கள், அவை பெரும்பாலும் தீர்வாக அமையும் வரிசையில் வரிசைப்படுத்தப்பட்டுள்ளன.

காரணம் 1: நீங்கள் தவறான பயனர் பெயரில் (username) நுழைய முயல்கிறீர்கள்

மிகவும் பொதுவான இந்த காரணம், கவனிக்கப்படாமல் விடப்படும் ஒன்றாகும். SSH server daemon-ஆன sshd, ஒரு கணக்கு இல்லை என்று ஒருபோதும் வெளிப்படையாகக் கூறாது. ஒரு தவறான பயனர் பெயருக்குக் கூட அது முழு பரிமாற்றத்தையும் நடத்திவிட்டு, இறுதியில் அதே பிழைச் செய்தியைக் காட்டும். ஏனெனில், சரியான பயனர் பெயர்களை வெளிப்படுத்துவது தாக்குதல் நடத்துபவர்களுக்கு உதவியாக இருக்கும். பயனர் பெயரில் உள்ள ஒரு சிறிய எழுத்துப் பிழை, உடைந்த key இருப்பது போன்ற தோற்றத்தையே தரும்.

எதையும் சரிபார்க்கும் முன் Authenticating to ... as வரியைச் சரிபார்க்கவும். அதில் உங்கள் server கணக்கிற்குப் பதிலாக உங்கள் laptop-ன் பயனர் பெயர் இருந்தால், நீங்கள் command-ல் பயனர் பெயரைத் தவறவிட்டுள்ளீர்கள் என்று அர்த்தம்.

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

இயல்புநிலை (default) கணக்கு, உங்கள் சேவை வழங்குநர் (provider) உருவாக்கும் image-ஐப் பொறுத்தது. ஆகஸ்ட் 2026 நிலவரப்படி, Ubuntu cloud images பொதுவாக ubuntu கணக்கையும், Debian images debian அல்லது admin கணக்கையும், Rocky Linux மற்றும் AlmaLinux ஆகியவை rocky மற்றும் almalinux கணக்குகளையும் கொண்டுள்ளன. பல VPS வழங்குநர்கள் உங்கள் key-ஐ நேரடியாக root கணக்கில் நிறுவுகின்றனர். உங்கள் சேவை வழங்குநரின் control panel-ல் எந்தக் கணக்கு உருவாக்கப்பட்டது என்பது பதிவாகியிருக்கும். server-க்கு வெளியே இருந்து இயக்கும் எந்த command-ஆலும் இதைக் கண்டறிய முடியாது.

~/.ssh/config கோப்பில் உள்ள ஒரு Host தொகுதியும் பயனர் பெயரை நிர்ணயிக்கும்; இது உங்கள் உள்ளூர் login பெயரை விட முன்னுரிமை பெறும்:

Host vps-prod
  HostName 203.0.113.10
  User deploy

நீங்கள் ஒரு கணக்கை நீங்களே உருவாக்கிவிட்டு, அதில் நுழைய முடியவில்லை என்றால், அந்த key பெரும்பாலும் image-ன் இயல்புநிலை பயனருக்காகவே நிறுவப்பட்டிருக்கலாம், உங்கள் கணக்கிற்கு நகலெடுக்கப்படாமல் இருந்திருக்கலாம். அந்தப் படிநிலை புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற வழிகாட்டியில் உள்ளது, அதைத் தவறுவது எளிது.

காரணம் 2: நீங்கள் அனுப்புவதாக நினைக்கும் key, உண்மையில் அனுப்பப்படும் key அல்ல

இயல்பாக, ssh ஆனது ssh-agent-ல் உள்ள keys-ஐயும், ~/.ssh-ல் உள்ள குறிப்பிட்ட சில கோப்புப் பெயர்களையும் மட்டுமே வழங்குகிறது: id_ed25519, id_ecdsa, id_rsa, மற்றும் அவற்றின் hardware மற்றும் DSA வகைகள். ~/.ssh/vps-prod எனச் சேமிக்கப்பட்ட ஒரு key-ஐ நீங்கள் குறிப்பிடும் வரை ssh-ஆல் அதைக் காண முடியாது; இதனால்தான் verbose output-ல் அதற்கான Offering public key வரி காட்டப்படுவதில்லை.

கோப்பின் பெயரைத் தெளிவாகக் குறிப்பிடவும், agent-ல் உள்ள keys அதற்குப் பதிலாகத் தேர்வாகாமல் தடுக்கவும்:

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

Agent-ல் keys இருக்கும்போது -i-ஐ மட்டும் பயன்படுத்துவது போதாது, ஏனெனில் ssh முதலில் agent-ன் keys-ஐயும், கடைசியாகவே நீங்கள் குறிப்பிட்ட கோப்பையும் வழங்கும். இது முக்கியமானது, ஏனெனில் நிராகரிக்கப்படும் ஒவ்வொரு key-யையும் server MaxAuthTries வரம்பிற்குக் கணக்கிடுகிறது (இதன் இயல்பு மதிப்பு 6). ஏழு keys கொண்ட ஒரு agent, உங்கள் சரியான key-ஐச் சென்றடைவதற்கு முன்பே இந்த வரம்பை முடித்துவிடும், அப்போது செய்தி இவ்வாறு மாறும்:

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

IdentitiesOnly=yes நீங்கள் குறிப்பிட்ட கோப்புடன் முயற்சியைக் கட்டுப்படுத்துகிறது. ssh-add -l மூலம் agent-ல் என்னென்ன keys உள்ளன என்பதைப் பட்டியலிடுங்கள், பல வருடங்களாகச் சேர்ந்த பழைய 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-ல் மற்றொரு சிக்கல் உள்ளது. உங்கள் கணினியில் உள்ள பிற கணக்குகள் படிக்கக்கூடிய வகையில் இருக்கும் private key-ஐப் பயன்படுத்த ssh மறுத்துவிடும். அது ஒரு எச்சரிக்கையை வெளியிட்டு அந்த 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 மாறிவிடும். Key-கள் எங்கு இருக்க வேண்டும், அவற்றை எப்படி அழைக்க வேண்டும் என்பது SSH key மேலாண்மை அடிப்படைகள் பகுதியில் விளக்கப்பட்டுள்ளது.

காரணம் 3: public key, authorized_keys கோப்பிற்குச் சென்றடையவில்லை

ssh -v கட்டளை மூலம் key அனுப்பப்பட்டும் server இன்னும் அனுமதி மறுக்கிறது என்றால், அந்த key கணக்கின் authorized_keys கோப்பில் உள்ளதா என்று பார்க்க வேண்டும். SSH மூலம் உள்நுழைய முடியாது என்பதால், உங்கள் provider-ன் console-ஐத் திறந்து சரிபார்க்கவும்.

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

authorized_keys கோப்பில் உள்ள ஒவ்வொரு entry-க்கும் ஒரு fingerprint-ஐ ssh-keygen -lf அச்சிடும்:

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

இவற்றை உங்கள் Offering public key வரியில் உள்ள fingerprint-உடன் ஒப்பிட்டுப் பார்க்கவும். பட்டியலில் அது இல்லை என்றால், நீங்கள் என்ன செய்ததாக நினைத்தாலும், அந்த key அந்த கணக்கில் நிறுவப்படவில்லை என்று அர்த்தம்.

பொதுவாக நடக்கும் நான்கு தவறுகள்:

• .pub கோப்பிற்குப் பதிலாக private key-ஐ நகலெடுத்து ஒட்டியிருக்கலாம். ஒரு public key வரி ssh-ed25519 அல்லது ssh-rsa என்று தொடங்கும். private key -----BEGIN OPENSSH PRIVATE KEY----- என்று தொடங்கும்.
• நகலெடுத்தபோது வரிகள் உடைந்திருக்கலாம். ஒவ்வொரு entry-யும் ஒரே வரியில் இருக்க வேண்டும்; வரி உடைந்தால் அது பல தவறான entry-களாகக் கருதப்பட்டு, எதனுடனும் பொருந்தாது.
• நீங்கள் deploy ஆக உள்நுழையும்போது key /root/.ssh/authorized_keys-ல் சேர்க்கப்பட்டிருக்கலாம், அல்லது அதற்கு மாறாக நடந்திருக்கலாம். இந்த கோப்பு ஒவ்வொரு கணக்கிற்கும் தனிப்பட்டது, பொதுவானது அல்ல.
• provider-ன் "add my key" வசதி, image-ன் default user-க்கு மட்டுமே key-ஐச் சேர்த்திருக்கலாம், இதனால் நீங்கள் பின்னர் உருவாக்கிய கணக்கில் .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 இப்போது பட்டியலில் இருக்க வேண்டும். கடவுச்சொல் மூலம் இன்னும் உள்நுழையக்கூடிய ஒரு கணினியிலிருந்து, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 கட்டளையைப் பயன்படுத்தினால் அதுவே இந்த வேலையைச் செய்து, முறையான permissions-ஐயும் அமைத்துவிடும்.

காரணம் 4: permissions மிகத் தாராளமாக இருக்கும்போது sshd ஏன் authorized_keys-ஐப் புறக்கணிக்கிறது

StrictModes yes என்பது sshd-ன் இயல்புநிலை அமைப்பாகும். இதன்படி, authorized_keys கோப்பு, .ssh அடைவு (directory), அல்லது பயனர் கணக்கின் home directory ஆகியவற்றை உரிமையாளர் அல்லாத பிறர் மாற்றியமைக்க (write) முடிந்தால், அந்த கோப்பை வாசிக்க sshd மறுத்துவிடும். இதற்கான காரணம் தெளிவானது: உங்கள் home directory-ல் group அல்லது பிற பயனர்களுக்கு எழுதும் உரிமை இருந்தால், அந்த அணுகல் உள்ள எவரும் authorized_keys கோப்பை மாற்றிவிட்டு உங்கள் கணக்கைக் கைப்பற்ற முடியும். எனவே, நம்பகத்தன்மையற்ற பாதையை sshd ஒரு key-யே இல்லாதது போலக் கருதும்.

Client பக்கத்தில் Permission denied என்ற பொதுவான பிழைச் செய்தி மட்டுமே தெரியும். ஆனால் server log-ல் உண்மையான காரணம் பதிவாகியிருக்கும்:

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

அல்லது, கோப்பின் அனுமதியே சிக்கலாக இருந்தால்:

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: இவை மூன்றும் நீங்கள் login செய்யும் பயனர் கணக்கின் உரிமையில் இருக்க வேண்டும், root-ன் உரிமையில் இருக்கக்கூடாது.

Mode போலவே Ownership-ம் முக்கியமானது. /home/deploy/.ssh-க்குள் உள்ள ஒரு கோப்பு root-ன் உரிமையில் இருந்தால், இந்தச் சோதனை தோல்வியடையும். நீங்கள் sudo nano மூலம் கோப்பை உருவாக்கும்போது உரிமையை மாற்ற மறந்துவிட்டால் இது நடக்கும். இரண்டையும் ஒரே நேரத்தில் சரிசெய்ய:

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

கடைசி கட்டளை முடிவைக் காட்டும். Home directory-க்கு drwxr-xr-x அல்லது அதற்கும் குறைவான அனுமதியும், .ssh-க்கு drwx------ அனுமதியும் இருக்க வேண்டும். இந்த string-கள் புரியவில்லை என்றால், live server-ல் மாற்றங்களைச் செய்வதற்கு முன் drwxr-xr-x போன்ற permission string-களை வாசிப்பது எப்படி என்பதைப் படிக்கவும்.

Rocky Linux மற்றும் AlmaLinux-ல், SELinux (security-enhanced Linux)-ஐயும் கவனிக்க வேண்டும். வழக்கத்திற்கு மாறான முறையில் உருவாக்கப்பட்ட .ssh அடைவு தவறான file label-ஐக் கொண்டிருக்கலாம். இதனால், mode சரியாக இருந்தாலும் sshd-க்கு வாசிக்கும் அனுமதி மறுக்கப்படும். sudo restorecon -Rv /home/deploy/.ssh கட்டளை label-களைச் சரிசெய்யும், மேலும் sudo ausearch -m avc -ts recent கட்டளை SELinux தடையை ஏற்படுத்தியதா என்பதைக் காட்டும்.

காரணம் 5: sshd உங்களை நிராகரிக்கிறது

தற்போதைய Ubuntu அல்லது Debian அமைப்புகளில் /etc/ssh/sshd_config-ஐ மட்டும் வாசிப்பது போதாது. அந்த கோப்பு Include /etc/ssh/sshd_config.d/*.conf-உடன் தொடங்குகிறது, மேலும் OpenSSH எந்தவொரு அமைப்பிற்கும் முதலில் கண்டறியும் மதிப்பையே எடுத்துக்கொள்ளும். எனவே, 50-cloud-init.conf போன்ற ஒரு drop-in கோப்பு முதலில் வாசிக்கப்பட்டு, பிரதான கோப்பில் நீங்கள் கீழே செய்யும் மாற்றங்களை விட முன்னுரிமை பெறும். இதனால்தான், நீங்கள் செய்யும் மாற்றம் சரியாகத் தெரிந்தாலும், எந்த மாற்றமும் நிகழ்வதில்லை.

sshd தற்போது பயன்படுத்தும் உண்மையான configuration-ஐக் கேட்கவும்:

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

சரியான பதில் இவ்வாறு இருக்கும்:

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

உங்கள் output-ல் கவனிக்க வேண்டியவை:

• pubkeyauthentication no. எந்தவொரு key-யும் ஏற்றுக்கொள்ளப்படாது. இது ssh -v-ல் publickey இல்லாத முதல் Authentications that can continue: பட்டியலாகவும் தோன்றும்.
• authorizedkeysfile வேறொரு இடத்தைச் சுட்டிக்காட்டினால், உதாரணமாக /etc/ssh/authorized_keys/%u. உங்கள் home directory-ல் உள்ள கோப்பு முற்றிலும் புறக்கணிக்கப்படும், மேலும் காரணம் 4-ல் உள்ள mode விதிகள் புதிய பாதைக்கு பொருந்தும்.
• allowusers அல்லது allowgroups இருப்பது. பட்டியலிடப்படாத எந்தவொரு கணக்கும் எந்த விளக்கமும் இன்றி இந்த பிழையுடன் நிராகரிக்கப்படும். denyusers மற்றும் denygroups ஆகியவை இதற்கு நேர்மாறாகச் செயல்படும்.
• நீங்கள் root-ஆக login செய்ய முயற்சிக்கும்போது permitrootlogin no. prohibit-password என்பது பயனுள்ள இடைநிலை அமைப்பாகும்: root ஒரு key-யைப் பயன்படுத்தலாம், ஆனால் password-ஐப் பயன்படுத்த முடியாது.

Match தொகுதிகள் சாதாரண sshd -T-ல் தோன்றாது, ஏனெனில் அவற்றின் முடிவு யார் இணைக்கிறார்கள் என்பதைப் பொறுத்தது. ஒரு குறிப்பிட்ட இணைப்பு குறித்து இவ்வாறு கேட்கவும்:

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

மற்றொரு அமைப்பு பழைய key-களைப் பாதிக்கிறது. OpenSSH 8.8 பதிப்பிலிருந்து SHA-1 signatures (ssh-rsa) இயல்பாகவே ஏற்றுக்கொள்ளப்படுவதில்லை, எனவே பல ஆண்டுகளாகச் செயல்பட்ட RSA key, server upgrade-க்கு பிறகு வேலை செய்யாமல் போகலாம். client இதைத் தெளிவாகக் குறிப்பிடும்:

debug1: send_pubkey_test: no mutual signature algorithm

இதற்கான சரியான தீர்வு புதிய key-யை உருவாக்குவதாகும்: ssh-keygen -t ed25519 -C "deploy@vps-prod", பின்னர் மேலே காட்டியபடி .pub கோப்பை நிறுவவும். server-ல் PubkeyAcceptedAlgorithms +ssh-rsa-ஐ அமைப்பது பழைய signatures-ஐ மீண்டும் செயல்படுத்தி உங்களை உள்ளே அனுமதிக்கும், எனவே இதை server-ஐ அணுகுவதற்கான ஒரு வழியாக மட்டுமே கருதவும், இது நிரந்தரத் தீர்வல்ல. server-side அமைப்புகளை மேலும் ஆய்வு செய்ய VPS-ல் SSH server-ஐ பலப்படுத்துதல் என்பதைப் பார்க்கவும்.

ஒரு private key, நிறுவப்பட்ட public key-உடன் பொருந்துகிறதா என்பதை உறுதிப்படுத்துவது எப்படி

இந்த பிழையில் ஏற்படும் பெரும்பாலான குழப்பங்களுக்கு, இரண்டு கோப்புகளும் ஒரு ஜோடியா என்பது தெரியாததே காரணம். ஒரு கட்டளை இதற்கு விடையளிக்கும்:

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

இது private key-லிருந்து பெறப்பட்ட public key-ஐ அச்சிடும். இது அருகில் உள்ள .pub கோப்பை ஒருபோதும் வாசிப்பதில்லை, எனவே ஒரு பழைய .pub கோப்பு என்ன சொல்கிறது என்பதை விட, அந்த private key உண்மையில் என்ன என்பதை இது உங்களுக்குத் தெரிவிக்கும். அந்த key-க்கு passphrase இருந்தால், இந்த கட்டளை அதைக் கேட்கும்; இது உங்களுக்கு இன்னும் passphrase தெரியும் என்பதையும் உறுதிப்படுத்தும்.

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

முதலாவது, ஒரு public key கோப்பின் fingerprint-ஐ அச்சிடும். இரண்டாவது, உங்கள் agent-ல் உள்ள fingerprint-களை அச்சிடும். இப்போது ஒரே string-ன் நான்கு பார்வைகளை ஒப்பிட்டுப் பாருங்கள்: ssh -v-லிருந்து வரும் Offering public key வரியில் உள்ள fingerprint, உங்கள் .pub கோப்பின் fingerprint, சர்வரின் authorized_keys-ல் உள்ள ssh-keygen -lf-ல் இருக்கும் fingerprint, மற்றும் சர்வர் log-ல் உள்ள fingerprint. இவை எங்கு பொருந்துவதை நிறுத்துகிறதோ, அங்கேயே பிழை உள்ளது என்று அர்த்தம்.

login தோல்வியடையும் போது server log-ஐ வாசித்தல்

பாதுகாப்பு காரணங்களுக்காக, client-க்கு பயனுள்ள எந்தத் தகவலும் தெரிவிக்கப்படுவதில்லை. உண்மையான காரணத்தை server log-ல் எழுதும். Console session-ல் log follower-ஐத் தொடங்கிவிட்டு, உங்கள் laptop-லிருந்து தோல்வியடையும் ssh கட்டளையை இயக்கவும்.

sudo journalctl -u ssh -f

Ubuntu 24.04-ல் rsyslog இயல்பாக நிறுவப்படுவதில்லை, எனவே /var/log/auth.log அங்கு இல்லாமல் இருக்கலாம். Rocky Linux மற்றும் AlmaLinux-ல் இந்த unit sshd என்று அழைக்கப்படுகிறது, மேலும் அதே பதிவுகள் /var/log/secure-லும் சேமிக்கப்படுகின்றன.

sshd configuration-ல் LogLevel VERBOSE-ஐ அமைத்து, service-ஐ reload செய்யவும். ஒவ்வொரு முயற்சியின் போதும், server உண்மையில் பெற்ற fingerprint பதிவு செய்யப்படும்:

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

அந்த வரி, தவறு எந்தப் பக்கத்தில் உள்ளது என்பதை உங்களுக்குத் தெரிவிக்கும். உங்களுக்குத் தெரிந்த fingerprint என்றால், உங்கள் key server-க்கு வந்து சேர்ந்தது, ஆனால் நிராகரிக்கப்பட்டது என்று பொருள்; எனவே 3, 4 மற்றும் 5-வது காரணங்களைப் பார்க்கவும். உங்களுக்குத் தெரியாத fingerprint என்றால், உங்கள் client நீங்கள் விரும்பாத ஒரு key-ஐ அனுப்பியுள்ளது என்று பொருள்; எனவே 2-வது காரணத்திற்குச் செல்லவும்.

Log இன்னும் தெளிவாக இல்லை என்றால், மற்றொரு port-ல் debug mode-ல் இரண்டாவது sshd-ஐ இயக்கவும். இது foreground-ல் இயங்கி, ஒரு connection-ஐக் கையாண்டு, அதன் காரணத்தை அச்சிட்டுவிட்டு வெளியேறும்:

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

அதே server-ல் உள்ள console session-லிருந்து, loopback address வழியாக அதனுடன் இணைக்கவும்:

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

127.0.0.1 வழியாகச் செல்வது firewall-ஐ இந்தச் சோதனையிலிருந்து விலக்கி வைக்கும். Debug output, அது திறந்த கோப்பு, அது ஒப்பிட்ட fingerprint மற்றும் Authentication refused: bad ownership or modes for directory /home/deploy போன்ற வரிகள் உட்பட துல்லியமான நிராகரிப்பு காரணத்தைக் காட்டும். உங்கள் விடை கிடைத்ததும் Ctrl+C அழுத்தவும். Port 22-ல் இயங்கும் உண்மையான sshd இந்தச் செயல்முறை முழுவதும் பாதிக்கப்படாது.

உங்களை நீங்களே வெளியேற்றாமல் தவிர்ப்பது எப்படி

Server 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-ஐச் சரிபார்க்கவும்: sudo sshd -t கோப்பு சரியாக இருந்தால் எதையும் காட்டாது, தவறாக இருந்தால் கோப்பின் பெயரையும் வரி எண்ணையும் காட்டும்.
5. முதல் terminal-ஐ மூடுவதற்கு முன், இரண்டாவது terminal-ஐத் திறந்து புதிய login-ஐச் செய்து பார்க்கவும். தவறான configuration புதிய login-களைத் தடுக்கும், ஆனால் ஏற்கனவே உள்ள session-களைப் பாதிக்காது. எனவே, நீங்கள் தற்போது இருக்கும் session-ஐ வைத்து மாற்றம் வேலை செய்கிறதா என்று கண்டறிய முடியாது.

Debian மற்றும் Ubuntu-வில் sudo systemctl restart ssh மூலமும், Rocky Linux மற்றும் AlmaLinux-ல் sudo systemctl restart sshd மூலமும் restart செய்யவும். Ubuntu 24.04-ல் sshd ஒரு socket unit-லிருந்து தொடங்கப்படுவதால், Port அல்லது ListenAddress-ல் செய்யப்படும் மாற்றங்கள் நடைமுறைக்கு வர, அதற்கு முன் sudo systemctl restart ssh.socket தேவைப்படும்.

FAQ

மற்றொரு server-ல் வேலை செய்யும் அதே key, இந்த server-ல் ஏன் Permission denied (publickey) என்று காட்டுகிறது?

ஏனெனில் key சரியாகவே உள்ளது, அதைச் சுற்றியுள்ள அமைப்பில் ஏதோ தவறு உள்ளது. ssh -v கட்டளையை இயக்கி, Offering public key வரியைக் கண்டறியவும். உங்கள் key அங்கு பட்டியலிடப்படவில்லை என்றால், ssh அதை அனுப்பவில்லை என்று அர்த்தம்: அந்த file ~/.ssh-ல் இயல்புநிலை பெயரில் இல்லை மற்றும் agent-ல் ஏற்றப்படவில்லை, எனவே -i /path/to/key -o IdentitiesOnly=yes-ஐச் சேர்க்கவும். key பட்டியலிடப்பட்டும் server அனுமதி மறுத்தால், அந்த key கணக்கின் authorized_keys-ல் இல்லை, அல்லது அதன் path group-writable ஆக உள்ளது, அல்லது sshd config அந்த பயனரைத் தடுக்கிறது. server log இந்தச் சிக்கல்களைத் தனித்தனியாகக் காட்டும்.

SSH உண்மையில் எந்த key-ஐ அனுப்புகிறது என்பதை எப்படிப் பார்ப்பது?

ssh -v host ஒவ்வொரு key-க்கும் ஒரு debug1: Offering public key: வரியை அச்சிடும், அதில் source file மற்றும் SHA256 fingerprint இருக்கும். ssh-add -l agent-ல் உள்ள fingerprint-களைப் பட்டியலிடும். ssh-keygen -lf ~/.ssh/id_ed25519.pub ஒரு தனிப்பட்ட key file-ன் fingerprint-ஐ அச்சிடும், மற்றும் ssh-keygen -y -f ~/.ssh/id_ed25519 ஒரு private key-லிருந்து பெறப்படும் public key-ஐ அச்சிடும். login வெற்றிபெற, Offering வரியிலிருந்து வரும் fingerprint, server-ன் authorized_keys-க்கு எதிராக இயக்கப்பட்ட ssh-keygen -lf-ல் இருக்க வேண்டும்.

sshd ஏன் எனது authorized_keys file-ஐப் புறக்கணிக்கிறது?

ஏனெனில் StrictModes இயல்பாகவே செயல்பாட்டில் உள்ளது, மேலும் அந்த file, .ssh directory, அல்லது home directory ஆகியவை group அல்லது world-க்கு writable ஆக இருக்கலாம், அல்லது தவறான கணக்கின் உரிமையில் இருக்கலாம். வேறு யாராவது மாற்றக்கூடிய path-ஐ sshd நம்பாது, எனவே key இல்லாதது போலவே அது செயல்படும். home directory-ஐ 755 அல்லது அதற்கும் மேலாகக் கட்டுப்படுத்தவும், .ssh-ஐ 700 ஆகவும், authorized_keys-ஐ 600 ஆகவும் மாற்றவும், இவை மூன்றையும் login கணக்கின் உரிமையின் கீழ் கொண்டு வரவும். LogLevel VERBOSE மூலம் server Authentication refused: bad ownership or modes for directory /home/deploy/.ssh-ஐப் பதிவு செய்யும்.

server upgrade செய்த பிறகு எனது key வேலை செய்யவில்லை. என்ன மாறியது?

அது RSA key என்றால், இது பெரும்பாலும் SHA-1 மாற்றத்தினால் இருக்கலாம். OpenSSH 8.8 இயல்பாகவே ssh-rsa SHA-1 கையொப்பங்களை முடக்கியுள்ளது, எனவே அந்த முறையில் மட்டுமே கையொப்பமிடக்கூடிய key இப்போது நிராகரிக்கப்படுகிறது. verbose client output-ல் debug1: send_pubkey_test: no mutual signature algorithm என்பதைக் காணலாம். ssh-keygen -t ed25519 மூலம் நவீன key-ஐ உருவாக்கி அதன் .pub file-ஐ நிறுவவும். உங்களுக்கு உடனடியாக அணுகல் தேவைப்பட்டால், server-ல் PubkeyAcceptedAlgorithms +ssh-rsa பழைய கையொப்பங்களை மீண்டும் செயல்படுத்தும், புதிய key வேலை செய்தவுடன் அந்த வரியை நீக்கிவிட வேண்டும்.

நான் sshd_config-ஐத் திருத்தினேன், இப்போது என்னால் login செய்ய முடியவில்லை. எப்படி மீண்டும் உள்ளே செல்வது?

SSH வழியாகச் செல்லாத உங்கள் provider-ன் console-ஐப் பயன்படுத்தவும். அங்கு local password மூலம் login செய்து, sudo sshd -t-ஐ இயக்கி syntax error மற்றும் அதன் வரி எண்ணைக் கண்டறியவும், மாற்றத்தை நீக்கிவிட்டு service-ஐ restart செய்யவும். பிறகு sudo sshd -T-ஐச் சரிபார்த்து இயங்கும் மதிப்புகளை உறுதிப்படுத்தவும், ஏனெனில் /etc/ssh/sshd_config.d/-ல் உள்ள file முக்கிய config-ஐ மீறக்கூடும். local password இல்லையென்றால், முதலில் console மூலம் root password-ஐ reset செய்துவிட்டு, பிறகு file-ஐச் சரிசெய்யவும்.