Ayusin ang SSH Permission denied (publickey)

Ano talaga ang ibig sabihin ng Permission denied (publickey)

Ang Permission denied (publickey) ay nangangahulugang nagpadala ang client mo ng isa o higit pang public key, pero wala sa mga ito ang tinanggap ng server. Maayos ang network at tumatakbo ang sshd: sa huling hakbang ng authentication nangyayari ang pagtanggi. Hindi kailangang manghula sa pag-aayos nito, dahil ipinapakita sa iyo ng ssh -v kung alin sa limang sanhi ang nararanasan mo.

Ang mga salitang nasa loob ng panaklong ay ang mga method na handang tanggapin ng server. Ang Permission denied (publickey) lamang ay nangangahulugang naka-off ang password login sa server na iyon, kaya walang password na maaaring gamitin bilang fallback. Ang Permission denied (publickey,password) ay nangangahulugang inaalok ang password login at nabigo ka rin sa paraang iyon.

Iisang message ang ginagamit para sa limang magkakaibang fault, at sadyang malabo ito. Kung sasagot ang server ng “walang ganoong user” o “hindi naka-install ang key na iyon,” matutulungan nito ang sinumang naghahanap ng mga valid account. Kaya huwag munang magpalit-palit ng key at mag-edit ng configuration file. Magpatakbo ng isang command, basahin ang tatlong linya ng output, at ang limang posibleng sanhi ay magiging isa na lamang.

Unahin ang ssh -v, at basahin ang tatlong linya

Ulitin ang command na nag-fail, na may idinagdag na -v:

ssh -v deploy@203.0.113.10

Ganito ang pinaikling pero makatotohanang 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).

Nasa tatlong linya ang lahat ng kailangan mo.

Ang Authenticating to 203.0.113.10:22 as 'deploy' ang aktuwal na username na gagamitin. Hindi ito ang username na sinadya mong gamitin, kundi ang username na tinukoy ng ssh mula sa command line, sa ~/.ssh/config, o sa local login name mo.

Ang Authentications that can continue: publickey ang listahan ng mga method na tinatanggap ng server. Ipinapadala ito bago subukan ang anumang key. Kung wala ang publickey sa unang listahang iyon, naka-off ang public key login sa server, kaya walang key na gagana.

Ang Offering public key: ... ay tig-iisang linya para sa bawat key na aktuwal na ipinadala ng client. Nakasaad dito ang file na pinanggalingan nito at ang SHA256 fingerprint nito. Ang key na walang linyang Offering ay hindi kailanman ipinadala sa server.

Hatiin ngayon sa dalawang bahagi ang problema:

• Walang linyang Offering public key para sa key na inaasahan mo. Nasa machine mo ang problema, dahil hindi pa nakikita ng server ang key mo.
• Inalok ang key at muling lumabas ang Authentications that can continue: publickey. Natanggap ng server ang key na iyon ngunit tinanggihan ito, kaya nasa server ang problema.

Nakaayos sa ibaba ang mga sanhi ayon sa dalas ng pagiging aktuwal na sagot.

Dahilan 1: mali ang username na ginagamit mo sa pagkonekta

Ang pinakakaraniwang dahilan ay siya ring pinakasimple. Ang sshd, ang SSH (secure shell) server daemon, ay hindi kailanman nagsasabi na walang ganoong account. Isinasagawa nito ang buong exchange gamit ang ginawang username at tumatanggi sa huli gamit ang parehong mensahe, dahil nakatutulong sa attacker ang paglalantad ng mga valid na account name. Ang typo sa username ay eksaktong katulad ng sirang key.

Suriin muna ang linyang Authenticating to ... as bago ang iba pa. Kung pangalan ito ng login sa laptop mo sa halip na account sa server, hindi mo isinama ang username sa command.

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

Nakadepende ang default account sa image na binuo ng provider mo. Noong August 2026, karaniwang naglalabas ang Ubuntu cloud images ng account na ubuntu, ang Debian images ay naglalabas ng debian o admin, ang Rocky Linux at AlmaLinux ay naglalabas ng rocky at almalinux, at maraming VPS provider naman ang direktang nag-i-install ng key mo sa root. Nakatala sa control panel ng provider mo kung aling account ang ginawa nito. Walang command na pinapatakbo mula sa labas ng server ang makapagtatanong nito.

Nagtatakda rin ng username ang isang Host block sa ~/.ssh/config, at ito ang ginagamit kaysa sa lokal mong login name:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Kung ikaw mismo ang gumawa ng account at pagkatapos ay hindi ka nakapag-login gamit ito, malamang na na-install ang key para sa default user ng image at hindi ito nakopya sa bagong account. Bahagi ang hakbang na ito ng unang sampung minuto sa isang bagong VPS, at madaling malaktawan.

Sanhi 2: hindi ang key na inaakala mong ipinapadala ang aktuwal na ipinapadala

Bilang default, iniaalok ng ssh ang mga key na hawak ng ssh-agent, pati ang nakatakdang set ng mga filename sa ~/.ssh: id_ed25519, id_ecdsa, id_rsa, at ang hardware at DSA variant ng mga pangalang iyon. Hindi nakikita ng ssh ang key na naka-save bilang ~/.ssh/vps-prod hangga't hindi mo ito tinutukoy. Ito ang dahilan kung bakit walang Offering public key line para rito sa verbose output.

Tukuyin ang file, at pigilan ang mga key mula sa agent na mauna:

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

Hindi sapat ang -i kapag may hawak na mga key ang agent, dahil inuuna pa rin ng ssh ang mga key ng agent at huling iniaalok ang tinukoy na file. Mahalaga ito dahil ibinabawas ng server ang bawat tinanggihang key sa MaxAuthTries, na ang default ay 6. Maaaring maubos ng agent na may hawak na pitong key ang limit bago maabot ang tamang key, at magbabago ang mensahe sa:

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

Nililimitahan ng IdentitiesOnly=yes ang pagtatangka sa file na ipinasa mo. Ilista ang mga hawak ng agent gamit ang ssh-add -l, at i-clear ang mga ito gamit ang ssh-add -D kung maraming lumang key ang naipon nito sa paglipas ng mga taon. Pagkatapos, isulat ang mga setting para hindi nakadepende sa pag-alala ng mga flag ang susunod na login:

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

May isa pang client-side na problema. Tumatanggi ang ssh na gumamit ng private key na nababasa ng ibang account sa sarili mong machine. Nagpi-print ito ng warning at pagkatapos ay binabalewala ang key, kaya hindi ito kailanman iniaalok at hindi ito nakikita ng server:

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

Inaayos ito ng chmod 600 ~/.ssh/vps-prod. Karaniwang nawawala ang mode kapag inililipat ang key gamit ang USB stick o Windows share. Ipinaliwanag sa Mga pangunahing kaalaman sa SSH key management kung saan inilalagay ang mga key at kung ano ang dapat na pangalan ng mga ito.

Sanhi 3: hindi nakarating ang public key sa authorized_keys

Kung ipinapakita ng ssh -v na naipadala ang key ngunit tinatanggihan pa rin ito ng server, ang susunod na tanong ay kung nasa authorized_keys file ng account ang key na iyon. Buksan ang console ng provider para magsuri, dahil hindi ka makakapag-login gamit ang SSH upang tingnan ito.

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

Ang ssh-keygen -lf sa isang authorized_keys file ay nagpi-print ng tig-isang fingerprint para sa bawat entry:

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

Ihambing ang mga iyon sa fingerprint sa iyong Offering public key line. Kung wala ito sa listahan, hindi naka-install ang key sa account na iyon, anuman ang natatandaan mong ginawa.

Apat na karaniwang paraan kung paano ito nagkakamali:

• Na-paste mo ang private key sa halip na ang .pub file. Nagsisimula ang public key line sa ssh-ed25519 o ssh-rsa. Nagsisimula naman ang private key sa -----BEGIN OPENSSH PRIVATE KEY-----.
• Nahati sa ilang line ang paste. Dapat nasa eksaktong isang line ang bawat entry, kaya kapag nahati ang key, binabasa ito bilang ilang sirang entry at walang tumutugma.
• Nailagay ang key sa /root/.ssh/authorized_keys habang nagla-login ka bilang deploy, o kabaligtaran. Bawat account ay may sariling file, at walang shared na file.
• Isinulat ng "add my key" box ng provider ang key sa default user ng image, kaya walang laman ang .ssh directory ng account na ginawa mo kalaunan.

Ang ligtas na paraan para magdagdag ng key mula sa console, bilang root:

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

Patakbuhin muli ang sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys pagkatapos. Dapat nasa listahan na ngayon ang bagong fingerprint. Mula sa machine na makakapag-login pa gamit ang password, pareho ang ginagawa ng ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 at itinatakda nito nang tama ang mga mode para sa iyo.

Sanhi 4: bakit binabalewala ng sshd ang authorized_keys kapag masyadong bukas ang permissions

StrictModes yes ang default ng sshd. Sa ilalim nito, tumatanggi ang sshd na basahin ang authorized_keys kung ang file na iyon, ang .ssh directory, o ang home directory ng account ay maaaring sulatan ng sinuman maliban sa owner. Direktang dahilan ito: kung maaaring sulatan ng group o ng ibang user ang home directory mo, maaaring palitan ng anumang account na may ganoong access ang authorized_keys at kunin ang login. Itinuturing ng sshd ang isang path na hindi pinagkakatiwalaan na parang walang key na umiiral.

Ang nakikita ng client ay ang simpleng mensaheng Permission denied. Itinatala ng server log ang aktuwal na dahilan:

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

o, kapag ang file mismo ang may problema:

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

Mga tatanggapin ng sshd:

• Ang home directory: hindi writable ng group at hindi writable ng ibang user. Pumapasa ang 755, 750 at 700. Hindi pumapasa ang 775 at 777.
• ~/.ssh: mode 700.
• ~/.ssh/authorized_keys: mode 600.
• Ownership: lahat ng tatlo ay pagmamay-ari ng account na ginagamit mo sa pag-login, hindi ng root.

Mahalaga ang ownership gaya ng mode. Mabibigo rin ang parehong check kapag ang file sa loob ng /home/deploy/.ssh ay pagmamay-ari ng root. Nangyayari ito kapag ginawa mo ito gamit ang sudo nano at nakalimutang ibalik ang ownership. Ayusin ang dalawang ito nang sabay:

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

Ipinapakita ng huling command ang resulta. Dapat ay drwxr-xr-x o mas mahigpit ang home directory at drwx------ ang .ssh. Kung hindi pa malinaw ang mga string na iyon, basahin ang kung paano basahin ang permission string gaya ng drwxr-xr-x bago ka magbago ng modes sa isang live server.

Sa Rocky Linux at AlmaLinux, idagdag ang SELinux (security-enhanced Linux) sa mga posibleng sanhi. Maaaring magkaroon ng maling file label ang isang .ssh directory na ginawa sa hindi karaniwang paraan, kaya pinagkakaitan ang sshd ng read access kahit tama ang mga mode. Ibinabalik ng sudo restorecon -Rv /home/deploy/.ssh ang mga label, at ipinapakita ng sudo ausearch -m avc -ts recent kung ang SELinux ang component na tumanggi sa access.

Sanhi 5: naka-configure ang sshd na tanggihan ka

Hindi sapat ang pagbasa sa /etc/ssh/sshd_config sa kasalukuyang Ubuntu o Debian system. Nagsisimula ang file na iyon sa Include /etc/ssh/sshd_config.d/*.conf, at ginagamit ng OpenSSH ang unang value na makita nito para sa bawat setting. Kaya unang binabasa ang drop-in file gaya ng 50-cloud-init.conf, at ito ang nangingibabaw sa anumang i-edit mo sa bandang ibaba ng pangunahing file. Dahil dito, maaaring mukhang tama ang isang edit pero wala itong mabago.

Hingin sa sshd ang configuration na aktuwal nitong ginagamit:

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

Ganito ang hitsura ng maayos na output:

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

Narito ang dapat hanapin sa sarili mong output:

• pubkeyauthentication no. Walang key na tatanggapin kailanman. Lumalabas din ito sa ssh -v bilang unang Authentications that can continue: list na walang publickey.
• Nakaturo ang authorizedkeysfile sa ibang lokasyon, halimbawa /etc/ssh/authorized_keys/%u. Kaya tuluyang binabalewala ang file mo sa home directory, at inilalapat naman ang mode rules mula sa sanhi 4 sa bagong path.
• May allowusers o allowgroups. Tatanggihan ang anumang account na hindi nakalista, gamit ang eksaktong error na ito at walang paliwanag. Ganito rin ang ginagawa ng denyusers at denygroups sa kabaligtarang paraan.
• Naka-set ang permitrootlogin no habang sinusubukan mong mag-login bilang root. Ang prohibit-password ang praktikal na middle setting: maaaring gumamit ang root ng key pero hindi ng password.

Hindi lumilitaw ang Match blocks sa plain na sshd -T, dahil nakadepende ang resulta ng mga ito sa kumokonekta. Magtanong tungkol sa isang partikular na connection:

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

May isa pang setting na nakaaapekto sa mga lumang key. Itinigil ng OpenSSH 8.8 ang pagtanggap sa SHA-1 signatures (ssh-rsa) bilang default, kaya maaaring biglang tumigil sa paggana ang isang RSA key na ilang taon nang gumagana pagkatapos ng server upgrade. Malinaw itong sinasabi ng client:

debug1: send_pubkey_test: no mutual signature algorithm

Ang tamang fix ay gumawa ng bagong key: ssh-keygen -t ed25519 -C "deploy@vps-prod", pagkatapos ay i-install ang .pub file gaya ng ipinakita sa itaas. Ang pag-set ng PubkeyAcceptedAlgorithms +ssh-rsa sa server ay muling nagpapagana sa mga lumang signature at makapagpapapasok sa iyo ngayon, kaya ituring ito bilang paraan para ma-access ang server, hindi bilang panghuling solusyon. Nasa pag-hardening ng SSH server sa isang VPS ang iba pang server-side setting na dapat suriin.

Paano patunayan na tumutugma ang private key sa naka-install na public key

Karamihan sa paghuhula sa error na ito ay dahil hindi alam kung magkapareha ang dalawang file. Isang command ang makakasagot dito:

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

Ipi-print nito ang public key na nakuha mula sa private key. Hindi nito binabasa ang katabing .pub file, kaya ipinapakita nito kung ano talaga ang private key, hindi kung ano ang sinasabi ng lumang .pub file. Kung may passphrase ang key, hihingin ito ng command. Pinatutunayan din nito na alam mo pa ang passphrase.

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

Ipi-print ng una ang fingerprint ng isang public key file. Ipi-print naman ng pangalawa ang mga fingerprint na hawak ng iyong agent. Ihambing ang apat na view ng parehong string: ang fingerprint sa Offering public key line mula sa ssh -v, ang fingerprint ng iyong .pub file, ang mga fingerprint sa ssh-keygen -lf sa server's authorized_keys, at ang fingerprint sa server log. Ang puntong hindi na nagtutugma ang mga ito ang pinagmumulan ng problema.

Basahin ang server log habang nabibigo ang login

Sadyang walang kapaki-pakinabang na impormasyon ang ipinapakita sa client. Isinusulat ng server ang aktuwal na dahilan. Magsimula ng log follower sa console session, pagkatapos ay patakbuhin mula sa iyong laptop ang command na ssh na nagfa-fail.

sudo journalctl -u ssh -f

Hindi ini-install ng Ubuntu 24.04 ang rsyslog bilang default, kaya maaaring wala roon ang /var/log/auth.log. Sa Rocky Linux at AlmaLinux, sshd ang pangalan ng unit, at napupunta rin ang parehong record sa /var/log/secure.

Itakda ang LogLevel VERBOSE sa sshd configuration at i-reload ang service. Pagkatapos, ila-log ng bawat pagtatangka ang fingerprint na aktuwal na natanggap ng server:

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

Ipinapakita ng linyang iyon kung saang panig nanggagaling ang problema. Kung kinikilala mo ang fingerprint, nakarating ang iyong key ngunit tinanggihan ito ng server, kaya suriin ang mga sanhi 3, 4, at 5. Kung hindi mo kinikilala ang fingerprint, ibang key ang ipinadala ng client kaysa sa nilayon mo, kaya bumalik sa sanhi 2.

Kung hindi pa rin malinaw ang log, magpatakbo ng ikalawang sshd sa ibang port gamit ang debug mode. Mananatili ito sa foreground, tatanggap ng isang connection, ipapakita ang proseso ng pagsusuri nito, at pagkatapos ay lalabas:

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

Mula sa console session sa parehong server, kumonekta rito gamit ang loopback address:

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

Sa paggamit ng 127.0.0.1, hindi kasama ang firewall sa test. Ipinapakita sa debug output ang file na binuksan nito, ang fingerprint na ikinumpara nito, at ang eksaktong pagtanggi, kabilang ang mga linyang gaya ng Authentication refused: bad ownership or modes for directory /home/deploy. Pindutin ang Ctrl+C kapag nakuha mo na ang sagot. Hindi naaapektuhan ang aktuwal na sshd sa port 22 sa buong proseso.

Paano maiiwasang ma-lock out ang sarili

Bawat hakbang na nag-e-edit ng server configuration ay nangangailangan ng paraan para makabalik na hindi nakadepende sa SSH. I-set up ito habang gumagana pa ang SSH, hindi pagkatapos itong masira.

1. Buksan ang console ng provider mo gamit ang serial o VNC (virtual network computing), at tiyaking makakapag-log in ka roon.
2. Tiyaking alam mo ang gumaganang local password para sa isang account na may sudo. Kung wala ka nito, i-reset muna ang root password mula sa console ng provider.
3. Panatilihing bukas ang kasalukuyan mong SSH session. Nananatiling bukas ang isang session sa loob ng systemctl restart ssh, kaya magagamit pa rin ito bilang paraan para makabalik kung mali ang bagong configuration.
4. Suriin ang syntax bago mag-restart: walang output ang sudo sshd -t kapag valid ang file, at ipinapakita nito ang file at line number kapag invalid ito.
5. Magbukas ng pangalawang terminal at mag-log in ulit bago isara ang una. Pinipigilan ng maling configuration ang mga bagong login pero hindi nito naaapektuhan ang mga kasalukuyang session, kaya hindi masasabi ng session na ginagamit mo kung gumana ang pagbabago.

Mag-restart gamit ang sudo systemctl restart ssh sa Debian at Ubuntu, o sudo systemctl restart sshd sa Rocky Linux at AlmaLinux. Sa Ubuntu 24.04, sinisimulan ang sshd mula sa isang socket unit, kaya ang pagbabago sa Port o ListenAddress ay nangangailangan din ng sudo systemctl restart ssh.socket bago ito magkabisa.

FAQ

Bakit ako nakakakuha ng Permission denied (publickey) kahit gumagana ang parehong key sa ibang server?

Dahil maayos ang key at may ibang problemang nakapaligid dito. Patakbuhin ang ssh -v at hanapin ang linyang Offering public key. Kung hindi nakalista ang iyong key, hindi ito ipinadala ng ssh: wala ang file sa ~/.ssh gamit ang default na pangalan at hindi ito naka-load sa agent, kaya idagdag ang -i /path/to/key -o IdentitiesOnly=yes. Kung nakalista ang key ngunit tinatanggihan pa rin ito ng server, maaaring wala ang key sa authorized_keys ng account, group-writable ang path papunta rito, o bina-block ng sshd config ang user. Tinutukoy ng server log kung alin sa mga sitwasyong ito ang nangyari.

Paano ko makikita kung aling key ang aktuwal na ipinapadala ng SSH?

Nagpi-print ang ssh -v host ng isang debug1: Offering public key: line para sa bawat key. Nakasaad sa bawat isa ang source file at SHA256 fingerprint. Inililista ng ssh-add -l ang mga fingerprint na hawak ng agent. Nagpi-print ang ssh-keygen -lf ~/.ssh/id_ed25519.pub ng fingerprint ng isang key file, at nagpi-print ang ssh-keygen -y -f ~/.ssh/id_ed25519 ng public key na aktuwal na nade-derive mula sa isang private key. Para magtagumpay ang login, dapat lumitaw din ang fingerprint mula sa Offering line sa output ng ssh-keygen -lf na pinatakbo laban sa authorized_keys ng server.

Bakit binabalewala ng sshd ang aking authorized_keys file?

Dahil naka-enable bilang default ang StrictModes, at maaaring writable ng group o world ang file, ang .ssh directory, o ang home directory, o pagmamay-ari ito ng maling account. Hindi pinagkakatiwalaan ng sshd ang path na maaaring baguhin ng ibang tao, kaya kumikilos ito na parang walang key. Itakda ang home directory sa 755 o mas mahigpit pa, ang .ssh sa 700, at ang authorized_keys sa 600. Tiyaking pagmamay-ari ng login account ang tatlong ito. Kapag ginamit ang LogLevel VERBOSE, itinatala ng server ang Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Biglang hindi gumana ang aking key matapos ang server upgrade. Ano ang nagbago?

Kung RSA key ito, pinakamalamang na sanhi nito ang pagbabago sa SHA-1. Hindi na pinapahintulutan ng OpenSSH 8.8 bilang default ang ssh-rsa SHA-1 signatures, kaya tinatanggihan na ngayon ang key na ganoon lamang makapag-sign. Ipinapakita ng verbose client output ang debug1: send_pubkey_test: no mutual signature algorithm. Gumawa ng modern key gamit ang ssh-keygen -t ed25519 at i-install ang .pub file nito. Kung kailangan mo agad ng access, muling paganahin ng PubkeyAcceptedAlgorithms +ssh-rsa sa server ang mga lumang signature, at dapat mong alisin ang linyang iyon kapag gumana na ang bagong key.

In-edit ko ang sshd_config at hindi na ako makapag-login. Paano ako makakapasok muli?

Gamitin ang console ng iyong provider, na hindi dumaraan sa SSH. Mag-login doon gamit ang local password, patakbuhin ang sudo sshd -t upang makita ang syntax error at numero ng linya nito, ibalik ang binagong configuration, at i-restart ang service. Pagkatapos, suriin ang sudo sshd -T upang kumpirmahin ang mga value na ginagamit ng tumatakbong service, dahil maaaring may file sa /etc/ssh/sshd_config.d/ na nag-o-override sa pangunahing config. Kung wala kang local password, i-reset muna ang root password mula sa console, saka ayusin ang file.