Rédigé par Rédaction CyberSDF / 19 September 2026

bad ownership or modes : les droits de .ssh et de authorized_keys

Authentication refused: bad ownership or modes for file /home/alice/.ssh/authorized_keys est écrit par sshd, pas par le client : la clé publique a bien été trouvée, mais le fichier est modifiable par le groupe ou par les autres comptes, et sshd refuse alors de s’en servir. La correction tient en trois valeurs : 700 pour ~/.ssh, 600 pour ~/.ssh/authorized_keys, et aucun bit d’écriture pour le groupe sur le répertoire personnel.

Le motif du refus n’apparaît que dans le journal du serveur

Le client affiche alice@serveur: Permission denied (publickey). et ne reçoit jamais la cause. La ligne qui explique tout est journalisée par sshd au niveau INFO, donc visible avec le LogLevel par défaut, sans passer en DEBUG.

Authentication refused: bad ownership or modes for file /home/alice/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/alice

La variante file désigne authorized_keys, la variante directory un répertoire de la chaîne qui mène jusqu’à lui : les deux peuvent apparaître dans la même connexion, car la fonction safe_path() valide chaque composant avant d’ouvrir le fichier.

sudo journalctl -u ssh -e
sudo tail -f /var/log/auth.log

L’unité s’appelle ssh sous Debian et Ubuntu, sshd sous Arch et sur les distributions RPM, comme pour les autres services systemd ; le fichier /var/log/auth.log n’existe que si rsyslog est installé, et la rubrique Linux regroupe le reste du diagnostic système.

Un seul bit déclenche le refus : l’écriture pour le groupe ou les autres

Du côté serveur, OpenSSH n’examine jamais les bits de lecture. Le test refuse un fichier ou un répertoire dont le propriétaire n’est pas le compte visé, ou dont le mode contient le bit d’écriture du groupe (020) ou celui des autres (002). authorized_keys en 664 échoue, en 644 passe ; ~/.ssh en 775 échoue, en 755 passe. Le contrôle remonte du fichier jusqu’au répertoire personnel inclus, puis s’arrête : les droits de /home et de / n’entrent pas dans ce test. La lecture d’un mode chiffré suit les permissions et les utilisateurs : 4 pour la lecture, 2 pour l’écriture, 1 pour la traversée.

StrictModes, qui pilote cette vérification, vaut yes par défaut ; sshd_config(5) précise qu’elle porte sur les fichiers de l’utilisateur et sur son répertoire personnel avant d’accepter la connexion, et qu’elle ne s’applique pas à ChrootDirectory, contrôlé de toute façon.

sudo sshd -T | grep -i strictmodes

La sortie est strictmodes yes, quelle que soit la version installée : Debian 13 embarque OpenSSH 10.0p1 (paquet 1:10.0p1-7+deb13u4), Debian 12 OpenSSH 9.2p1 (1:9.2p1-2+deb12u10) et Ubuntu 24.04 OpenSSH 9.6p1.

Sept chemins contrôlés, une valeur attendue par chemin

Les valeurs viennent d’OpenSSH 9.2p1 (Debian 12), pour un compte dont le répertoire personnel est /home/alice : c’est le masque d’écriture 022 que safe_path() applique.

Une valeur 0775 sur le répertoire personnel suffit à faire échouer le contrôle, même quand .ssh et authorized_keys sont parfaits. Sur Debian 12, adduser crée les répertoires personnels en 0700 par défaut, valeur de DIR_MODE dans /etc/adduser.conf.

Remettre les droits, du répertoire personnel au fichier

Les cinq corrections s’exécutent depuis le compte visé, sauf la dernière, qui demande root.

1. Relever les modes actuels des trois niveaux.

   stat -c '%U %G %a %n' ~ ~/.ssh ~/.ssh/authorized_keys

   Ce que vous devez voir : trois lignes, alice alice 755 /home/alice, alice alice 700 /home/alice/.ssh, alice alice 600 /home/alice/.ssh/authorized_keys. Un 775 sur la première ou un 6 en tête sur la deuxième désigne la cause.

2. Afficher chaque composant du chemin, pour repérer un répertoire fautif que le message nomme sans lien évident avec .ssh.

   namei -l ~/.ssh/authorized_keys

   Ce que vous devez voir : une ligne par composant, du / jusqu’au fichier, avec les droits et le propriétaire de chacun.

3. Fermer l’écriture du groupe sur le répertoire personnel, puis rendre .ssh traversable par son seul propriétaire.

   chmod go-w ~
   chmod 700 ~/.ssh

   Ce que vous devez voir : stat -c '%a' ~ renvoie 755 ou 700, et ls -ld ~/.ssh affiche drwx------.

4. Restreindre authorized_keys à la lecture et à l’écriture du propriétaire.

   chmod 600 ~/.ssh/authorized_keys

   Ce que vous devez voir : ls -l ~/.ssh/authorized_keys affiche -rw-------.

5. Corriger le propriétaire si un autre compte détient les fichiers, ce qui arrive après un sudo cp ou une restauration faite en root.

   sudo chown -R alice:alice /home/alice/.ssh

   Ce que vous devez voir : la troisième colonne de ls -l ~/.ssh porte alice sur toutes les lignes.

Les modes sont relus à chaque tentative d’authentification : aucun redémarrage de sshd n’est nécessaire après un chmod. Un rechargement, avec sudo systemctl reload ssh, ne concerne que les modifications de /etc/ssh/sshd_config.

chmod -R 600 ~/.ssh retire le droit de traverser le dossier

Un répertoire sans bit de traversée n’ouvre plus les fichiers qu’il contient, même pour son propriétaire. Un chmod -R 600 ~/.ssh applique 600 au dossier comme aux fichiers, et sshd n’atteint plus authorized_keys : la connexion échoue toujours, mais la ligne du journal change, l’ouverture renvoyant ici une erreur autre que l’absence de fichier.

Could not open user 'alice' authorized keys '/home/alice/.ssh/authorized_keys': Permission denied

Le remède sépare les deux natures de droits : les répertoires gardent la traversée, les fichiers la perdent.

find ~/.ssh -type d -exec chmod 700 {} +
find ~/.ssh -type f -exec chmod 600 {} +
chmod 644 ~/.ssh/*.pub

Ce que vous devez voir : ls -ld ~/.ssh affiche drwx------, ls -l ~/.ssh des lignes -rw-------, sauf les fichiers .pub en -rw-r--r--. Un fichier absent laisse le journal muet au niveau INFO : la ligne No such file or directory n’est écrite qu’au niveau DEBUG.

Sur le poste client, la règle est plus stricte : 077 contre 022

Une clé privée ne suit pas le test du serveur. Le client refuse de charger un fichier dont un bit du masque 077 est posé, la lecture par le groupe comprise : 600 et 400 passent, 640 et 644 échouent. L’avertissement reste local au poste et n’empêche pas l’essai des autres clés.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/alice/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

chmod 600 ~/.ssh/id_ed25519

Ce que vous devez voir : l’avertissement disparaît et la clé repart vers le serveur, ce que confirme la ligne debug1: Offering public key: obtenue avec l’option -v. La préparation d’une connexion par clé est détaillée dans la mise en place d’une connexion SSH par clé.

Le fichier ~/.ssh/config obéit à un troisième test, propre au client : un propriétaire autre que le compte courant ou root, ou un bit d’écriture pour le groupe ou les autres, arrête la commande sur Bad owner or permissions on /home/alice/.ssh/config. Le script ssh-copy-id applique déjà les bonnes valeurs, avec umask 077 puis chmod 700 et chmod 600 côté serveur.

644 sur authorized_keys fonctionne, contrairement à ce que recommande le manuel

sshd(8) demande un répertoire ~/.ssh en lecture, écriture et exécution pour l’utilisateur, et un authorized_keys en lecture et écriture, sans accès des autres. Le code applique une règle plus étroite : seul le bit d’écriture du groupe ou des autres bloque, si bien qu’un authorized_keys en 644, un ~/.ssh en 755 et un répertoire personnel en 755 authentifient sans erreur, tandis que 664 et 775 échouent.

L’écart n’autorise pas à ouvrir les droits : un fichier lisible par tous expose la liste des clés autorisées, et un fichier modifiable par le groupe laisse un autre compte y ajouter la sienne. Le manuel tranche pour le dépannage : quand le fichier, le répertoire ~/.ssh ou le répertoire personnel sont modifiables par d’autres, sshd refuse de les utiliser, sauf si StrictModes vaut no, ce réglage supprimant tous les contrôles pour tous les comptes.

sudo sshd -t
sudo systemctl reload ssh

sshd -t reste muet quand la syntaxe est valide, et le rechargement applique la nouvelle configuration si le fichier a été modifié.

Sources : manuel sshd_config(5), StrictModes et AuthorizedKeysFile, manuel sshd(8), section FILES, misc.c d’OpenSSH 9.2p1, fonction safe_path(), masque 022, auth2-pubkeyfile.c, fonction auth_openfile(), journalisation Authentication refused, authfile.c, fonction sshkey_perm_ok(), masque 077, readconf.c, erreur fatale Bad owner or permissions, script contrib/ssh-copy-id, notes de version OpenSSH 9.8, PerSourcePenalties, versions OpenSSH des suites Debian bookworm et trixie, paquet openssh-server d’Ubuntu 24.04, version 9.6p1, adduser.conf(5), DIR_MODE à 0700.