Le format
# Deploy key, added for the release job
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINH9eelf0P7eT5ue6SualUXFrh1c9p3Maaem93iZtC2Q you@laptop
from="203.0.113.10",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINxDNsPpUAbI52nc1OduztL+ backup-jobUne ligne se lit de gauche à droite :
- Options, facultatives. Séparées par des virgules, sans espaces sauf entre guillemets doubles.
- Type de clé, comme
ssh-ed25519oussh-rsa. - La clé, une longue chaîne en base64.
- Un commentaire, facultatif. Il n'est là que pour vous.
Les lignes vides et celles qui commencent par # sont ignorées. Une ligne incompréhensible est sautée, et les lignes suivantes fonctionnent quand même.
Ces erreurs vous font perdre la clé sans prévenir, et vous ne voyez que Permission denied :
- Une clé coupée sur deux lignes, le plus souvent en collant dans un éditeur qui replie le texte. Chaque clé doit tenir sur une seule ligne.
- Une clé sans son type au début.
- Une espace après une virgule dans les options, comme dans
from="203.0.113.10", restrict.
Besoin d'une clé à y mettre ? Voir comment générer une clé SSH Ed25519.
Options utiles
| Option | Effet |
|---|---|
restrict | Désactive les redirections de port, d'agent et X11, les terminaux et ~/.ssh/rc. |
command="..." | Exécute cette commande quoi que le client ait demandé. |
from="..." | La connexion doit venir de l'une de ces adresses ou de l'un de ces noms. Le CIDR et les motifs fonctionnent. |
permitopen="host:port" | Limite ssh -L à cette destination. |
expiry-time="20991231" | La clé cesse de fonctionner après cette date. |
cert-authority | La ligne est une autorité de certification, pas une clé d'utilisateur. Voir les certificats SSH. |
verify-required | Pour les clés FIDO : chaque signature doit inclure un code PIN ou une vérification équivalente. |
Pour des exemples concrets, voir comment limiter une clé à une seule commande.
Permissions
Les bons réglages, à lancer en tant qu'utilisateur sur le serveur :
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysSi vous les avez créés en tant que root, corrigez aussi le propriétaire :
sudo chown -R user:user /home/user/.sshVoici ce qui s'est passé dans nos tests, et ce que disait le journal du serveur :
| Réglage | Résultat |
|---|---|
authorized_keys en mode 600 ou 644 | Fonctionne |
authorized_keys en mode 666 | Refusé : Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys |
~/.ssh en mode 700 ou 755 | Fonctionne |
~/.ssh en mode 777 | Refusé : Authentication refused: bad ownership or modes for directory /home/user/.ssh |
| Fichier appartenant à root, mode 644 | Fonctionne, car l'utilisateur peut le lire |
| Fichier appartenant à root, mode 600 | Refusé : Could not open user 'user' authorized keys '/home/user/.ssh/authorized_keys': Permission denied |
Cette vérification s'appelle StrictModes et elle est activée par défaut. Laissez-la ainsi. Un répertoire personnel en mode 775 est passé sur notre système Debian, où le groupe ne contient que cet utilisateur, mais c'est une modification propre à Debian : d'autres systèmes peuvent le refuser. Le client ne voit que Permission denied, alors lisez toujours le journal du serveur. Voir comment déboguer une connexion SSH.
Quelle ligne l'emporte
Quand une clé apparaît plusieurs fois, sshd lit de haut en bas et utilise la première ligne qui laisse passer la connexion. Seules les options de cette ligne s'appliquent. Cela donne deux résultats à connaître :
- Une ligne simple placée au-dessus d'une ligne restreinte l'annule. Si la clé figure d'abord sans options puis avec
command="...", la connexion obtient une session normale, sans restriction. - Une ligne dont la condition échoue n'arrête pas la recherche. Si la première ligne a un
from=qui ne correspond pas, ou unexpiry-timedépassé, la ligne suivante contenant la même clé peut quand même laisser passer la connexion. Pour couper une clé, supprimez toutes ses lignes.
Changer l'emplacement du fichier
Le réglage serveur AuthorizedKeysFile indique où chercher. Voyez la valeur actuelle avec :
sudo sshd -T | grep -i authorizedkeysfileLa valeur par défaut est .ssh/authorized_keys .ssh/authorized_keys2 : une clé oubliée dans un authorized_keys2 fonctionne donc aussi. Vérifiez-en l'existence quand vous retirez un accès.
Un changement fréquent consiste à garder les fichiers hors des répertoires personnels, là où seul root peut les modifier :
# /etc/ssh/sshd_config.d/10-keys.conf
AuthorizedKeysFile /etc/ssh/authorized_keys/%u%u est le nom d'utilisateur et %h le répertoire personnel. Les chemins relatifs partent du répertoire personnel. Chaque utilisateur doit pouvoir lire son propre fichier, par exemple en mode 644 avec root comme propriétaire. Créez ces fichiers avant de recharger sshd, et gardez une session ouverte pendant vos essais.
Pour récupérer les clés ailleurs, par exemple depuis un annuaire, utilisez AuthorizedKeysCommand. Voir sshd_config(5).
Voir ce que contient le fichier
ssh-keygen -lf ~/.ssh/authorized_keysCela affiche une empreinte pour chaque clé. Sur une ligne avec options, le texte des options apparaît là où l'on attendrait le commentaire, par exemple 256 SHA256:NxFS... restrict,command="/usr/local/bin/ssh-allow" (ED25519). L'empreinte reste correcte.
Questions
Où se trouve le fichier authorized_keys ?
Par défaut dans ~/.ssh/authorized_keys, dans le répertoire personnel du compte utilisé. Le réglage serveur AuthorizedKeysFile peut indiquer un autre chemin ; vérifiez-le avec sudo sshd -T | grep -i authorizedkeysfile.
Faut-il redémarrer sshd après avoir modifié authorized_keys ?
Non. sshd lit le fichier à chaque connexion, la modification vaut donc dès la suivante.
Pourquoi SSH demande-t-il encore un mot de passe après l'ajout de ma clé ?
En général, les permissions sont trop ouvertes, la clé est coupée sur deux lignes ou elle est dans le mauvais compte. Le journal du serveur donne la raison ; le client n'affiche que la demande de mot de passe ou Permission denied.