Ajouter une clé SSH et désactiver les mots de passe

Génération de la clé sur la machine où vous êtes assis

Pas sur le serveur. La moitié privée ne doit jamais exister sur un hôte auquel vous pourriez perdre l'accès, et la copier partout annule son intérêt.

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

-a 100 définit le nombre de tours KDF protégeant la phrase secrète, qui est la seule chose entre un ordinateur portable volé et votre flotte. Utilisez une phrase secrète. Si vous possédez un jeton matériel, utilisez-le à la place :

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

Installation de la moitié publique

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

À la main, depuis une session root, si le compte n'a pas encore de mot de passe :

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

Collez la ligne unique, puis Ctrl-D. Les permissions comptent plus qu'on ne le pense : sshd refuse un répertoire personnel ou un répertoire .ssh accessible en écriture au groupe, et ne s'explique que dans le journal du démon, jamais auprès du client.

Restriction de la clé pendant que vous y êtes

Les options dans authorized_keys s'appliquent par clé. restrict désactive tout, puis vous rajoutez ce dont la clé a réellement besoin :

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

Une clé qui existe pour exécuter une tâche doit être autorisée à n'exécuter qu'une tâche :

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

Tester avant de verrouiller

Laissez la première session connectée. Depuis un second terminal :

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

Si cela affiche votre UID, le chemin de la clé fonctionne. Si ce n'est pas le cas, ssh -vvv côté client et journalctl -u ssh -n 50 côté serveur vous diront entre les deux quel côté est mécontent. Ce sont des permissions environ la moitié du temps et le mauvais nom d'utilisateur la plupart du reste.

Désactivation des mots de passe

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 est la ceinture sous les bretelles. Même si un ajout ultérieur réactive silencieusement les mots de passe, le démon refuse toujours tout ce qui n'est pas une clé.

Confirmez depuis le client que la porte est fermée :

ssh -o PreferredAuthentications=password deploy@<ipv4>

Le résultat attendu est Permission denied (publickey).

Clés lors du déploiement

Le panneau conserve une liste de clés par compte. Cochez celles que vous voulez et cloud-init les écrit lors du premier démarrage, ce qui signifie qu'une instance peut exister pour la première fois avec l'authentification par mot de passe déjà désactivée. Attacher la clé à la commande transforme les dix minutes ci-dessus en une seule.

En cas de perte de la clé

Il n'y a pas de récupération basée sur l'identité ici, car nous ne détenons aucune identité. La console hors bande est le chemin de retour : elle atteint l'instance via un chemin qui ne touche jamais sshd, et depuis un shell de secours vous pouvez ajouter une nouvelle clé et continuer.

Gardez une seconde clé sur une seconde machine et vous n'aurez jamais besoin de lire cet article.