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 fase van de authenticatie. De oplossing is geen kwestie van gokken, omdat ssh -v u vertelt welke van de vijf oorzaken van toepassing is.

De termen tussen haakjes zijn de methoden die de server bereid was te accepteren. Permission denied (publickey) op zichzelf betekent dat inloggen met een wachtwoord 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 niet bent geslaagd.

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.

Voer eerst ssh -v uit en lees drie regels

Herhaal het commando dat mislukte, met -v toegevoegd:

ssh -v deploy@203.0.113.10

Een ingekorte maar realistische uitvoer ziet er als volgt uit:

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

Drie regels bevatten alles wat u nodig heeft.

Authenticating to 203.0.113.10:22 as 'deploy' is de gebruikersnaam die daadwerkelijk zal worden gebruikt. Niet degene die u bedoelde: degene die ssh heeft afgeleid van de opdrachtregel, van ~/.ssh/config, of van uw lokale inlognaam.

Authentications that can continue: publickey is de lijst met geaccepteerde methoden van de server, verzonden voordat er een sleutel wordt geprobeerd. Als publickey ontbreekt in die eerste lijst, heeft de server inloggen met een publieke sleutel uitgeschakeld, waardoor geen enkele sleutel kan werken.

Offering public key: ... is één regel per sleutel die uw client daadwerkelijk heeft verzonden, met de naam van het bestand waar deze vandaan kwam en de SHA256-vingerafdruk. Een sleutel zonder Offering-regel is nooit naar de server verzonden.

Splits het probleem nu in tweeën:

• Er is geen Offering public key-regel voor de sleutel die u verwacht. De fout ligt bij uw machine, omdat de server uw sleutel helemaal niet heeft gezien.
• De sleutel wordt aangeboden en Authentications that can continue: publickey komt weer terug. De server heeft die sleutel ontvangen en geweigerd, dus de fout ligt bij de server.

De onderstaande oorzaken zijn gerangschikt op basis van hoe vaak ze de oplossing blijken te zijn.

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 vóór alles. Als hier de inlognaam van uw laptop staat in plaats van het serveraccount, dan bent u de gebruikersnaam vergeten in het commando.

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 cloud-images doorgaans 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. Die stap is onderdeel van de eerste tien minuten op een nieuwe VPS, en het is gemakkelijk 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 zich in ssh-agent bevinden, 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. Daarom toont de uitgebreide uitvoer geen Offering public key-regel voor dit bestand.

Geef het bestand op en voorkom dat de sleutels van de agent 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

IdentitiesOnly=yes beperkt de poging tot het bestand dat u heeft opgegeven. Bekijk welke sleutels de agent bevat met ssh-add -l en wis deze met ssh-add -D als er zich in de loop der jaren oude sleutels hebben opgehoopt. Leg de instellingen vervolgens vast zodat de volgende login niet afhankelijk is van het onthouden van vlaggen:

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. De sleutel wordt daardoor nooit aangeboden en de server ziet deze nooit:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         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 is nooit in authorized_keys terechtgekomen

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.

Er zijn vier veelvoorkomende manieren waarop dit misgaat:

• 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-----.
• De tekst is bij het plakken over meerdere regels verdeeld. Elke invoer moet exact op één regel staan; een afgebroken key wordt gelezen als meerdere ongeldige regels en komt nergens mee 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 toegevoegd aan de standaardgebruiker van de image, waardoor het account dat u later heeft aangemaakt een lege .ssh-directory heeft.

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

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 eenvoudige 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.
• Eigenaarschap: alle drie moeten eigendom zijn van het account waarmee u inlogt, niet van root.

Eigenaarschap 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 eigenaarschap 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 permissiereeks zoals drwxr-xr-x leest voordat u de modi op een actieve 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 bestandslabel dragen, waardoor sshd leesrechten worden 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 niets verandert.

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 op moet letten in uw eigen output:

• pubkeyauthentication no. Geen enkele sleutel zal ooit worden 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 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 bruikbare 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 heeft invloed op oudere sleutels. OpenSSH 8.8 is standaard gestopt met het 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 zodat u vandaag toegang krijgt; beschouw dit echter als een manier om de server te bereiken, niet als het einde van het werk. 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, dus het toont u 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; dit bewijst tevens 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 waar 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 logboekvolger 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 daarna 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 vanaf 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 zodra 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 serverconfiguraties wijzigt, vereist een noodtoegang 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 seriële verbinding of VNC (virtual network computing) en bevestig dat u daar kunt inloggen.
2. Zorg dat u een werkend lokaal wachtwoord heeft 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 na systemctl restart ssh, waardoor dit een uitweg biedt als de nieuwe configuratie onjuist is.
4. Controleer de syntaxis voordat u opnieuw opstart: 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 aantonen of de wijziging succesvol was.

Start opnieuw 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 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 wordt vermeld, heeft ssh deze nooit verzonden: het bestand staat niet in ~/.ssh onder een standaardnaam 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 alsnog, dan ontbreekt die 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 verstuurt?

ssh -v host toont één debug1: Offering public key:-regel per sleutel, met vermelding van het bronbestand en een SHA256-vingerafdruk. ssh-add -l somt de vingerafdrukken op 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 uit een privésleutel wordt afgeleid. Om de aanmelding te laten slagen, moet de vingerafdruk van de Offering-regel ook verschijnen 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 iemand anders kan worden gewijzigd; het gedraagt zich daarom alsof er geen sleutel bestaat. Stel de rechten van de thuismap in 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, is dit hoogstwaarschijnlijk 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, herstelt PubkeyAcceptedAlgorithms +ssh-rsa op de server de oude handtekeningen; verwijder die 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, omdat 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.