Jinsi ya kurekebisha kosa la SSH Permission denied

Maana halisi ya Permission denied (publickey)

Permission denied (publickey) inamaanisha kuwa mteja wako alituma ufunguo mmoja au zaidi wa umma (public keys) na seva haikukubali hata mmoja. Mtandao unafanya kazi vizuri na sshd inasikiliza: kukataliwa huko kunatokea katika hatua ya mwisho ya uthibitishaji. Suluhisho si kubahatisha, kwa sababu ssh -v inakuambia ni ipi kati ya sababu tano iliyosababisha tatizo.

Maneno yaliyo ndani ya mabano ni mbinu ambazo seva ilikuwa tayari kukubali. Permission denied (publickey) pekee inamaanisha kuwa kuingia kwa nenosiri (password login) kumezimwa kwenye seva hiyo, kwa hivyo hakuna nenosiri la kutumia kama mbadala. Permission denied (publickey,password) inamaanisha kuwa manenosiri yalikuwa yanaruhusiwa lakini umeshindwa pia kuyatumia.

Ujumbe mmoja unashughulikia makosa matano tofauti, na ni wa jumla kwa makusudi. Seva inayojibu "no such user" au "that key is not installed" ingemsaidia mtu yeyote anayetafuta akaunti halali. Kwa hivyo, usianze kubadilisha funguo na kuhariri faili za usanidi. Tekeleza amri moja, soma mistari mitatu ya matokeo, na sababu tano zinazowezekana zitapungua hadi kubaki moja.

Tekeleza ssh -v kwanza, na usome mistari mitatu

Rudia amri iliyoshindwa, ukiwa umeongeza -v:

ssh -v deploy@203.0.113.10

Mchakato uliopunguzwa lakini wa kweli unaonekana hivi:

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).

Mistari mitatu ina kila kitu unachohitaji.

Authenticating to 203.0.113.10:22 as 'deploy' ni jina la mtumiaji (username) ambalo litatumika kihalisi. Si lile ulilokusudia kutumia: ni lile ambalo ssh imebaini kutoka kwenye mstari wa amri, kutoka ~/.ssh/config, au kutoka jina lako la kuingia (login name) la ndani.

Authentications that can continue: publickey ni orodha ya seva ya mbinu zinazokubalika, inayotumwa kabla ya ufunguo wowote kujaribiwa. Ikiwa publickey haipo kwenye orodha hiyo ya kwanza, seva imezima uingiaji kwa kutumia public key, kwa hivyo hakuna ufunguo utakaoweza kufanya kazi.

Offering public key: ... ni mstari mmoja kwa kila ufunguo ambao mteja wako (client) ametuma kihalisi, ikitaja faili ufunguo huo ulipotoka na fingerprint yake ya SHA256. Ufunguo usio na mstari wa Offering haukutumwa kamwe kwenye seva.

Sasa gawanya tatizo katika sehemu mbili:

• Hakuna mstari wa Offering public key kwa ufunguo unaotarajia. Kosa liko kwenye mashine yako, kwa sababu seva haijaona ufunguo wako hata kidogo.
• Ufunguo umetolewa na Authentications that can continue: publickey inarudi tena. Seva imepokea ufunguo huo na kuukataa, kwa hivyo kosa liko kwenye seva.

Visababishi vilivyo hapa chini vimepangwa kulingana na mara ngapi vinageuka kuwa jibu sahihi.

Sababu ya 1: unaunganisha kwa kutumia jina la mtumiaji lisilo sahihi

Sababu ya kawaida zaidi ndiyo pia isiyovutia zaidi. sshd, daemon ya seva ya SSH (secure shell), haikuambii kamwe kuwa akaunti haipo. Inafanya mabadilishano yote kwa jina la mtumiaji lililobuniwa na kukataa mwishoni kwa ujumbe uleule, kwa sababu kufichua majina halali ya akaunti humsaidia mshambuliaji. Kosa la kuandika jina la mtumiaji linaonekana sawa na ufunguo uliovunjika.

Kagua mstari wa Authenticating to ... as kabla ya kitu kingine chochote. Ikiwa unataja jina lako la kuingia kwenye laptop badala ya akaunti ya seva, umesahau kuweka jina la mtumiaji kwenye amri hiyo.

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

Akaunti chaguo-msingi inategemea image inayotengenezwa na mtoa huduma wako. Kufikia Agosti 2026, image za wingu za Ubuntu kwa kawaida huja na akaunti ya ubuntu, image za Debian huja na debian au admin, Rocky Linux na AlmaLinux huja na rocky na almalinux, na watoa huduma wengi wa VPS badala yake huweka ufunguo wako moja kwa moja kwenye root. Jopo la kudhibiti la mtoa huduma wako hurekodi akaunti iliyoundwa. Hakuna amri inayoweza kuendeshwa kutoka nje ya seva inayoweza kuuliza jambo hili.

Kizuizi cha Host katika ~/.ssh/config pia huweka jina la mtumiaji, na hupata kipaumbele kuliko jina lako la kuingia la ndani:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Ikiwa uliunda akaunti mwenyewe na kisha ukashindwa kuingia nayo, ufunguo pengine uliwekwa kwa mtumiaji chaguo-msingi wa image na haukunakiliwa. Hatua hiyo ni sehemu ya dakika kumi za kwanza kwenye VPS mpya, na ni rahisi kuisahau.

Sababu ya 2: ufunguo unaodhani unatuma si ule unaotumwa

Kwa chaguo-msingi, ssh hutoa tu funguo zilizohifadhiwa kwenye ssh-agent pamoja na seti maalum ya majina ya faili kwenye ~/.ssh: id_ed25519, id_ecdsa, id_rsa, na matoleo ya maunzi na DSA ya majina hayo. Ufunguo ulihifadhiwa kama ~/.ssh/vps-prod hauwezi kuonekana na ssh hadi utakapoutaja, ndiyo maana matokeo ya kina (verbose output) hayakuonyeshi mstari wa Offering public key kwa ajili yake.

Taja faili hilo, na uzuie funguo za wakala (agent keys) kuchukua nafasi yake:

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

-i pekee haitoshi wakati wakala anashikilia funguo, kwa sababu ssh bado hutoa funguo za wakala kwanza na faili lililotajwa mwisho. Hilo ni muhimu, kwa sababu seva huhesabu kila ufunguo uliokataliwa dhidi ya MaxAuthTries, ambayo kwa chaguo-msingi ni 6. Wakala anayeshikilia funguo saba anaweza kumaliza kikomo hicho kabla ya ufunguo wako sahihi kufikiwa, na ujumbe hubadilika na kuwa:

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

IdentitiesOnly=yes hupunguza jaribio kwenye faili ulilopitisha. Orodhesha kile ambacho wakala anashikilia kwa kutumia ssh-add -l, na ukiondoe kwa ssh-add -D ikiwa kimekusanya funguo za zamani za miaka mingi. Kisha andika mipangilio hiyo ili kuingia kwa mara nyingine kusitegemee kukumbuka flag:

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

Mtego mwingine wa upande wa mteja. ssh hukataa kutumia ufunguo wa faragha (private key) ambao akaunti nyingine kwenye mashine yako zinaweza kuusoma. Huchapisha onyo na kisha kuupuuza ufunguo huo, kwa hivyo ufunguo hautolewi kamwe na seva hauoni:

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

chmod 600 ~/.ssh/vps-prod hurekebisha hilo. Kuhamisha ufunguo kupitia USB stick au Windows share ndiyo njia ya kawaida ambayo mode hupotea. Mahali ambapo funguo huishi na jinsi ya kuziita imeelezewa katika misingi ya usimamizi wa funguo za SSH.

Sababu ya 3: ufunguo wa umma haukufika kwenye authorized_keys

Ikiwa ssh -v inaonyesha ufunguo unatumwa na seva bado inakataa, swali linalofuata ni kama ufunguo huo upo kwenye faili ya authorized_keys ya akaunti husika. Fungua konsole ya mtoa huduma wako ili kukagua, kwa kuwa huwezi kuingia kupitia SSH ili kuangalia.

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

ssh-keygen -lf kwenye faili ya authorized_keys huchapisha fingerprint moja kwa kila ingizo:

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

Linganisha hizo na fingerprint iliyo kwenye mstari wako wa Offering public key. Ikiwa haipo kwenye orodha, ufunguo haujasakinishwa kwenye akaunti hiyo, bila kujali unachokumbuka kufanya.

Kuna njia nne ambazo mambo huenda vibaya, zote ni za kawaida:

• Ulibandika ufunguo wa faragha badala ya faili ya .pub. Mstari wa ufunguo wa umma huanza na ssh-ed25519 au ssh-rsa. Ufunguo wa faragha huanza na -----BEGIN OPENSSH PRIVATE KEY-----.
• Ubandikaji ulijikunja kwenye mistari kadhaa. Kila ingizo lazima likae kwenye mstari mmoja kamili, kwa hivyo ufunguo uliokunjwa husomwa kama maingizo kadhaa yaliyovunjika na haulingani na chochote.
• Ufunguo ulienda kwenye /root/.ssh/authorized_keys wakati unaingia kama deploy, au kinyume chake. Faili hii ni ya kila akaunti, na hakuna faili ya pamoja.
• Kisanduku cha "add my key" cha mtoa huduma kiliandika ufunguo huo kwa mtumiaji wa kawaida wa image pekee, kwa hivyo akaunti uliyounda baadaye ina saraka ya .ssh tupu.

Njia salama ya kuongeza ufunguo kutoka kwenye konsole, ukiwa kama 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

Endesha sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys tena baada ya hapo. Fingerprint mpya inapaswa sasa kuwepo kwenye orodha. Kutoka kwenye mashine ambayo bado inaweza kuingia kwa nenosiri, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 hufanya kazi hiyo hiyo na kukuwekea mode kwa usahihi.

Sababu ya 4: kwa nini sshd hupuuza authorized_keys wakati ruhusa ziko wazi kupita kiasi

StrictModes yes ndiyo chaguo-msingi la sshd. Chini yake, sshd hukataa kusoma authorized_keys ikiwa faili hilo, saraka ya .ssh, au saraka ya nyumbani ya akaunti hiyo inaweza kuandikwa na mtu yeyote isipokuwa mmiliki. Sababu ni ya moja kwa moja: ikiwa kundi au ulimwengu unaweza kuandika kwenye saraka yako ya nyumbani, akaunti yoyote yenye ufikiaji huo inaweza kuchukua nafasi ya authorized_keys na kudhibiti uingiaji. sshd huchukulia njia isiyoaminika kama vile hakuna ufunguo uliopo.

Mteja huona ujumbe wa kawaida wa Permission denied. Logi ya seva hurekodi sababu halisi:

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

au, wakati faili lenyewe ndilo tatizo:

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

Kile ambacho sshd itakubali:

• Saraka ya nyumbani: isiweze kuandikwa na kundi na isiweze kuandikwa na ulimwengu. 755, 750 na 700 zote hupita. 775 na 777 hushindwa.
• ~/.ssh: mode 700.
• ~/.ssh/authorized_keys: mode 600.
• Umiliki: zote tatu lazima ziwe zinamilikiwa na akaunti unayoingia nayo, si na root.

Umiliki ni muhimu kama ilivyo mode. Faili ndani ya /home/deploy/.ssh linalomilikiwa na root hushindwa ukaguzi huo, jambo ambalo hutokea unapolitengeneza kwa sudo nano na kusahau kurudisha umiliki. Rekebisha yote kwa wakati mmoja:

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

Amri ya mwisho inaonyesha matokeo. Unataka drwxr-xr-x au kali zaidi kwenye saraka ya nyumbani na drwx------ kwenye .ssh. Ikiwa kamba hizo bado hazijawa wazi, soma jinsi ya kusoma kamba ya ruhusa kama drwxr-xr-x kabla ya kubadilisha mode kwenye seva inayofanya kazi.

Kwenye Rocky Linux na AlmaLinux, ongeza SELinux (security-enhanced Linux) kwenye orodha ya washukiwa. Saraka ya .ssh iliyotengenezwa kwa njia isiyo ya kawaida inaweza kubeba lebo ya faili isiyo sahihi, kwa hivyo sshd hukataliwa ufikiaji wa kusoma ingawa mode zinaonekana sawa. sudo restorecon -Rv /home/deploy/.ssh hurudisha lebo kwenye hali yake, na sudo ausearch -m avc -ts recent huonyesha ikiwa SELinux ndiyo sehemu iliyokuwa ikikataa.

Sababu 5: sshd imesanidiwa kukukataa

Kusoma /etc/ssh/sshd_config hakutoshi kwenye mfumo wa sasa wa Ubuntu au Debian. Faili hiyo huanza na Include /etc/ssh/sshd_config.d/*.conf, na OpenSSH huhifadhi thamani ya kwanza inayopata kwa mpangilio wowote. Faili ya ziada kama 50-cloud-init.conf kwa hivyo husomwa kwanza na kushinda chochote unachohariri chini kwenye faili kuu. Hii ndiyo sababu uhariri unaweza kuonekana kuwa sahihi lakini usibadilishe chochote.

Iulize sshd kuhusu usanidi unaotumia kweli:

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

Jibu zuri linaonekana hivi:

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

Mambo ya kuangalia katika matokeo yako:

• pubkeyauthentication no. Hakuna ufunguo utakaokubaliwa. Hii pia huonekana katika ssh -v kama orodha ya kwanza ya Authentications that can continue: bila publickey ndani yake.
• authorizedkeysfile inayoelekeza mahali pengine, kwa mfano /etc/ssh/authorized_keys/%u. Faili yako iliyo kwenye saraka ya nyumbani (home directory) hupuuzwa kabisa, na sheria za mode kutoka sababu 4 hutumika kwenye njia hiyo mpya badala yake.
• allowusers au allowgroups kuwepo. Akaunti yoyote isiyoorodheshwa hukataliwa na kosa hili hasa bila maelezo yoyote. denyusers na denygroups hufanya vivyo hivyo kwa njia ya kinyume.
• permitrootlogin no wakati unajaribu kuingia kama root. prohibit-password ndio mpangilio wa kati unaofaa: root anaweza kutumia ufunguo lakini si nenosiri.

Vizuizi vya Match havionekani kwenye sshd -T ya kawaida, kwa sababu matokeo yake hutegemea nani anaunganisha. Uliza kuhusu muunganisho mmoja mahususi:

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

Mpangilio mwingine huathiri funguo za zamani. OpenSSH 8.8 iliacha kukubali sahihi za SHA-1 (ssh-rsa) kwa chaguo-msingi, kwa hivyo ufunguo wa RSA uliokuwa ukifanya kazi kwa miaka mingi unaweza kuacha kufanya kazi mara tu baada ya kuboresha seva. Mteja husema hivyo waziwazi:

debug1: send_pubkey_test: no mutual signature algorithm

Suluhisho sahihi ni ufunguo mpya: ssh-keygen -t ed25519 -C "deploy@vps-prod", kisha sakinisha faili ya .pub kama ilivyoonyeshwa hapo juu. Kuweka PubkeyAcceptedAlgorithms +ssh-rsa kwenye seva huwezesha tena sahihi za zamani na kukuwezesha kuingia leo, kwa hivyo ichukulie kama njia ya kufikia seva, si kama mwisho wa kazi. Mipangilio mingine ya upande wa seva inayostahili kupitiwa iko katika kuimarisha seva ya SSH kwenye VPS.

Jinsi ya kuthibitisha ufunguo binafsi (private key) unalingana na ufunguo wa umma (public key) uliowekwa

Sehemu kubwa ya kubahatisha katika hitilafu hii inatokana na kutojua kama faili mbili ni jozi. Amri moja inajibu swali hili:

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

Hii huchapisha ufunguo wa umma uliotokana na ufunguo binafsi. Haiwahi kusoma faili ya .pub iliyo karibu nayo, kwa hivyo inakuambia ufunguo binafsi ni nini hasa badala ya kile ambacho faili ya zamani ya .pub inadai. Ikiwa ufunguo una passphrase, amri hiyo itaiomba, jambo ambalo pia linathibitisha kuwa bado unajua passphrase hiyo.

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

Ya kwanza huchapisha fingerprint ya faili moja ya ufunguo wa umma. Ya pili huchapisha fingerprint ambazo wakala wako anazo. Sasa panga maoni manne ya mfuatano uleule: fingerprint kwenye mstari wa Offering public key kutoka ssh -v, fingerprint ya faili yako ya .pub, fingerprint zilizomo ndani ya ssh-keygen -lf kwenye authorized_keys ya seva, na fingerprint iliyo kwenye log ya seva. Mahali ambapo hazilingani tena ndipo kosa lako lilipo.

Soma log ya seva wakati login inapofeli

Mteja hapewi taarifa yoyote muhimu kwa makusudi. Seva huandika sababu halisi. Anzisha ufuatiliaji wa log kwenye kikao cha console, kisha endesha amri ya ssh inayofeli kutoka kwenye laptop yako.

sudo journalctl -u ssh -f

Ubuntu 24.04 haisakinishi rsyslog kwa chaguo-msingi, kwa hivyo /var/log/auth.log inaweza isiwepo hapo. Kwenye Rocky Linux na AlmaLinux unit hiyo inaitwa sshd na rekodi zilezile pia huenda kwenye /var/log/secure.

Weka LogLevel VERBOSE kwenye usanidi wa sshd na uanzishe upya huduma hiyo. Kila jaribio hurekodi fingerprint ambayo seva imepokea:

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

Mstari huo unakuambia upande upi una tatizo. Fingerprint unayoitambua inamaanisha ufunguo wako umefika na kukataliwa na seva, kwa hivyo angalia sababu 3, 4 na 5. Fingerprint usiyoijua inamaanisha mteja wako ametuma ufunguo usioukusudia, kwa hivyo rudi kwenye sababu 2.

Wakati log bado haijawa wazi, endesha sshd ya pili kwenye port nyingine katika hali ya debug. Inabaki mbele, inahudumia muunganisho mmoja, inachapisha sababu zake, kisha inajifunga:

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

Kutoka kwenye kikao cha console kwenye seva hiyo hiyo, ungana nayo kupitia loopback address:

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

Kupitia 127.0.0.1 kunaiweka firewall nje ya jaribio hili. Matokeo ya debug yanataja faili iliyofunguliwa, fingerprint iliyolinganishwa, na sababu kamili ya kukataa, ikijumuisha mistari kama Authentication refused: bad ownership or modes for directory /home/deploy. Bonyeza Ctrl+C unapopata jibu lako. sshd halisi kwenye port 22 haiguswi wakati wote huu.

Jinsi ya kuepuka kujifungia nje ya seva

Kila hatua inayobadilisha usanidi wa seva inahitaji njia mbadala ya kuingia ambayo haitegemei SSH. Sanidi njia hii wakati SSH bado inafanya kazi, si baada ya kuharibika.

1. Fungua console ya mtoa huduma wako, kupitia serial au VNC (virtual network computing), na uhakikishe kuwa unaweza kuingia huko.
2. Hakikisha unajua nenosiri la ndani linalofanya kazi kwa akaunti yenye haki za sudo. Ikiwa huna, weka upya nenosiri la root kutoka kwenye console ya mtoa huduma kwanza.
3. Acha kikao chako cha sasa cha SSH kikiwa wazi. Kikao kilicho wazi kinaendelea kufanya kazi hata baada ya systemctl restart ssh, kwa hivyo kinabaki kuwa njia ya kuingia ikiwa usanidi mpya una makosa.
4. Kagua sintaksia kabla ya kuanzisha upya: sudo sshd -t haitoi ujumbe wowote wakati faili ni sahihi, na huchapisha faili na namba ya mstari wakati si sahihi.
5. Fungua terminal ya pili na uingie upya kabla ya kufunga ile ya kwanza. Usanidi uliovunjika huzuia maingizo mapya lakini huacha yale yaliyopo yakiendelea, kwa hivyo kikao ulichomo hakiwezi kukuambia ikiwa mabadiliko yamefanya kazi.

Anzisha upya kwa kutumia sudo systemctl restart ssh kwenye Debian na Ubuntu, au sudo systemctl restart sshd kwenye Rocky Linux na AlmaLinux. Kwenye Ubuntu 24.04, sshd huanzishwa kutoka kwa socket unit, kwa hivyo mabadiliko kwenye Port au ListenAddress yanahitaji pia sudo systemctl restart ssh.socket kabla ya kuanza kufanya kazi.

FAQ

Kwa nini ninapata Permission denied (publickey) wakati ufunguo uleule unafanya kazi kwenye seva nyingine?

Kwa sababu ufunguo wenyewe ni sahihi lakini kuna kitu kinachouzunguka ambacho si sahihi. Tekeleza ssh -v na utafute mstari wa Offering public key. Ikiwa ufunguo wako haujaorodheshwa, ssh haukuutuma: faili halipo kwenye ~/.ssh kwa jina la kawaida na halijapakiwa kwenye agent, kwa hiyo ongeza -i /path/to/key -o IdentitiesOnly=yes. Ikiwa ufunguo umeorodheshwa na seva bado inakataa, basi ufunguo huo haupo kwenye authorized_keys ya akaunti hiyo, njia ya kufikia faili hilo ina ruhusa ya kuandikwa na kundi (group-writable), au usanidi wa sshd unamzuia mtumiaji huyo. Log ya seva hutofautisha visa hivi.

Ninawezaje kuona ni ufunguo upi SSH inatuma kweli?

ssh -v host huchapisha mstari mmoja wa debug1: Offering public key: kwa kila ufunguo, kila mmoja ukionyesha faili asilia na SHA256 fingerprint. ssh-add -l huorodhesha fingerprint zilizopo kwenye agent. ssh-keygen -lf ~/.ssh/id_ed25519.pub huchapisha fingerprint ya faili moja la ufunguo, na ssh-keygen -y -f ~/.ssh/id_ed25519 huchapisha ufunguo wa umma (public key) unaotokana na ufunguo wa siri (private key). Ili kuingia kufanikiwa, fingerprint kutoka kwenye mstari wa Offering lazima pia ionekane kwenye ssh-keygen -lf inayotekelezwa dhidi ya authorized_keys ya seva.

Kwa nini sshd inapuuza faili langu la authorized_keys?

Kwa sababu StrictModes imewashwa kwa chaguo-msingi, na aidha faili hilo, saraka ya .ssh, au saraka ya nyumbani (home directory) inaweza kuandikwa na kundi au watu wengine, au inamilikiwa na akaunti isiyo sahihi. sshd haitaamini njia ambayo mtu mwingine anaweza kuibadilisha, kwa hiyo inafanya kazi kana kwamba hakuna ufunguo uliopo. Weka saraka ya nyumbani kuwa 755 au zaidi, .ssh kuwa 700, authorized_keys kuwa 600, na uhakikishe vyote vitatu vinamilikiwa na akaunti ya kuingia. Kwa LogLevel VERBOSE seva hurekodi Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Ufunguo wangu uliacha kufanya kazi mara tu baada ya kuboresha seva. Nini kimebadilika?

Ikiwa ni ufunguo wa RSA, hii inawezekana sana ni mabadiliko ya SHA-1. OpenSSH 8.8 ilizima saini za ssh-rsa SHA-1 kwa chaguo-msingi, kwa hiyo ufunguo unaoweza kusaini kwa njia hiyo pekee sasa unakataliwa. Matokeo ya kina ya mteja (verbose client output) yanaonyesha debug1: send_pubkey_test: no mutual signature algorithm. Tengeneza ufunguo wa kisasa kwa ssh-keygen -t ed25519 na usakinishe faili lake la .pub. Ikiwa unahitaji ufikiaji mara moja, PubkeyAcceptedAlgorithms +ssh-rsa kwenye seva huwasha tena saini za zamani, na unapaswa kuondoa mstari huo mara tu ufunguo mpya utakapofanya kazi.

Nimehariri sshd_config na sasa siwezi kuingia kabisa. Ninawezaje kurudi ndani?

Tumia console ya mtoa huduma wako, ambayo haipiti kwenye SSH. Ingia huko kwa kutumia nenosiri la ndani (local password), tekeleza sudo sshd -t ili kuona kosa la sintaksia na namba ya mstari wake, tengua mabadiliko hayo, na uanzishe upya huduma hiyo. Kisha angalia sudo sshd -T ili kuthibitisha thamani zinazofanya kazi, kwa sababu faili lililopo kwenye /etc/ssh/sshd_config.d/ linaweza kuwa linabatilisha usanidi mkuu. Ikiwa huna nenosiri la ndani, weka upya nenosiri la root kutoka kwenye console kwanza, kisha rekebisha faili hilo.