SSH Permission denied (publickey) oplossen

Wat Permission denied (publickey) daadwerkelijk betekent

Permission denied (publickey) betekent dat uw client een of meer publieke sleutels heeft verzonden en de server er geen enkele heeft geaccepteerd. Het netwerk functioneert naar behoren en sshd draait: de weigering vindt plaats in de laatste stap van de authenticatie. Als uw sessie vóór dat punt wordt verbroken, is er sprake van connection refused of connection timed out; dit is een andere diagnose die andere tests vereist. De oplossing is nooit een kwestie van gokken, omdat ssh -v u vertelt welke van de vijf oorzaken bij u van toepassing is.

De woorden tussen de haakjes zijn de methoden die de server bereid was te accepteren. Permission denied (publickey) op zichzelf betekent dat wachtwoordinlog op die server is uitgeschakeld, waardoor er geen wachtwoord is om op terug te vallen. Permission denied (publickey,password) betekent dat wachtwoorden werden aangeboden en dat u ook daarvoor bent afgewezen.

Eén melding dekt vijf afzonderlijke fouten en is bewust vaag gehouden. Een server die zou antwoorden met "no such user" of "that key is not installed" zou iedereen helpen die scant op geldige accounts. Begin daarom niet met het uitwisselen van sleutels of het bewerken van configuratiebestanden. Voer één commando uit, lees drie regels output, en de vijf mogelijke oorzaken worden teruggebracht tot één.

Run ssh -v first, and read three lines

Repeat the command that failed, with -v added:

ssh -v deploy@203.0.113.10

A trimmed but realistic run looks like this:

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

Three lines carry everything you need.

Authenticating to 203.0.113.10:22 as 'deploy' is the username that will actually be used. Not the one you meant to use: the one ssh worked out from the command line, from ~/.ssh/config, or from your local login name.

Authentications that can continue: publickey is the server's list of accepted methods, sent before any key is tried. If publickey is missing from that first list, the server has public key login switched off, so no key can ever work.

Offering public key: ... is one line per key your client really sent, naming the file it came from and its SHA256 fingerprint. A key with no Offering line was never sent to the server.

Now split the problem in two:

• There is no Offering public key line for the key you expect. The fault is on your machine, because the server has not seen your key at all.
• The key is offered and Authentications that can continue: publickey comes back again. The server received that key and refused it, so the fault is on the server.

The causes below are ordered by how often they turn out to be the answer.

Oorzaak 1: u maakt verbinding met de verkeerde gebruikersnaam

De meest voorkomende oorzaak is tevens de minst interessante. sshd, de SSH (secure shell) server-daemon, meldt nooit dat een account niet bestaat. Het proces voert de volledige uitwisseling uit voor een verzonnen gebruikersnaam en weigert aan het einde met dezelfde melding, omdat het lekken van geldige accountnamen een aanvaller helpt. Een typefout in de gebruikersnaam ziet er precies zo uit als een defecte sleutel.

Controleer de Authenticating to ... as regel voordat u iets anders doet. Als hier de inlognaam van uw laptop staat in plaats van het serveraccount, dan bent u vergeten de gebruikersnaam in het commando op te geven.

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

Het standaardaccount hangt af van de image die uw provider gebruikt. Sinds augustus 2026 bevatten Ubuntu-cloudimages meestal een ubuntu-account, Debian-images bevatten debian of admin, Rocky Linux en AlmaLinux bevatten rocky en almalinux, en veel VPS-providers installeren uw sleutel direct in root. Het configuratiescherm van uw provider vermeldt welk account er is aangemaakt. Geen enkel commando dat vanaf buiten de server wordt uitgevoerd, kan dit opvragen.

Een Host-blok in ~/.ssh/config stelt ook de gebruikersnaam in, en deze instelling krijgt voorrang op uw lokale inlognaam:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Als u het account zelf heeft aangemaakt en vervolgens niet kon inloggen, is de sleutel waarschijnlijk geïnstalleerd voor de standaardgebruiker van de image en nooit gekopieerd naar het nieuwe account. Die stap is onderdeel van de eerste tien minuten op een nieuwe VPS, en het is eenvoudig om deze over te slaan.

Oorzaak 2: de sleutel die u denkt te versturen is niet de sleutel die daadwerkelijk wordt verstuurd

Standaard biedt ssh alleen de sleutels aan die in ssh-agent staan, plus een vaste set bestandsnamen in ~/.ssh: id_ed25519, id_ecdsa, id_rsa, en de hardware- en DSA-varianten van deze namen. Een sleutel die is opgeslagen als ~/.ssh/vps-prod is onzichtbaar voor ssh totdat u deze expliciet benoemt. Dit is de reden waarom de uitgebreide uitvoer geen Offering public key-regel voor dit bestand toont.

Geef het bestand op en voorkom dat de agent-sleutels voorrang krijgen:

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

-i alleen is niet voldoende wanneer de agent sleutels bevat, omdat ssh nog steeds eerst de sleutels van de agent aanbiedt en het opgegeven bestand als laatste. Dit is van belang omdat de server elke geweigerde sleutel meetelt voor MaxAuthTries, dat standaard op 6 staat. Een agent die zeven sleutels bevat, kan de limiet bereiken voordat uw juiste sleutel wordt bereikt. De melding verandert dan in:

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

Als u in plaats daarvan dit bericht ziet, heeft de server de sessie beëindigd voordat uw juiste sleutel aan de beurt kwam. Dit valt onder te veel authenticatiefouten. IdentitiesOnly=yes beperkt de poging tot het bestand dat u hebt opgegeven. Bekijk welke sleutels de agent bevat met ssh-add -l en wis deze met ssh-add -D als er in de loop der jaren oude sleutels zijn verzameld. Leg de instellingen vervolgens vast, zodat de volgende aanmelding niet afhankelijk is van het onthouden van flags:

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

Nog een valkuil aan de clientzijde. ssh weigert een privésleutel te gebruiken die door andere accounts op uw eigen machine kan worden gelezen. Het programma geeft een waarschuwing en negeert de sleutel vervolgens, waardoor de sleutel nooit wordt aangeboden en de server deze nooit ziet:

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

chmod 600 ~/.ssh/vps-prod lost dit op. Het verplaatsen van een sleutel via een USB-stick of een Windows-share is de gebruikelijke manier waarop de rechten verloren gaan. Waar sleutels worden opgeslagen en hoe ze moeten worden genoemd, wordt behandeld in Basisprincipes van SSH-sleutelbeheer.

Oorzaak 3: de public key heeft authorized_keys nooit bereikt

Als ssh -v laat zien dat de key is verzonden en de server nog steeds weigert, is de volgende vraag of die key in het authorized_keys-bestand van het account staat. Open de console van uw provider om dit te controleren, aangezien u niet via SSH kunt inloggen om te kijken.

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

ssh-keygen -lf op een authorized_keys-bestand print één fingerprint per regel:

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

Vergelijk deze met de fingerprint op uw Offering public key-regel. Als deze niet in de lijst staat, is de key niet op dat account geïnstalleerd, ongeacht wat u zich herinnert te hebben gedaan.

Vier manieren waarop dit misgaat, die allemaal veel voorkomen:

• U heeft de private key geplakt in plaats van de inhoud van het .pub-bestand. Een regel met een public key begint met ssh-ed25519 of ssh-rsa. Een private key begint met -----BEGIN OPENSSH PRIVATE KEY-----.
• Het plakken heeft tekst over meerdere regels verdeeld. Elke invoer moet op precies één regel staan; een afgebroken key wordt gelezen als meerdere ongeldige regels en komt met niets overeen.
• De key is in /root/.ssh/authorized_keys geplaatst terwijl u inlogt als deploy, of andersom. Het bestand is per account en er is geen gedeeld bestand.
• Het "add my key"-veld van de provider heeft de key alleen geschreven naar de standaardgebruiker van de image, waardoor het account dat u later aanmaakte een lege .ssh-directory heeft.

De veilige manier om een key toe te voegen via de console, als 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

Voer daarna opnieuw sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys uit. De nieuwe fingerprint zou nu in de lijst moeten staan. Vanaf een machine die nog wel met een wachtwoord kan inloggen, doet ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 hetzelfde werk en stelt het de rechten correct voor u in.

Oorzaak 4: waarom sshd authorized_keys negeert bij te ruime rechten

StrictModes yes is de standaardinstelling van sshd. Hieronder weigert sshd om authorized_keys te lezen als dat bestand, de map .ssh of de home-directory van het account door iemand anders dan de eigenaar kan worden gewijzigd. De reden is direct: als de groep of anderen schrijfrechten hebben op uw home-directory, kan elk account met die toegang authorized_keys vervangen en de login overnemen. sshd behandelt een onbetrouwbaar pad alsof er geen sleutel bestaat.

De client ziet de algemene melding Permission denied. Het serverlogboek registreert de werkelijke reden:

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

of, wanneer het bestand zelf het probleem is:

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

Wat sshd accepteert:

• De home-directory: niet schrijfbaar voor de groep en niet schrijfbaar voor anderen. 755, 750 en 700 voldoen allemaal. 775 en 777 falen.
• ~/.ssh: modus 700.
• ~/.ssh/authorized_keys: modus 600.
• Eigendom: alle drie moeten eigendom zijn van het account waarmee u inlogt, niet van root.

Eigendom is net zo belangrijk als de modus. Een bestand in /home/deploy/.ssh dat eigendom is van root faalt voor dezelfde controle; dit gebeurt wanneer u het aanmaakt met sudo nano en vergeet het eigendom terug te geven. Herstel beide tegelijk:

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

Het laatste commando toont het resultaat. U wilt drwxr-xr-x of strikter op de home-directory en drwx------ op .ssh. Als deze reeksen nog niet duidelijk zijn, lees dan hoe u een rechtenreeks zoals drwxr-xr-x leest voordat u de modi op een live server wijzigt.

Voeg op Rocky Linux en AlmaLinux SELinux (security-enhanced Linux) toe aan de lijst met verdachten. Een map .ssh die via een ongebruikelijke route is aangemaakt, kan het verkeerde bestandlabel dragen, waardoor sshd de leestoegang wordt geweigerd, zelfs als de modi correct lijken. sudo restorecon -Rv /home/deploy/.ssh herstelt de labels en sudo ausearch -m avc -ts recent laat zien of SELinux de component was die de toegang weigerde.

Oorzaak 5: sshd is geconfigureerd om u te weigeren

Het lezen van /etc/ssh/sshd_config is op een modern Ubuntu- of Debian-systeem niet voldoende. Dat bestand begint met Include /etc/ssh/sshd_config.d/*.conf, en OpenSSH hanteert de eerste waarde die het voor een instelling tegenkomt. Een drop-in bestand zoals 50-cloud-init.conf wordt daarom als eerste gelezen en krijgt voorrang op alles wat u lager in het hoofdconfiguratiebestand aanpast. Dit is de reden waarom een wijziging correct kan lijken, maar geen enkel effect heeft.

Vraag sshd welke configuratie daadwerkelijk wordt gebruikt:

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

Een gezond antwoord ziet er als volgt uit:

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

Waar u in uw eigen uitvoer op moet letten:

• pubkeyauthentication no. Geen enkele sleutel wordt geaccepteerd. Dit verschijnt ook in ssh -v als een eerste Authentications that can continue:-lijst zonder publickey erin.
• authorizedkeysfile die naar een andere locatie wijst, bijvoorbeeld /etc/ssh/authorized_keys/%u. Uw bestand in de thuismap wordt dan volledig genegeerd en de rechtenregels uit oorzaak 4 zijn in plaats daarvan van toepassing op het nieuwe pad.
• allowusers of allowgroups aanwezig. Elk account dat niet in de lijst staat, wordt geweigerd met precies deze foutmelding en zonder verdere uitleg. denyusers en denygroups doen hetzelfde in omgekeerde volgorde.
• permitrootlogin no terwijl u probeert in te loggen als root. prohibit-password is de nuttige tusseninstelling: root mag een sleutel gebruiken, maar geen wachtwoord.

Match-blokken verschijnen niet in een standaard sshd -T, omdat het resultaat afhangt van wie er verbinding maakt. Vraag informatie op over één specifieke verbinding:

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

Nog één instelling is van invloed op oudere sleutels. OpenSSH 8.8 is gestopt met het standaard accepteren van SHA-1-handtekeningen (ssh-rsa), waardoor een RSA-sleutel die jarenlang werkte, direct na een serverupgrade kan stoppen met werken. De client geeft dit duidelijk aan:

debug1: send_pubkey_test: no mutual signature algorithm

De juiste oplossing is een nieuwe sleutel: ssh-keygen -t ed25519 -C "deploy@vps-prod", en installeer vervolgens het .pub-bestand zoals hierboven getoond. Het instellen van PubkeyAcceptedAlgorithms +ssh-rsa op de server schakelt de oude handtekeningen weer in en geeft u vandaag toegang; beschouw dit echter als een manier om de server te bereiken, niet als de definitieve oplossing. De overige serverinstellingen die het bekijken waard zijn, vindt u in het beveiligen van de SSH-server op een VPS.

Hoe u controleert of een private key overeenkomt met de geïnstalleerde public key

Het meeste giswerk bij deze fout komt voort uit onzekerheid of twee bestanden een paar vormen. Eén commando geeft uitsluitsel:

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

Dit drukt de public key af die is afgeleid van de private key. Het leest nooit het .pub-bestand dat ernaast staat; het toont u dus wat de private key werkelijk is, in plaats van wat een verouderd .pub-bestand beweert. Als de key een wachtwoordzin heeft, vraagt het commando hierom, wat tevens bewijst dat u de wachtwoordzin nog kent.

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

Het eerste commando drukt de vingerafdruk van een public key-bestand af. Het tweede drukt de vingerafdrukken af die uw agent in het geheugen heeft. Vergelijk nu vier weergaven van dezelfde reeks: de vingerafdruk op de Offering public key-regel uit ssh -v, de vingerafdruk van uw .pub-bestand, de vingerafdrukken in ssh-keygen -lf op de authorized_keys van de server, en de vingerafdruk in het serverlogboek. Het punt waarop ze niet meer overeenkomen, is waar de fout ligt.

Lees het serverlogboek terwijl de aanmelding mislukt

De client krijgt bewust geen nuttige informatie. De server schrijft de werkelijke reden weg. Start een log-volger in de consolesessie en voer vervolgens het falende ssh-commando uit vanaf uw laptop.

sudo journalctl -u ssh -f

Ubuntu 24.04 installeert standaard geen rsyslog, waardoor /var/log/auth.log daar mogelijk niet bestaat. Op Rocky Linux en AlmaLinux heet de unit sshd en komen dezelfde gegevens ook terecht in /var/log/secure.

Stel LogLevel VERBOSE in de sshd-configuratie in en herlaad de service. Elke poging logt vervolgens de vingerafdruk die de server daadwerkelijk heeft ontvangen:

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

Die regel vertelt u aan welke kant de fout ligt. Een vingerafdruk die u herkent, betekent dat uw sleutel is aangekomen en door de server is geweigerd; kijk in dat geval naar oorzaken 3, 4 en 5. Een vingerafdruk die u niet herkent, betekent dat uw client een sleutel heeft verzonden die u niet bedoelde; ga in dat geval terug naar oorzaak 2.

Wanneer het logboek nog steeds onduidelijk is, start dan een tweede sshd op een andere poort in debug-modus. Deze blijft op de voorgrond draaien, bedient één verbinding, print de redenering en sluit vervolgens af:

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

Maak vanuit de consolesessie op dezelfde server verbinding via het loopback-adres:

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

Door via 127.0.0.1 te werken, blijft de firewall buiten de test. De debug-uitvoer benoemt het bestand dat werd geopend, de vingerafdruk die werd vergeleken en de exacte weigering, inclusief regels zoals Authentication refused: bad ownership or modes for directory /home/deploy. Druk op Ctrl+C wanneer u het antwoord heeft. De actieve sshd op poort 22 blijft gedurende het hele proces ongewijzigd.

Hoe u voorkomt dat u uzelf buitensluit

Elke stap waarbij u de serverconfiguratie wijzigt, vereist een noodoplossing voor toegang die niet afhankelijk is van SSH. Richt dit in terwijl SSH nog werkt, niet pas nadat de verbinding is verbroken.

1. Open de console van uw provider via serial of VNC (virtual network computing) en bevestig dat u daar kunt inloggen.
2. Zorg dat u een werkend lokaal wachtwoord kent voor een account met sudo-rechten. Als u dit niet heeft, stel dan eerst het root-wachtwoord opnieuw in via de console van de provider.
3. Houd uw huidige SSH-sessie open. Een actieve sessie blijft bestaan bij systemctl restart ssh, waardoor dit een uitweg biedt als de nieuwe configuratie onjuist is.
4. Controleer de syntaxis voordat u de service herstart: sudo sshd -t geeft geen uitvoer als het bestand geldig is, en toont het bestand en regelnummer als er een fout is.
5. Open een tweede terminal en log opnieuw in voordat u de eerste sessie sluit. Een defecte configuratie blokkeert nieuwe aanmeldingen, maar laat bestaande sessies intact; de sessie waarin u werkt kan dus niet bevestigen of de wijziging succesvol was.

Herstart met sudo systemctl restart ssh op Debian en Ubuntu, of sudo systemctl restart sshd op Rocky Linux en AlmaLinux. Op Ubuntu 24.04 wordt sshd gestart vanuit een socket-unit, dus een wijziging in Port of ListenAddress vereist ook sudo systemctl restart ssh.socket voordat deze van kracht wordt.

FAQ

Waarom krijg ik de melding Permission denied (publickey) terwijl dezelfde sleutel wel werkt op een andere server?

Omdat de sleutel in orde is, maar de omgeving eromheen niet. Voer ssh -v uit en zoek de regel Offering public key. Als uw sleutel daar niet tussen staat, heeft ssh deze nooit verzonden: het bestand staat niet onder een standaardnaam in ~/.ssh en is niet geladen in de agent; voeg deze toe met -i /path/to/key -o IdentitiesOnly=yes. Als de sleutel wel wordt vermeld en de server weigert nog steeds, dan ontbreekt de sleutel in het bestand authorized_keys van het account, is het pad ernaartoe schrijfbaar voor de groep, of blokkeert de sshd-configuratie de gebruiker. Het serverlogboek maakt onderscheid tussen deze gevallen.

Hoe zie ik welke sleutel SSH daadwerkelijk verzendt?

ssh -v host toont één debug1: Offering public key:-regel per sleutel, met vermelding van het bronbestand en een SHA256-vingerafdruk. ssh-add -l toont de vingerafdrukken die de agent bevat. ssh-keygen -lf ~/.ssh/id_ed25519.pub toont de vingerafdruk van een enkel sleutelbestand en ssh-keygen -y -f ~/.ssh/id_ed25519 toont de publieke sleutel die daadwerkelijk bij een privésleutel hoort. Om de aanmelding te laten slagen, moet de vingerafdruk van de Offering-regel ook voorkomen in de uitvoer van ssh-keygen -lf, uitgevoerd op het bestand authorized_keys van de server.

Waarom negeert sshd mijn authorized_keys-bestand?

Omdat StrictModes standaard is ingeschakeld en het bestand, de map .ssh of de thuismap schrijfbaar is voor de groep of anderen, of eigendom is van het verkeerde account. sshd vertrouwt geen pad dat door anderen gewijzigd kan worden en gedraagt zich daarom alsof er geen sleutel bestaat. Zet de rechten van de thuismap op 755 of strikter, .ssh op 700, authorized_keys op 600, en zorg dat alle drie eigendom zijn van het inlogaccount. Met LogLevel VERBOSE registreert de server Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Mijn sleutel werkte niet meer direct na een serverupgrade. Wat is er veranderd?

Als het een RSA-sleutel is, komt dit hoogstwaarschijnlijk door de wijziging met betrekking tot SHA-1. OpenSSH 8.8 heeft ssh-rsa SHA-1-handtekeningen standaard uitgeschakeld, waardoor een sleutel die alleen op die manier kan ondertekenen nu wordt geweigerd. De uitgebreide client-uitvoer toont debug1: send_pubkey_test: no mutual signature algorithm. Genereer een moderne sleutel met ssh-keygen -t ed25519 en installeer het bijbehorende .pub-bestand. Als u direct toegang nodig heeft, schakelt PubkeyAcceptedAlgorithms +ssh-rsa op de server de oude handtekeningen weer in; verwijder deze regel zodra de nieuwe sleutel werkt.

Ik heb sshd_config bewerkt en kan nu helemaal niet meer inloggen. Hoe krijg ik weer toegang?

Gebruik de console van uw provider, die niet via SSH verloopt. Log daar in met een lokaal wachtwoord, voer sudo sshd -t uit om de syntaxfout en het regelnummer te zien, maak de wijziging ongedaan en herstart de service. Controleer daarna sudo sshd -T om de actieve waarden te bevestigen, aangezien een bestand in /etc/ssh/sshd_config.d/ de hoofdconfiguratie kan overschrijven. Als u geen lokaal wachtwoord heeft, reset dan eerst het root-wachtwoord via de console en herstel daarna het bestand.