Hvordan kan du fikse en "Permission denied (publickey)" SSH-feil på Linux?

SSH er et nyttig verktøy for å koble til eksterne maskiner, men du kan støte på en "Permission denied (publickey)"-feil som involverer den offentlige nøkkelen din på Linux. Heldigvis er det noen enkle rettelser du kan prøve for å feilsøke det.

Hva er en offentlig nøkkel?

Når du genererer et nøkkelpar for SSH på Linux, får du en offentlig nøkkel og en privat nøkkel. Den private nøkkelen vil forbli hos deg som en tett bevoktet hemmelighet, men den offentlige nøkkelen er det som vil bli overført til eksterne servere for å la deg logge på uten passord. Din lokale SSH-klient vil matche den offentlige nøkkelen med den private nøkkelen når du kobler til.

Fordelen med denne metoden er at du bare trenger å gi ut den offentlige nøkkelen. Så lenge du holder din private nøkkel privat, bør dette holde deg sikker i tilfelle den offentlige nøkkelen blir kompromittert. Den offentlige nøkkelen vil være ubrukelig i seg selv.

OpenSSH, den mest brukte SSH-klienten og serveren i åpen kildekode-verden, krever at filen inneholder offentlige nøkler på den eksterne maskinen (".ssh/authorized_keys" i hjemmekatalogen din), for å ha visse tillatelser. Det vil ikke fungere hvis skrivetillatelsene er satt for andre brukere, som er kjent som "verdensskrivbare". Fordi katalognavnet starter med et punktum (.), vil det ikke vises i noen ls-oppføringer med mindre du bruker kommando

ls -A.

Tillatelser kan endres hvis filen ble kopiert over fra en annen datamaskin eller du opprettet den selv. Heldigvis er dette enkelt å fikse.

Sjekk dine offentlige nøkkeltillatelser

Authorized_keys-filen er ganske enkelt en ren tekstfil som inneholder alle de offentlige nøklene fra klienter du ønsker for å kunne logge på kontoen din på den eksterne maskinen. For å se tillatelsene, bruk ls-kommandoen med alternativet -l:

ls -l ~/.ssh/authorized_keys

Dette vil vise tillatelsesinnstillingene for eieren, gruppen og andre brukere. Vær oppmerksom på de seks siste bokstavene i strengen. Hvis du ser "w" i dem, betyr det at gruppen eller andre kan skrive til den, noe som gjør den usikker.

Du vil at denne filen skal være skrivbar av deg, men ikke av gruppen eller andre. For å gi tilgang til de riktige brukerne, du kan endre tillatelser med chmod.

Det er to måter: numerisk og symbolsk.

Den numeriske måten er kortere, men du må huske de oktale tillatelsesnumrene:

chmod 700 ~/.ssh/authorized_keys

Den symbolske metoden er mer mnemonisk:

chmod go-w ~/.ssh/authorized_keys

Trygg kopiering av nøkler ved hjelp av ssh-agent

Du kan manuelt kopiere og lime inn alle offentlige nøkler fra maskinen din i ~/.ssh/.authorized_keys fil, men bruk av ssh-agent-programmet vil redusere sjansene for eventuelle tillatelsesfeil.

For å starte ssh-agent, bruk denne kommandoen:

eval "$(ssh-agent-s)"

For å logge på en ekstern server ved hjelp av ssh-agent, bruk alternativet -A med ssh

ssh -A [email protected]

Sjekk den eksterne serverens sshd-innstillinger

Hvis noen av disse forsøkene mislykkes, må du kanskje gjøre noen konfigurasjonsendringer på sshd-serveren på den eksterne maskinen hvis du har root-tilgang. Hvis ikke, må du sannsynligvis ta kontakt med systemadministratoren for å hjelpe deg med å løse eventuelle SSH-tilkoblingsproblemer. Dette er en siste utvei fordi det kan gjøre systemet ditt mindre sikkert.

Den systemomfattende konfigurasjonsfilen for sshd er /etc/ssh/sshd_config. Fordi det eies av root, må du bruke sudo for å redigere det. For eksempel, for å redigere den med Vim:

sudo vim /etc/ssh/sshd_config

For å aktivere sshd for å la deg logge på selv om filen authorized_keys er verdensskrivbar, sett alternativet "StrictModes" til "nei" i denne filen.

Lagre den og start SSH-serveren på nytt:

sudo systemctl restart sshd.service

Nå kan du fikse SSH Public Key Permissions-feil

Du kan støte på feil angående offentlige SSH-nøkler på eksterne systemer. Heldigvis er det meste av tiden alt du trenger å gjøre å sjekke og angi filtillatelsene slik at ingen andre kan se nøkkelen din. Du kan også bruke ssh-agent for mer pålitelige tilkoblinger. Som en siste utvei kan du gjøre SSH-serveren mindre streng.