SSH StrictModes, transfert d'agent (ssh -A) et ssh -a expliqués

En bref : `StrictModes yes` (valeur par défaut d'OpenSSH) fait vérifier à sshd le propriétaire et les permissions de votre répertoire personnel, de `~/.ssh` et de `~/.ssh/authorized_keys` avant d'accepter une clé, et refuse la connexion avec « Authentication refused: bad ownership or modes » si l'un d'eux est modifiable par le groupe ou les autres, ou appartient à un autre utilisateur. Corrigez les permissions plutôt que de désactiver la vérification. Le transfert d'agent avec `ssh -A` permet à l'hôte distant d'utiliser vos clés locales pendant que vous êtes connecté : évitez-le sur les hôtes auxquels vous ne faites pas entièrement confiance et utilisez plutôt `ssh -J` (ProxyJump) ; `ssh -a` en minuscule désactive explicitement le transfert d'agent.

Ce guide complète le guide de durcissement SSH et s'applique à Debian 12/13, Ubuntu 24.04 et aux systèmes de la famille RHEL comme AlmaLinux 9 et Rocky 9.

Ce que vérifie SSH StrictModes

StrictModes est un paramètre côté serveur dans `/etc/ssh/sshd_config`. Son but est simple : si un autre utilisateur pouvait écrire dans votre `authorized_keys`, il pourrait y ajouter sa propre clé et se connecter sous votre identité. sshd refuse donc de faire confiance au fichier si tout le chemin n'est pas protégé. Il vérifie le fichier et les répertoires au-dessus, y compris le répertoire personnel.

Confirmez la valeur effective avec `sshd -T | grep -i strictmodes`. Sur Ubuntu 24.04 et Debian 13, vérifiez aussi les fichiers drop-in de `/etc/ssh/sshd_config.d/`.

Corriger « Authentication refused: bad ownership or modes »

Le client n'affiche qu'un générique `Permission denied (publickey)`. La vraie raison se trouve dans le journal du serveur, qui indique le chemin exact, par exemple `Authentication refused: bad ownership or modes for directory /home/alice` ou `... for file /home/alice/.ssh/authorized_keys`. Utilisez la console de votre VPS ou une autre session pour corriger.

1. 01.Lisez le journal : `journalctl -u ssh -n 50` sur Debian et Ubuntu, ou `journalctl -u sshd -n 50` sur AlmaLinux et Rocky.
2. 02.Corrigez le propriétaire du répertoire SSH de l'utilisateur : `chown -R alice:alice /home/alice/.ssh`.
3. 03.Corrigez les modes : `chmod 700 /home/alice/.ssh` et `chmod 600 /home/alice/.ssh/authorized_keys`.
4. 04.Retirez le droit d'écriture du groupe et des autres sur le répertoire personnel : `chmod go-w /home/alice`.
5. 05.Sur les systèmes SELinux (AlmaLinux, Rocky, Fedora), restaurez les labels : `restorecon -Rv /home/alice/.ssh`.
6. 06.Testez depuis un nouveau terminal avec `ssh -v alice@server` en gardant la session fonctionnelle ouverte.

# all-in-one, run as root on the server
chown -R alice:alice /home/alice/.ssh
chmod go-w /home/alice
chmod 700 /home/alice/.ssh
chmod 600 /home/alice/.ssh/authorized_keys
namei -l /home/alice/.ssh/authorized_keys   # shows owner and mode of every path component

Note · Ne définissez pas `StrictModes no` pour faire disparaître l'erreur. Cela supprime une vraie protection et masque la mauvaise configuration au lieu de la corriger.

StrictModes ou StrictHostKeyChecking

Les recherches sur « ssh strictmode » confondent souvent deux options sans rapport. `StrictModes` se trouve dans `sshd_config` sur le serveur et vérifie les permissions des fichiers. `StrictHostKeyChecking` se trouve dans `ssh_config` ou `~/.ssh/config` sur le client et détermine ce qui se passe lorsque la clé d'hôte d'un serveur est inconnue ou a changé. Le client a aussi sa propre vérification des permissions : il refuse d'utiliser une clé privée lisible par d'autres utilisateurs, avec un avertissement sur un fichier de clé privée non protégé ; `chmod 600 ~/.ssh/id_ed25519` règle le problème.

Transfert d'agent avec ssh -A : le risque

`ssh -A` (ou `ForwardAgent yes`) crée sur l'hôte distant un socket, référencé par `$SSH_AUTH_SOCK`, qui relaie les demandes de signature vers le ssh-agent de votre machine. Votre clé privée ne quitte jamais votre machine, mais quiconque accède à ce socket peut utiliser votre clé pendant que vous êtes connecté. Sur l'hôte distant, cela inclut root et tout processus tournant sous votre utilisateur.

Si le serveur est compromis, ou administré par quelqu'un d'autre, un attaquant peut se connecter discrètement à tous les autres hôtes que votre clé ouvre, y compris l'hébergement Git et les serveurs de production. C'est pourquoi le client OpenSSH utilise par défaut `ForwardAgent no`.

• ▹Ne transférez jamais votre agent vers des hôtes partagés, tiers ou fraîchement réinstallés que vous n'avez pas durcis.
• ▹Si vous devez transférer, utilisez `ssh-add -c` pour que chaque utilisation de la clé exige une confirmation locale.
• ▹OpenSSH 8.9 et ultérieur prend en charge les contraintes de destination avec `ssh-add -h`, qui limitent les hôtes pour lesquels une clé transférée peut servir.
• ▹Côté serveur, `AllowAgentForwarding no` dans `sshd_config` le désactive, même si les utilisateurs disposant d'un shell peuvent toujours mettre en place leurs propres relais.

Préférez ProxyJump (ssh -J) pour les bastions

Le transfert d'agent sert le plus souvent à rebondir par un bastion vers une machine interne. `ssh -J` le fait sans exposer votre agent : le bastion ne fait que relayer un flux TCP chiffré, et l'authentification auprès de l'hôte interne se fait de bout en bout depuis votre ordinateur. Pour les serveurs joignables uniquement via un réseau privé, un tunnel WireGuard est une autre option ; voir le guide VPN WireGuard ou le guide du maillage WireGuard, et pour les réglages keepalive et PSK ce guide de réglage WireGuard.

Sur un VPS NoctisNode, vous avez l'accès root complet en SSH sur une machine KVM : une petite offre Wisp peut servir d'hôte de rebond dédié sans rien d'autre dessus ; voir offres VPS.

# one-off
ssh -J [email protected] [email protected]

# ~/.ssh/config
Host bastion
    HostName bastion.example.com
    User alice
    ForwardAgent no

Host db1
    HostName 10.88.0.3
    User alice
    ProxyJump bastion

Ce que fait ssh -a (minuscule)

`ssh -a` en minuscule désactive le transfert d'agent pour cette connexion, à l'inverse de `-A`. C'est utile quand votre `~/.ssh/config` active `ForwardAgent` pour un hôte générique et que vous voulez être sûr qu'une connexion précise ne transfère pas, par exemple `ssh -a admin@untrusted-host`. Ne le confondez pas avec `ssh-agent -a`, qui définit le chemin du socket de l'agent, ni avec `ssh-add`, qui charge des clés dans l'agent.

FAQ