Een SSH-sleutel toevoegen en wachtwoorden uitschakelen

Genereer de sleutel op de machine waar je voor zit

Niet op de server. Het privégedeelte mag nooit bestaan op een host waar je de toegang toe zou kunnen verliezen, en het rondkopiëren ervan verslaat het doel van het hebben van een sleutel.

ssh-keygen -t ed25519 -a 100 -C "laptop-2026"

-a 100 bepaalt het aantal KDF-rondes dat de wachtwoordzin beschermt, wat het enige is dat tussen een gestolen laptop en je vloot staat. Gebruik een wachtwoordzin. Als je een hardwaretoken bezit, gebruik dat dan in plaats daarvan:

ssh-keygen -t ed25519-sk -O resident -C "token-1"

Installeer het openbare gedeelte

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@<ipv4>

Met de hand, vanuit een rootsessie, als het account nog geen wachtwoord heeft:

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
install -m 600 -o deploy -g deploy /dev/null /home/deploy/.ssh/authorized_keys
cat >> /home/deploy/.ssh/authorized_keys

Plak de enkele regel en druk dan op Ctrl-D. Machtigingen zijn belangrijker dan mensen verwachten: sshd weigert een groepsschrijfbare home of .ssh-map en legt zichzelf alleen uit in het daemonlogboek, nooit aan de client.

Beperk de sleutel terwijl je er toch bent

Opties in authorized_keys gelden per sleutel. restrict schakelt alles uit, en dan voeg je terug toe wat de sleutel echt nodig heeft:

restrict,pty ssh-ed25519 AAAAC3Nza... deploy@laptop

Een sleutel die bestaat om één taak uit te voeren, moet slechts één taak mogen uitvoeren:

restrict,command="/usr/local/bin/backup-receive" ssh-ed25519 AAAAC3Nza... backup

Test voordat je op slot gaat

Laat de eerste sessie verbonden. Vanuit een tweede terminal:

ssh -o PreferredAuthentications=publickey deploy@<ipv4> id

Als dat je uid afdrukt, werkt het sleutelpad. Als dat niet zo is, zullen ssh -vvv aan de clientzijde en journalctl -u ssh -n 50 aan de serverzijde samen zeggen welke kant ongelukkig is. Het is in ongeveer de helft van de gevallen machtigingen en in de rest meestal de verkeerde gebruikersnaam.

Schakel wachtwoorden uit

cat > /etc/ssh/sshd_config.d/20-keys-only.conf <<EOF
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
AuthenticationMethods publickey
EOF
sshd -t && systemctl reload ssh

AuthenticationMethods publickey is de riem onder de bretels. Zelfs als een later drop-in-bestand wachtwoorden stil opnieuw inschakelt, weigert de daemon nog steeds alles dat geen sleutel is.

Bevestig vanaf de client dat de deur gesloten is:

ssh -o PreferredAuthentications=password deploy@<ipv4>

Het verwachte resultaat is Permission denied (publickey).

Sleutels bij implementatie

Het paneel houdt per account een sleutellijst bij. Vink de gewenste aan en cloud-init schrijft ze tijdens de eerste start, wat betekent dat een instantie voor het eerst kan bestaan met wachtwoordauthenticatie al uitgeschakeld. Het koppelen van de sleutel aan de bestelling verandert de tien minuten hierboven in één.

Wanneer je de sleutel kwijtraakt

Er is hier geen op identiteit gebaseerd herstel, omdat we geen identiteit bewaren. Het out-of-band console is de weg terug: het bereikt de instantie via een pad dat nooit sshd raakt, en vanuit een reddingsshell kun je een nieuwe sleutel toevoegen en doorgaan.

Houd een tweede sleutel op een tweede machine en je hoeft dat artikel nooit te lezen.