SSH : Restreindre une connexion via clefs privée/publique

Quoi de plus évident lors de l’exécution de tâches automatisées diverses entre plusieurs serveurs que l’utilisation d’une paire de clefs ssh sans passphrase ?

Oui, mais comment cantonner cette clefs non protégée à l’exécution d’une tâche bien précise ?

Il suffit de préfixer la clefs publique à limiter dans le fichier :

.ssh/authorized_keys

Avec les options détaillées dans le manuel d’sshd à la section AUTHORIZED_KEYS FILE FORMAT:

command="/usr/bin/rsync --server --daemon .",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAA...

Chaque option bloque une voie d’échappement:

• command="..." : la clé ne peut exécuter QUE cette commande (rsync), pas de shell
• no-port-forwarding : pas de tunnel SSH via cette clé
• no-X11-forwarding : pas de display X11 distant
• no-agent-forwarding : pas d’agent SSH relayé (l’attaque “je vole l’agent de l’utilisateur”)
• no-pty : pas de terminal interactif (pas de shell même si command est vide)

La combinaison de ces cinq options transforme une clé “sans passphrase = porte ouverte” en une clé “sans passphrase = un seul usage, chiffré, limité”. C’est le pattern de sauvegarde automatisée entre serveurs: la machine de backup a une clé qui ne peut faire qu’une chose.

[edit: 2026] Ce mécanisme est toujours le pattern standard pour les tâches automatisées SSH. La version moderne ajoute restrict (qui remplace les cinq no-*) et principals= (pour les certificats). L’article compagnon SSH en 2021 documente la suite: les certificats, les FIDO2 et le ProxyJump qui a tué les tunnels administratifs.

[edit: 2026] L’implémentation Ansible de tout ceci: le rôle ssh .