SSH-fout "Permission denied (publickey)" oplossen

De verbindingspoging breekt na een seconde af, er komt geen wachtwoordprompt, alleen één enkele regel: Permission denied (publickey). Deze melding is zo vervelend omdat ze met opzet niets prijsgeeft. De SSH-server vertelt een mogelijke aanvaller niet of de gebruiker bestaat, of de sleutel verkeerd was, of dat het bestand onleesbaar is. Precies diezelfde terughoudendheid treft echter ook u, terwijl u met alle recht voor de deur staat.

Het goede nieuws: het aantal oorzaken is beperkt, ze laten zich in een vaste volgorde aflopen, en in de meeste gevallen zijn het gewoon de bestandsrechten. Dit artikel loopt de oorzaken langs op volgorde van hoe vaak ze voorkomen, toont bij elke oorzaak de letterlijke regel uit het log en legt uit hoe u met ssh -vvv in dertig seconden bepaalt of het probleem op uw eigen computer of op de server ligt.

Wat de melding precies betekent

De haakjes aan het eind zijn geen opsmuk, ze bevatten de belangrijkste informatie van de hele regel. Daarin staat welke authenticatiemethoden de server na de mislukte poging nog aanbiedt:

Permission denied (publickey).
Permission denied (publickey,password).
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Staat er alleen publickey, dan is het inloggen met een wachtwoord op de server uitgeschakeld. Staat password ook in de lijst, dan was inloggen met een wachtwoord in principe mogelijk geweest; het is alleen niet geprobeerd of eveneens mislukt. De variant met gssapi is typisch voor AlmaLinux, Rocky Linux en RHEL, want daar is ondersteuning voor Kerberos meegecompileerd.

Belangrijk is het onderscheid met meldingen die er vergelijkbaar uitzien, maar een heel ander probleem beschrijven:

• Permission denied, please try again. zonder haakjes betekent een verkeerd wachtwoord, geen sleutelprobleem.
• Host key verification failed. gaat over de serversleutel in uw known_hosts, niet over uw eigen sleutel.
• Received disconnect from 203.0.113.7 port 22:2: Too many authentication failures betekent dat uw agent te veel sleutels achter elkaar heeft aangeboden en dat de server na MaxAuthTries heeft afgebroken.
• Connection refused of een time-out zijn netwerk- of firewallkwesties. Hebt u kort daarvoor iets veranderd aan een UFW-firewall of aan Fail2ban, begin dan daar.

De tweesprong: ssh -vvv goed lezen

Verander nog niets, maar laat eerst het verloop zien. Drie keer v is met opzet, bij één v ontbreken juist de doorslaggevende regels:

ssh -vvv deploy@203.0.113.7

De uitvoer is lang, maar u zoekt slechts vier plekken. Ten eerste de gebruikersnaam waarmee daadwerkelijk verbinding wordt gemaakt:

debug1: Authenticating to 203.0.113.7:22 as 'deploy'

Ten tweede welke sleutels de client in overweging neemt, en ten derde welke sleutel hij werkelijk verstuurt:

debug1: Will attempt key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk... agent
debug1: Offering public key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

En ten vierde de succesmelding, die bij een fout nu juist ontbreekt:

debug1: Server accepts key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk...
debug1: Authenticated to 203.0.113.7 ([203.0.113.7]:22) using "publickey".

Daaruit volgt de tweesprong die u het halve zoekwerk bespaart:

• Er verschijnt geen Offering public key met uw sleutel. Dan ligt het probleem op uw eigen computer, de sleutel is nooit verstuurd. Ga meteen naar oorzaak 3.
• Er verschijnt Offering public key, maar daarna opnieuw Authentications that can continue. Dan heeft de server uw sleutel gezien en geweigerd. Dat zijn de oorzaken 1, 2, 4, 5 en 6, allemaal aan de serverkant.
• Er verschijnt send_pubkey_test: no mutual signature algorithm. Dan gaat het om het sleuteltype, ga meteen naar oorzaak 7.

Twee andere regels uit de debuguitvoer zijn een blik waard. debug3: no such identity: /home/tom/.ssh/id_rsa: No such file or directory is onschuldig, de client loopt simpelweg alle standaardnamen af. Permissions 0644 for '/home/tom/.ssh/id_ed25519' are too open. is daarentegen een echte treffer: uw privésleutel wordt dan genegeerd.

De serverkant: sshd -T en de logs

ssh -vvv toont uitsluitend het beeld van de client. Waarom de server geweigerd heeft, staat alleen in het serverlog. Hebt u nog een sessie openstaan of komt u via de console in het klantenpaneel binnen, kijk daar dan als eerste.

Op Debian en Ubuntu heet de service ssh, op AlmaLinux, Rocky Linux en RHEL heet hij sshd. Dat is een klassieke valkuil bij het kopiëren van commando's:

journalctl -u ssh -n 50 --no-pager      # Debian, Ubuntu
journalctl -u sshd -n 50 --no-pager     # AlmaLinux, Rocky, RHEL

Het klassieke tekstbestand bestaat niet meer overal. Ubuntu 22.04 en 24.04 houden in de serverinstallatie nog steeds /var/log/auth.log bij, omdat rsyslog daar wordt meegeleverd. Debian 12 en Debian 13 installeren rsyslog in een minimale installatie niet meer mee, daar bestaat het bestand eenvoudigweg niet en komt alles in het journal terecht. In de Red-Hat-familie heet het bestand /var/log/secure. Wilt u het tekstbestand op Debian terug, installeer rsyslog dan alsnog, op Debian en Ubuntu met apt-get install -y rsyslog, in de Red-Hat-familie met dnf install -y rsyslog.

Het tweede servercommando is nog belangrijker, want het toont de configuratie die werkelijk van kracht is en lost daarbij alle ingesloten bestanden op:

sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|strictmodes|permitrootlogin'

Antwoordt het commando in plaats van een configuratie alleen met Missing privilege separation directory: /run/sshd en komt er geen enkele regel uit, dan ontbreekt simpelweg een runtimemap. Dat gebeurt op Debian 11, Debian 12, Ubuntu 22.04 en Ubuntu 24.04 direct na de pakketinstallatie zolang de service nog nooit gestart is, en in containers. In normaal bedrijf maakt de systemd-unit die map zelf aan via RuntimeDirectory=sshd. Verschijnt de melding, voer dan eerst mkdir -p /run/sshd uit, daarna levert sshd -T netjes permitrootlogin, pubkeyauthentication yes, strictmodes yes en authorizedkeysfile. Debian 13 met OpenSSH 10 en de hele Red-Hat-familie kennen die beperking niet meer. Let erop dat de melding in een pipe verdwijnt: sshd -T | grep ... laat dan alleen lege uitvoer zien, en de eigenlijke retourwaarde 255 gaat verloren in de grep.

En wilt u echt zien wat de server denkt zonder aan de draaiende service te komen, start dan een tweede exemplaar in debugmodus op een vrije poort. Dat exemplaar sluit zichzelf na één verbinding af en kan u niet buitensluiten.

/usr/sbin/sshd -ddd -p 2222

Voer daarna vanaf uw eigen computer ssh -p 2222 deploy@203.0.113.7 uit, en in de terminal van de server staat de weigering in gewone taal. De poort moet daarvoor uiteraard open staan in de firewall.

Oorzaak 1: rechten en eigenaar, veruit het vaakst voorkomende geval

OpenSSH heeft de optie StrictModes yes standaard actief staan. De server weigert een sleutel te lezen uit een bestand waar behalve de gebruiker zelf nog iemand anders in kan schrijven. Dat is geen pesterij, het voorkomt dat een andere gebruiker zomaar zijn eigen sleutel in uw authorized_keys zet.

De gewenste toestand is strak omschreven:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 750 ~
chown -R "$(id -un):$(id -gn)" ~/.ssh

Controleren kan in één regel:

stat -c "%a %U %G %n" ~ ~/.ssh ~/.ssh/authorized_keys

Verwacht worden 750 of 700 voor de homedirectory, 700 voor .ssh en 600 voor authorized_keys, en in alle drie de regels uw eigen gebruikersnaam. Doorslaggevend is dit: de homedirectory mag niet beschrijfbaar zijn voor de groep en voor anderen, dus 770 of 777 is al genoeg om het te laten mislukken.

Eén getal mag u daarbij niet als fout uitleggen: op AlmaLinux, Rocky Linux en Oracle Linux heeft /root de rechten 550, niet 700 zoals op Debian en Ubuntu. stat -c geeft dat correct weer, en het is volkomen in orde. Voor StrictModes telt alleen dat de groep en anderen geen schrijfrecht hebben, en daaraan voldoet 550 precies. Wie hier nog snel een chmod 700 /root achteraan stuurt, heeft het inloggen daarmee niet gerepareerd, maar de oorzaak alleen verder toegedekt.

In het serverlog staat het dan heel duidelijk:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh
Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys
error: Could not open authorized keys '/home/deploy/.ssh/authorized_keys': Permission denied

Twee details die andere handleidingen vaak weglaten. Ten eerste de eigenaar: hebt u het bestand met sudo nano ~/.ssh/authorized_keys aangemaakt, dan is het eigendom van root en niet van de gebruiker, en mislukt het inloggen ondanks perfecte 600-rechten. Ten tweede controleert sshd het hele pad naar boven toe. Ligt de homedirectory niet onder /home, maar bijvoorbeeld onder /srv/klanten/deploy, dan moeten ook /srv en /srv/klanten eigendom zijn van root of van de gebruiker, en mogen ze niet beschrijfbaar zijn voor de groep en voor anderen.

Oorzaak 2: de verkeerde gebruikersnaam

Een gebruiker die niet bestaat, levert exact dezelfde melding op als een verkeerde sleutel, want de server geeft bewust niet prijs welk van de twee gevallen aan de hand is. In het log ziet u het verschil meteen:

Invalid user deply from 203.0.113.7 port 51234

De meest voorkomende aanleiding is dat de sleutel in /root/.ssh/authorized_keys staat terwijl u zich als gewone gebruiker aanmeldt, of andersom. Bij kant-en-klare cloud-images is het inloggen als root vaak geblokkeerd en bestaat er in plaats daarvan een voorbereide gebruiker, afhankelijk van de distributie debian, ubuntu, almalinux of rocky. Bij de standaardimages op een KernelHost-rootserver logt u daarentegen rechtstreeks in als root.

Controleer daarnaast of uw ~/.ssh/config stiekem een andere gebruiker invult. Het volgende commando maakt geen verbinding, maar laat alleen zien welke instellingen voor dit doel werkelijk gelden:

ssh -G deploy@203.0.113.7

In de uitvoer zijn user, hostname, port en de lijst met identityfile-regels van belang.

Oorzaak 3: de sleutel wordt helemaal niet aangeboden

Duikt er in ssh -vvv geen Offering public key met uw sleutel op, dan heeft de server nooit een kans gekregen. Daarvoor zijn er vier typische redenen.

De sleutel heeft een eigen naam

Automatisch probeert OpenSSH alleen de standaardnamen id_ed25519, id_ecdsa en id_rsa. Een sleutel met de naam id_productie wordt alleen gebruikt als u hem expliciet noemt:

ssh -i ~/.ssh/id_productie -o IdentitiesOnly=yes deploy@203.0.113.7

IdentitiesOnly=yes is hier geen franje. Zonder die optie biedt ssh daarnaast alle sleutels uit de agent aan, en bij te veel pogingen breekt de server af met Too many authentication failures, nog voordat de juiste sleutel aan de beurt is.

De agent heeft de sleutel niet

ssh-add -l

Antwoordt het commando met The agent has no identities. of Could not open a connection to your authentication agent., laad de sleutel dan alsnog met ssh-add ~/.ssh/id_ed25519.

Rechten op de privésleutel

De privésleutel moet 600 hebben, anders weigert de client dienst. Onder Windows heeft chmod geen effect, daar werkt u met ACL's:

icacls %USERPROFILE%\.ssh\id_ed25519 /inheritance:r /grant:r "%USERNAME%":R

Het bestand authorized_keys is stuk

Een publieke sleutel is precies één regel. Bij het kopiëren via editors, ticketsystemen of chatvensters sluipt er al snel een regelafbreking midden in het base64-blok, en dan klopt er niets meer van. Tel na:

grep -c '^ssh-' ~/.ssh/authorized_keys
awk '{print NR": "NF" velden, type "$1}' ~/.ssh/authorized_keys

Elke regel moet beginnen met ssh-ed25519, ssh-rsa of ecdsa-sha2- en uit twee tot drie velden bestaan. Het aantal regels moet overeenkomen met het aantal sleutels. Een tweede klassieker is dat per ongeluk de privésleutel in plaats van de publieke sleutel is ingevoerd, herkenbaar aan BEGIN OPENSSH PRIVATE KEY. En een sleutel in PuTTY-formaat (.ppk) werkt zo niet, die moet eerst naar OpenSSH worden geëxporteerd.

Of de privésleutel en de publieke sleutel bij elkaar horen, blijkt uit een vergelijking van de vingerafdrukken:

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh-keygen -lf ~/.ssh/authorized_keys

Dezelfde SHA256-waarde moet in beide gevallen te zien zijn. Hoe het geheel er netjes opgezet uitziet, leest u in ons artikel over SSH beveiligen en key-login instellen.

Oorzaak 4: PubkeyAuthentication staat uit

Komt minder vaak voor, maar is dan wel heel duidelijk. Controleer niet het configuratiebestand, maar het resultaat:

sshd -T | grep -i pubkeyauthentication

Hier ligt een valkuil die veel uren kost. Debian vanaf versie 12 en Ubuntu vanaf 22.04 hebben bovenaan in /etc/ssh/sshd_config de regel Include /etc/ssh/sshd_config.d/*.conf staan. Bij sshd geldt: voor elk sleutelwoord telt de waarde die als eerste wordt gevonden. Omdat die insluiting helemaal aan het begin staat, wint elk detail uit sshd_config.d het van het hoofdbestand, ongeacht wat daar verderop staat. Blijft uw wijziging zonder effect, kijk dan daar:

grep -rniE 'pubkeyauthentication|authorizedkeysfile|allowusers|allowgroups' /etc/ssh/

Het tweede punt in deze categorie is AuthorizedKeysFile. Standaard zijn dat .ssh/authorized_keys en .ssh/authorized_keys2. Sommige hardeningscripts zetten het pad op iets als /etc/ssh/authorized_keys/%u. Daarna wordt uw bestand in de homedirectory volledig genegeerd, zonder ook maar één foutmelding. Ook dat laat sshd -T zien.

Oorzaak 5: AllowUsers, AllowGroups en Match grijpen in

Deze directieven sluiten hele gebruikersgroepen buiten, en wel nog voordat de sleutel wordt gecontroleerd. De letterlijke tekst in het log:

User root from 203.0.113.7 not allowed because not listed in AllowUsers
User deploy from 203.0.113.7 not allowed because none of user's groups are listed in AllowGroups
User root from 203.0.113.7 not allowed because "PermitRootLogin no"

Onthoud de rangorde: DenyUsers gaat boven AllowUsers, en zodra AllowUsers eenmaal is ingesteld, zijn alle niet genoemde gebruikers buitengesloten. Bij AllowGroups moet het groepslidmaatschap kloppen, wat u met id deploy controleert.

Bij PermitRootLogin is het onderscheid belangrijk: prohibit-password staat het inloggen als root met een sleutel toe. Alleen no sluit root volledig uit. Verwacht in de uitvoer van sshd -T echter niet het woord prohibit-password, daar staat de oudere, gelijkbetekenende naam without-password. En de standaardwaarde is beslist niet overal hetzelfde, wat bij het vergelijken van twee servers geregeld voor verwarring zorgt:

Op AlmaLinux mag root er dus ook met een wachtwoord in, op de overige genoemde systemen niet. Wie een dienst van AlmaLinux naar Debian verhuist en tot dan toe als root met een wachtwoord inlogde, belandt daarna precies bij Permission denied (publickey).

Zit de regel in een Match-blok, dan helpt de optie die de configuratie voor één concreet geval doorrekent:

sshd -T -C user=deploy,host=client.example.com,addr=203.0.113.7 | grep -Ei 'pubkeyauth|allowusers|permitrootlogin'

Dat is de betrouwbaarste manier om te zien wat er voor precies deze gebruiker vanaf precies dit IP-adres geldt.

Oorzaak 6: SELinux op AlmaLinux, Rocky en RHEL

In de Red-Hat-familie draait SELinux standaard in de modus Enforcing, op Debian en Ubuntu speelt het geen rol. Het sshd-proces mag authorized_keys alleen lezen als het bestand de context ssh_home_t draagt. Dat is het geval wanneer het gewoon in de homedirectory is aangemaakt. Het is niet het geval wanneer u het met mv uit /tmp hebt gehaald of de homedirectory met de hand hebt aangemaakt, want mv neemt de oude context mee.

getenforce
ls -Z ~/.ssh

Goed is een vermelding die op ssh_home_t eindigt. Staat er user_tmp_t of user_home_t, dan is de oorzaak gevonden. De reparatie:

restorecon -R -v ~/.ssh

Deze stap geldt uitsluitend voor de Red-Hat-familie. Op Debian en Ubuntu bestaat er geen standaardopzet met SELinux, daar antwoordt de shell met restorecon: command not found, en dat is geen fout, maar simpelweg niet van toepassing. Maar ook op AlmaLinux en Rocky Linux ontbreekt het commando in een slanke installatie, omdat het bijbehorende pakket niet is meegeïnstalleerd. Installeer het dan eerst alsnog:

dnf install -y policycoreutils

Bewijs vindt u in het auditlog, daar staat de weigering in gewone taal:

ausearch -m avc -ts recent

Ligt de homedirectory op een ongebruikelijke plek, dan is restorecon alleen niet genoeg, want SELinux kent het pad helemaal niet als homedirectory. Registreer die gelijkstelling dan eenmalig en herstel daarna opnieuw:

semanage fcontext -a -e /home /srv/klanten
restorecon -R -v /srv/klanten

semanage zit in het pakket policycoreutils-python-utils. Schakel SELinux niet uit om het inloggen aan de praat te krijgen, want dat lost een probleem van twee commando's op ten koste van een systeembreed verlies aan beveiliging.

Oorzaak 7: oude server, verkeerd sleuteltype

Sinds OpenSSH 8.8 wijst de client RSA-handtekeningen met SHA-1 af. Dat raakt Ubuntu 22.04 al, en Debian 13 levert inmiddels OpenSSH 10. Wilt u vanaf zo'n actueel systeem naar een heel oude server die alleen het oude ssh-rsa beheerst, dan ziet u in de debuguitvoer:

debug1: send_pubkey_test: no mutual signature algorithm

Dat is geen rechtenprobleem, uw sleutel is volkomen in orde. Voor eenmalige toegang helpt dit:

ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa deploy@203.0.113.7

Permanent hoort dat in ~/.ssh/config onder een Host-regel te staan, zodat het alleen deze ene server betreft. Op heel oude clients heet de optie nog PubkeyAcceptedKeyTypes. De echte oplossing is de oude server bijwerken, want vanaf OpenSSH 7.2 beheerst ook die de SHA-2-varianten, en uw bestaande RSA-sleutel blijft dan ongewijzigd werken. Alleen de handtekeningmethode verandert.

Het omgekeerde geval bestaat ook. Een ed25519-sleutel vereist minstens OpenSSH 6.5 aan beide kanten, hardwaretokens van het type ed25519-sk minstens 8.2. En DSA is verleden tijd: sinds OpenSSH 10.0 is ssh-dss volledig verwijderd, zulke oude sleutels werken tegenover Debian 13 helemaal niet meer. Welke typen uw client kent, laat dit zien:

ssh -Q key

Ontbreekt ssh op een pas opgezette AlmaLinux, Rocky Linux of RHEL volledig, dan komt dat door een valkuil in de pakketnamen: dnf install openssh-server brengt alleen de service mee, geen clienttools. Zonder die tools ontbreken ssh, ssh-add en daarmee ook ssh -Q en ssh -G. Bijinstalleren gaat met een meervouds-s aan het eind, anders dan bij het Debian-pakket openssh-client:

dnf install -y openssh-clients

Op AlmaLinux, Rocky en RHEL 9 komt er een tweede laag bij. Daar bepalen systeembrede cryptorichtlijnen mede wat is toegestaan, los van de sshd-configuratie:

update-crypto-policies --show

Ook dit gereedschap is puur Red-Hat, op Debian en Ubuntu bestaat het niet. En zelfs op Oracle Linux 9 ontbreekt het in de minimale installatie, daar levert dnf install -y crypto-policies-scripts het alsnog, waarna er zoals verwacht DEFAULT uitkomt. Staat daar DEFAULT, dan zijn SHA-1-handtekeningen al systeembreed geblokkeerd. update-crypto-policies --set LEGACY heft dat op, maar verzwakt de hele machine en hoort hooguit een tussenoplossing voor een migratie te zijn.

Als u zichzelf hebt buitengesloten

Het gevaarlijke moment is niet de fout zelf, maar de reparatie aan sshd_config. Drie regels die buitensluiting praktisch onmogelijk maken:

1. Laat een tweede sessie openstaan. Een herstart van sshd verbreekt bestaande verbindingen niet. Zolang er één terminal open blijft, kunt u elke wijziging terugdraaien.
2. Controleer voor elke herstart de syntaxis. sshd -t geeft bij fouten het regelnummer en zwijgt als alles klopt. Een typefout in de configuratie verhindert anders de start van de service, en dan komt er niemand meer binnen. Komt er in plaats daarvan Missing privilege separation directory: /run/sshd, dan is uw configuratie in orde en ontbreekt alleen de runtimemap, zie hierboven.
3. Test vanuit de tweede sessie, voordat u de eerste sluit.

Bij het herstarten verschillen de systemen. Op Debian en Ubuntu heet de unit ssh, in de Red-Hat-familie sshd. Sinds Ubuntu 22.10 en in Debian 13 wordt SSH daarnaast via socketactivering gestart: de configuratie uit sshd_config blijft gelden, maar een gewijzigde Port-opgave werkt pas nadat ook ssh.socket opnieuw is gestart.

sshd -t
systemctl restart ssh          # Debian, Ubuntu
systemctl restart ssh.socket   # ook nodig als de poort is gewijzigd
systemctl restart sshd         # AlmaLinux, Rocky, RHEL

Is het toch gebeurd, dan hebt u een weg nodig die om SSH heen gaat. Bij een KernelHost-rootserver opent u in het klantenpaneel de VNC-console en logt u daar in met het rootwachtwoord, volledig zonder netwerkdienst. Leidt dat niet tot het doel, bijvoorbeeld omdat sshd helemaal niet meer start, dan biedt het rescuesysteem uitkomst: u start op in een noodomgeving, koppelt het bestandssysteem van de server aan en corrigeert authorized_keys en de rechten rechtstreeks op de schijf. Denk eraan om na het aankoppelen de eigendomsverhoudingen te controleren, want in het rescuesysteem bent u root en maakt u bestanden anders met de verkeerde eigenaar aan.

Waaraan u ziet dat het echt werkt

Dat het inloggen lukt, wil nog niet zeggen dat het via de sleutel ging. Zolang inloggen met een wachtwoord actief is, kan de server u daar stilletjes op laten terugvallen. De eerlijke test sluit elke andere methode uit:

ssh -o BatchMode=yes -o PreferredAuthentications=publickey deploy@203.0.113.7 'id -un; hostname'

BatchMode=yes onderdrukt elke interactieve vraag. Komen uw gebruikersnaam en de hostnaam terug en levert echo $? daarna een 0 op, dan heeft uitsluitend de sleutel het werk gedaan.

Het tweede bewijs staat in het serverlog en noemt zelfs de vingerafdruk van de gebruikte sleutel:

Accepted publickey for deploy from 203.0.113.7 port 51234 ssh2: ED25519 SHA256:8Qk...

Vergelijk deze SHA256-waarde met de uitvoer van ssh-keygen -lf ~/.ssh/id_ed25519.pub. Komen beide overeen, dan weet u niet alleen dat het inloggen werkt, maar ook welke sleutel het was. Dat is van belang wanneer er meerdere sleutels in het spel zijn en u er daarvan één wilt intrekken.

De volgorde om af te werken

Hebt u geen tijd voor theorie, loop deze lijst dan van boven naar beneden af. De lijst is gesorteerd op hoe vaak iets voorkomt, niet op elegantie.

1. ssh -vvv starten en vaststellen of Offering public key verschijnt. Dat splitst het probleem in client en server.
2. Rechten controleren: 700 op ~/.ssh, 600 op authorized_keys, homedirectory niet beschrijfbaar voor de groep, alles in eigendom van de gebruiker.
3. Gebruikersnaam controleren, bij twijfel ssh -G raadplegen en in het log zoeken naar Invalid user.
4. Vingerafdrukken van de privésleutel en authorized_keys vergelijken, het aantal regels in het bestand controleren.
5. sshd -T uitlezen: pubkeyauthentication, authorizedkeysfile, strictmodes, permitrootlogin.
6. Controleren op AllowUsers, AllowGroups, DenyUsers en Match-blokken, inclusief de map sshd_config.d.
7. In de Red-Hat-familie ls -Z ~/.ssh en zo nodig restorecon -R -v ~/.ssh.
8. Alleen bij heel oude servers aan de andere kant: het handtekeningalgoritme uitbreiden met PubkeyAcceptedAlgorithms=+ssh-rsa.

Uiterlijk op dit punt is de oorzaak gevonden. Wilt u de toegang daarna netjes opnieuw opzetten, dan zijn de introductie tot de SSH-verbinding en de checklist voor een nieuwe rootserver de passende vervolgstappen.