SSH: authentification via clefs privé/publique

L’authentification SSH par mot de passe fonctionne, mais elle est faible: le mot de passe se tape à chaque connexion, il peut être brute-forcé (fail2ban atténue mais ne résout pas) et il ne distingue pas “qui” de “quoi”. Les clefs SSH résolvent les trois: la clef privée prouve l’identité, la clef publique autorise l’accès et une fois configurée, plus de mot de passe.

Générer la paire

ssh-keygen -t rsa -b 4096 -C "commentaire"

Le -t rsa génère une paire RSA, le -b 4096 définit la taille (2048 minimum, 4096 recommandé). Le -C est un commentaire libre (l’email ou le hostname habituellement). Deux fichiers: id_rsa (la clé privée, ne jamais sortir du poste) et id_rsa.pub (la clé publique, à copier sur les serveurs).

Déployer la clé publique

ssh-copy-id user@serveur

Cette commande copie le contenu de id_rsa.pub dans ~/.ssh/authorized_keys sur le serveur (chmod 600, .ssh 700). Elle peut se faire manuellement:

cat ~/.ssh/id_rsa.pub | ssh user@serveur "cat >> ~/.ssh/authorized_keys"

Une fois déployée, la connexion se fait sans mot de passe:

ssh user@serveur

L’agent SSH

La passphrase de la clé privée peut être mise en cache par ssh-agent:

eval $(ssh-agent)
ssh-add ~/.ssh/id_rsa

Le passphrase est demandé une fois, puis l’agent signe les connexions sans redemander. Avec keychain, l’agent persiste entre les sessions (il stocke le socket dans un fichier que les shells suivants réutilisent).

Désactiver l’authentification par mot de passe

Une fois que toutes les clefs sont déployées, on peut fermer la porte:

# /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no

/etc/init.d/ssh restart

À ce stade, seuls les possesseurs de la clé privée peuvent se connecter. Le brute-force du mot de passe ne fonctionne plus (il n’y a plus de mot de passe). Le serveur SSH passe de “accessible par tout le monde avec un mot de passe” à “accessible par qui a la clé”. C’est la plus grosse montée en sécurité d’un serveur SSH et elle prend 5 minutes.

La notion de authorized_keys

Le fichier ~/.ssh/authorized_keys contient une clé publique par ligne. Chaque ligne autorise un accès pour la clé privée correspondante. On peut restreindre chaque ligne:

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

Cette ligne autorise SEULEMENT rsync (pas de shell, pas de port forwarding, pas de X11, pas de terminal). C’est le mécanisme de sauvegarde sécurisé: la machine de backup a une clé qui ne peut faire qu’une chose.

[edit: 2026] Les clefs SSH sont toujours le mécanisme d’authentification standard, Ed25519 a remplacé RSA comme choix par défaut et les certificats SSH (ssh-keygen -s) ont ajouté une couche d’expiration et de revocation. Le PasswordAuthentication no reste la première chose à faire sur un serveur SSH neuf. Les rootkits SSH qui hookent PAM existent toujours et la défense reste la même: mot de passe désactivé, clefs uniquement et un audit des authorized_keys (ils s’accumulent et personne ne les nettoie).

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