‘Permission denied (publickey)’ bij ssh of git push naar GitHub of GitLab? Zo test je je sleutel, maak je een nieuwe ed25519-sleutel en zet je de rechten goed.
Bij inloggen met SSH bewijst je computer wie je bent met een sleutelpaar: een privésleutel die alleen op jouw computer staat, en een publieke sleutel die je bij de server (of bij GitHub of GitLab) hebt neergezet. Permission denied (publickey) betekent dat de server geen enkele aangeboden sleutel accepteerde, en dat sleutels de enige toegestane manier van inloggen zijn. Tussen de haakjes staat welke methoden de server toestaat; staat er alleen publickey, dan is inloggen met een wachtwoord uitgeschakeld.
De meest voorkomende oorzaken: er is nog geen sleutel aangemaakt, de publieke sleutel is niet (of bij het verkeerde account) toegevoegd, SSH biedt een andere sleutel aan dan je denkt, de sleutel is niet geladen in de ssh-agent, of je logt in met de verkeerde gebruikersnaam. Bij GitHub en GitLab is de gebruiker altijd git, niet je eigen naam.
Op een eigen server komt daar nog iets bij: SSH is streng op bestandsrechten. Zijn de map ~/.ssh of het bestand authorized_keys schrijfbaar voor anderen, of is je privésleutel leesbaar voor anderen, dan negeert SSH de sleutel. Op je eigen computer zie je dan ‘bad permissions’; op de server staat de reden alleen in het log.
https://github.com/…) een inlogfout, dan speelt SSH geen rol; dan gaat het om een token of wachtwoord.Menunamen kunnen per versie of toestel iets anders heten. Loop de stappen op volgorde af en stop zodra het werkt.
Test eerst of je sleutel werkt, zonder Git ertussen. Bij GitHub krijg je bij succes ‘Hi gebruikersnaam! You've successfully authenticated, but GitHub does not provide shell access.’ Dat is goed nieuws: de sleutel werkt. Bij GitLab krijg je een welkomstregel met je gebruikersnaam. Gebruik altijd de gebruiker git.
ssh -T git@github.com
ssh -T git@gitlab.comMet -v laat SSH zien wat het probeert. Zoek naar regels als ‘Offering public key’ en ‘Trying private key’. Zie je je sleutel daar niet, dan staat hij op een andere plek of met een andere naam dan SSH verwacht. Staat er ‘Server accepts key’, dan ligt het niet aan de sleutel maar aan rechten op de repository.
ssh -vT git@github.comKijk welk adres je repository gebruikt. Een SSH-adres ziet eruit als git@github.com:organisatie/repo.git. Staat de gebruikersnaam of organisatie verkeerd, dan kan GitHub ook ‘Permission denied’ geven of zeggen dat de repository niet bestaat.
git remote -v
git remote set-url origin git@github.com:organisatie/repo.gitKijk in ~/.ssh of er een bestand id_ed25519.pub of id_rsa.pub staat. Zo niet, maak dan een nieuwe sleutel van het type ed25519. Het commentaar achter -C is alleen een label, bijvoorbeeld je e-mailadres. Kies een wachtwoordzin; die beschermt de sleutel als je laptop kwijtraakt.
ls -al ~/.ssh
ssh-keygen -t ed25519 -C "jij@voorbeeld.nl"Laad de sleutel in de ssh-agent, zodat SSH hem aanbiedt. Kopieer daarna de inhoud van het .pub-bestand, dus de publieke sleutel, naar je account: bij GitHub via Settings › SSH and GPG keys, bij GitLab via je profielinstellingen bij SSH Keys. Deel nooit het bestand zonder .pub.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l
cat ~/.ssh/id_ed25519.pubHeb je meerdere sleutels, bijvoorbeeld voor werk en privé, dan kan SSH de verkeerde aanbieden. GitHub accepteert die dan als een ander account, met ‘Permission denied’ of ‘Repository not found’ als gevolg. Leg in ~/.ssh/config vast welke sleutel bij welke host hoort.
Host github.com
User git
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yesOp de server moet de publieke sleutel in ~/.ssh/authorized_keys staan van de gebruiker waarmee je inlogt, op één regel. SSH negeert hem als de rechten te ruim zijn. De map hoort 700 te hebben, authorized_keys 600, en beide moeten van die gebruiker zijn. Op je eigen computer geldt hetzelfde voor je privésleutel (600). Meer over rechten bij Permission denied in Linux.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chown -R gebruiker:gebruiker /home/gebruiker/.sshWeet je nog niet waarom de server weigert, kijk dan in het authenticatielog terwijl je opnieuw probeert in te loggen. Daar staat bijvoorbeeld ‘Authentication refused: bad ownership or modes’ of welke gebruiker werd geprobeerd. Houd een tweede, werkende sessie open als je aan de SSH-instellingen van de server werkt.
sudo journalctl -u ssh -f
# of op sommige systemen:
sudo tail -f /var/log/auth.logLet op: Deel nooit je privésleutel (het bestand zonder .pub) en zet hem niet in een repository. Is hij toch ergens terechtgekomen, verwijder de bijbehorende publieke sleutel overal en maak een nieuwe.
Kom je er met deze stappen niet uit, of wil je het liever niet zelf doen? We kijken online mee of komen langs. Hulp op afstand kost €20 per uur; komen we langs, dan is de prijs op aanvraag. Je weet vooraf waar je aan toe bent.
Schrijf kort wat er misgaat en wat je al hebt geprobeerd. Kies of we bellen, online meekijken of langskomen.
De server accepteerde geen van de sleutels die je computer aanbood, en inloggen met wachtwoord staat uit. Meestal is de sleutel niet toegevoegd, wordt de verkeerde aangeboden of is de gebruikersnaam fout.
Altijd git, dus ssh -T git@github.com. GitHub herkent je account aan de sleutel, niet aan de gebruikersnaam.
Voor nieuwe sleutels is ed25519 de gebruikelijke keuze: kort, snel en breed ondersteund. RSA gebruik je alleen als een oud systeem ed25519 niet kent.
Je privésleutel is leesbaar voor anderen, en dan weigert SSH hem. Zet de rechten op 600 met chmod 600 ~/.ssh/id_ed25519.
Hulp nodig van een mens? Website-onderhoud · Hosting en onderhoud · WordPress-support · Alle oplossingen