authorized_keys est le fichier OpenSSH qui répertorie les clés publiques autorisées à se connecter à un compte. Pour que sshd l'accepte, ~/.ssh doit être en 700 et authorized_keys en 600, sans droit d'écriture pour le groupe ni pour les autres. Chaque ligne peut porter des options comme from=, command= et no-pty, qui limitent l'origine des connexions d'une clé et ce qu'elle peut exécuter.
Permissions d'authorized_keys : 700 sur ~/.ssh et 600 sur le fichier
sshd ignore authorized_keys lorsque ~/.ssh ou le fichier lui-même est plus ouvert que prévu : 700 pour ~/.ssh et 600 pour authorized_keys et les clés privées. Ce contrôle vient de la directive StrictModes de sshd_config, activée par défaut, qui vérifie aussi que votre répertoire personnel n'est pas modifiable par le groupe ou les autres.
chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$(id -un)":"$(id -gn)" ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keysQuand quelque chose cloche, le journal du serveur le dit clairement : cherchez des lignes comme Authentication refused: bad ownership or modes. Sur Debian et Ubuntu, vous les lisez avec journalctl -u ssh ; sur les autres distributions, l'unité s'appelle sshd. Désactiver StrictModes pour se débloquer est un mauvais calcul : cela masque le problème et permet à un autre utilisateur ayant un accès en écriture à votre répertoire personnel d'y glisser sa propre clé.
Options d'authorized_keys : from=, command= et no-pty par l'exemple
Chaque ligne d'authorized_keys suit le format [options] keytype key comment, avec des options séparées par des virgules, sans espaces, placées avant le type de clé. La liste complète figure dans la section AUTHORIZED_KEYS de la page de manuel officielle de sshd.
from="203.0.113.0/24,198.51.100.7",no-pty,no-port-forwarding ssh-ed25519 AAAAC3Nza... admin@phone
command="/usr/local/bin/backup.sh",restrict ssh-ed25519 AAAAC3Nza... backup@nas
restrict,pty ssh-ed25519 AAAAC3Nza... support@laptop- from="patterns" : la clé n'est acceptée que lorsque le client se connecte depuis ces adresses ou noms d'hôte. Les jokers, la notation CIDR et la négation avec
!sont autorisés. - command="…" : impose cette commande, quoi que demande le client. La commande demandée est conservée dans
SSH_ORIGINAL_COMMANDafin qu'un script puisse la valider. - no-pty : aucun terminal n'est alloué. Utile pour les clés rsync, de sauvegarde ou de déploiement.
- no-port-forwarding, no-agent-forwarding, no-X11-forwarding : désactivent individuellement chaque type de redirection.
- restrict : désactive tout ce qui précède d'un coup ; vous réactivez ensuite ce dont vous avez besoin, par exemple avec
pty.
Associer command= à restrict est le schéma standard pour les clés de sauvegarde : même si la clé fuite, elle ne peut exécuter que ce seul script. from= ajoute une seconde barrière, mais un téléphone en données mobiles a rarement une IP source fixe. Dans ce cas, il vaut mieux passer par un réseau maillé privé comme Prialo ou Tailscale et restreindre from= aux adresses de ce réseau.
5 erreurs courantes avec authorized_keys et comment les repérer
La première étape de diagnostic est toujours ssh -v user@server : elle montre quelles clés le client propose et à quel moment le serveur les refuse.
- Mauvaises permissions ou mauvais propriétaire. Copier le fichier en tant que root le laisse appartenir à root, et sshd l'ignore. Le bloc chmod et chown ci-dessus corrige le problème.
- Clé coupée sur plusieurs lignes. Coller depuis un éditeur qui renvoie le texte à la ligne casse la clé. Chaque clé doit tenir sur une seule ligne.
- Options avec des espaces ou des guillemets non fermés. Un espace après une virgule ou un guillemet fermant manquant invalide toute la ligne, et sshd l'écarte sans prévenir le client.
- Clé RSA refusée à cause de l'algorithme. Depuis OpenSSH 8.8, la signature
ssh-rsautilisant SHA-1 est désactivée par défaut, si bien que les clients plus anciens ne peuvent plus se connecter. La solution consiste à passer à Ed25519, pris en charge depuis OpenSSH 6.5. - command= qui casse Mosh, SFTP ou scp. Mosh lance
mosh-servervia une connexion SSH initiale et SFTP demande son sous-système ; un command= fixe remplace les deux. Depuis OpenSSH 9.0, scp utilise SFTP par défaut, il échoue donc lui aussi. Gardez des clés distinctes pour les sessions interactives et l'automatisation.
Gérer authorized_keys sur iOS et Android ou sur un ordinateur
La clé privée peut être générée sur le téléphone lui-même et conservée dans le stockage sécurisé du système, de sorte que le serveur n'a besoin que de la ligne publique ajoutée à authorized_keys.
| Tâche | iOS/Android avec termi1 | Ordinateur avec OpenSSH |
|---|---|---|
| Générer la clé | Sur le téléphone ; conservée dans le stockage sécurisé | ssh-keygen -t ed25519 |
| Installer la clé publique | La coller dans authorized_keys ou associer un Mac via Companion | ssh-copy-id user@server |
| Inspecter le fichier | SFTP intégré sans quitter la session | Éditeur local ou client sftp |
| Éditer avec vim ou nano | Clavier personnalisé avec Esc, Ctrl, Tab et flèches | Clavier physique |
| Coupure réseau en pleine tâche | Mosh et tmux maintiennent la session | La session SSH meurt |
Dans le terminal SSH et Mosh termi1, la clé privée ne quitte jamais l'appareil et n'atteint jamais les serveurs de Sinergia, et termi1 Companion (macOS 14 ou ultérieur) installe la clé publique sur un Mac avec un code à six chiffres. Demandez à l'IA de « corriger mes permissions ssh » et elle tape chmod 600 ~/.ssh/authorized_keys dans l'invite sans appuyer sur Entrée ; sur les connexions marquées comme production, Production Guard bloque tout ce qui modifie l'état. Le terminal est gratuit, fonctionne sans compte et est disponible sur l'App Store et Google Play.
Questions fréquentes
Quelles permissions doit avoir authorized_keys ?
authorized_keys doit être en 600, lisible et modifiable uniquement par son propriétaire, et le répertoire ~/.ssh en 700. Avec StrictModes activé, ce qui est le cas par défaut, sshd ignore le fichier si le groupe ou les autres peuvent écrire dedans, dans ~/.ssh ou dans le répertoire personnel.
Que fait command= dans authorized_keys ?
command= dans authorized_keys impose une commande précise chaque fois que quelqu'un s'authentifie avec cette clé, quelle que soit la demande du client. La commande demandée est conservée dans la variable SSH_ORIGINAL_COMMAND. On l'utilise généralement pour les clés de sauvegarde et de déploiement, combinée à restrict ou no-pty.
Pourquoi SSH demande-t-il encore un mot de passe après l'ajout de ma clé ?
SSH revient au mot de passe lorsque sshd n'accepte aucune clé d'authorized_keys. Les causes habituelles sont des permissions trop ouvertes, un mauvais propriétaire, une clé coupée sur plusieurs lignes ou une option mal saisie. Lancer ssh -v sur le client et lire le journal de sshd sur le serveur permet d'identifier laquelle.
Mosh fonctionne-t-il avec une clé restreinte dans authorized_keys ?
Mosh fonctionne avec des clés restreintes tant qu'elles ne comportent pas de command=, car il lance mosh-server via une connexion SSH initiale. Ensuite, la session passe en UDP, par défaut sur les ports 60000-61000, qui doivent être ouverts dans le pare-feu du serveur.