Authentification SSH par clé : Ed25519, ssh-agent et sécurité du serveur

EdwardMoon

L'authentification SSH par clé repose sur une chaîne de confiance : vérifier l'identité du serveur, protéger la clé privée, déployer la clé publique, tester une nouvelle session et renforcer la politique de connexion. Conservez la clé privée sur le client et protégez-la avec une phrase secrète et ssh-agent.

Ce guide utilise Ed25519 et présente aussi l'alternative RSA en mode FIPS. Il suit l'ordre d'exploitation : vérification de known_hosts, permissions d'authorized_keys, validation de sshd, révocation des clés et récupération après erreur.

Distinguer les deux vérifications SSH

Une authentification utilisateur par clé publique ne suffit pas à garantir la sécurité. Vérifiez l'empreinte de la clé d'hôte du serveur depuis une console fiable, un inventaire des équipements ou un canal indépendant pour détecter une substitution du serveur de destination.

Créer sur le client une clé protégée par une phrase secrète

Ed25519 constitue un choix simple et sûr dans les environnements courants. Il peut toutefois être interdit en mode FIPS ; utilisez alors une clé RSA suffisamment longue conformément à la politique applicable. Choisissez un nom de fichier propre à chaque usage pour ne pas écraser une clé existante.

install -d -m 0700 ~/.ssh
ssh-keygen -t ed25519 -a 100   -f ~/.ssh/id_ed25519_ops   -C 'ops-admin@client'
chmod 0600 ~/.ssh/id_ed25519_ops
chmod 0644 ~/.ssh/id_ed25519_ops.pub

Alternative RSA pour une politique FIPS

ssh-keygen -t rsa -b 3072 -o -a 100   -f ~/.ssh/id_rsa_ops   -C 'ops-admin@client'

Gérer les clés déverrouillées avec ssh-agent

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_ops
ssh-add -l

Vérifier l'empreinte du serveur par un canal indépendant

Affichez l'empreinte de la clé publique d'hôte depuis la console du serveur et comparez-la à celle présentée au client. ssh-keyscan collecte une clé sans prouver qu'elle appartient au véritable serveur : ne faites pas confiance à sa sortie sans vérification.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

ssh-keyscan -t ed25519 server.example.com > /tmp/server.hostkey
ssh-keygen -lf /tmp/server.hostkey
install -m 0600 /tmp/server.hostkey ~/.ssh/known_hosts.ops
rm -f /tmp/server.hostkey

Déployer la clé publique dans authorized_keys

Lors de la première configuration, connectez-vous une fois avec le mot de passe actuellement autorisé ou depuis la console pour ajouter la clé publique. Quand ssh-copy-id est disponible, il facilite la gestion des doublons et des permissions.

ssh-copy-id -i ~/.ssh/id_ed25519_ops.pub ops@server.example.com

Déploiement manuel sans ssh-copy-id

cat ~/.ssh/id_ed25519_ops.pub   | ssh ops@server.example.com     'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'

# À partir d'ici, exécuter dans une session de l'utilisateur ops sur le serveur.
chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys
restorecon -RFv ~/.ssh

Sur les distributions RHEL avec SELinux actif, les contextes doivent être corrects en plus des permissions. Vérifiez également que les autres utilisateurs ne peuvent pas écrire dans le répertoire personnel.

Alias client et sélection explicite de la clé

Host prod-app-01
    HostName server.example.com
    User ops
    IdentityFile ~/.ssh/id_ed25519_ops
    IdentitiesOnly yes
    UserKnownHostsFile ~/.ssh/known_hosts.ops

chmod 0600 ~/.ssh/config
ssh -v prod-app-01

Vérifier avant de désactiver la connexion par mot de passe

ssh -o PreferredAuthentications=publickey   -o PasswordAuthentication=no   prod-app-01
sudo -v
whoami

Contrôler la syntaxe et les valeurs effectives de sshd

sudo sshd -t
sudo sshd -T   | grep -E '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '

Après validation de l'authentification par clé, placez la politique dans un fichier complémentaire. L'ordre des inclusions et les blocs Match peuvent modifier les valeurs finales. Vérifiez donc la sortie de sshd -T, et pas seulement le contenu du fichier.

sudo install -d -m 0755 /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/20-key-auth.conf >/dev/null <<'CONF'
PubkeyAuthentication yes
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
CONF

sudo sshd -t
sudo sshd -T | grep -E "^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) "
sudo systemctl reload sshd

ssh -o PreferredAuthentications=publickey prod-app-01
sudo journalctl -u sshd --since '-10 minutes' --no-pager

Limiter l'usage des clés et les révoquer

Séparez les clés d'automatisation des clés administratives personnelles. Si nécessaire, limitez les adresses sources ou les fonctions avec les options d'authorized_keys. Ces restrictions peuvent bloquer des tunnels ou un PTY réellement nécessaires : testez-les d'abord dans un environnement de test.

from="198.51.100.0/24",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... deploy-key

En cas de fuite ou de départ d'un utilisateur, retirez la ligne de clé publique concernée. Pour une révocation centralisée, créez une KRL OpenSSH et référencez-la avec RevokedKeys dans sshd. Si une KRL existe déjà, utilisez -u pour préserver les révocations précédentes. Préparez le nouveau fichier temporaire sur le même système de fichiers, puis remplacez-le atomiquement. Si sshd ne peut pas lire la KRL, toutes les authentifications par clé publique peuvent être refusées : conservez une session administrateur et la console de secours. Avec des blocs Match, précisez aussi les conditions réelles de connexion, par exemple sshd -T -C user=ops,host=client.example.com,addr=198.51.100.10.

KRL_STAGE_DIR=$(sudo mktemp -d /etc/ssh/krl-stage.XXXXXX)
if sudo test -f /etc/ssh/revoked.krl; then
  sudo cp -p /etc/ssh/revoked.krl "$KRL_STAGE_DIR/revoked.krl"
  sudo ssh-keygen -k -u -f "$KRL_STAGE_DIR/revoked.krl" compromised_key.pub
else
  sudo ssh-keygen -k -f "$KRL_STAGE_DIR/revoked.krl" compromised_key.pub
fi
sudo chown root:root "$KRL_STAGE_DIR/revoked.krl"
sudo chmod 0644 "$KRL_STAGE_DIR/revoked.krl"
sudo mv "$KRL_STAGE_DIR/revoked.krl" /etc/ssh/revoked.krl
sudo rmdir "$KRL_STAGE_DIR"
sudo restorecon /etc/ssh/revoked.krl
sudoedit /etc/ssh/sshd_config.d/20-key-auth.conf
# Ajouter la ligne suivante dans la configuration globale du fichier ci-dessus.
# RevokedKeys /etc/ssh/revoked.krl
sudo sshd -t
sudo sshd -T | grep "^revokedkeys "
sudo systemctl reload sshd

Résoudre les problèmes d'authentification

ssh -vvv prod-app-01
ssh-add -l
ssh-keygen -lf ~/.ssh/id_ed25519_ops.pub
sudo journalctl -u sshd -b --no-pager
sudo namei -l /home/ops/.ssh/authorized_keys
sudo ls -ldZ /home/ops /home/ops/.ssh /home/ops/.ssh/authorized_keys
sudo sshd -T

• Après un refus suivant Offering public key, vérifiez l'utilisateur, la ligne de clé publique, les permissions et les contextes SELinux.
• Pour Too many authentication failures, définissez explicitement IdentitiesOnly et IdentityFile.
• Face à REMOTE HOST IDENTIFICATION HAS CHANGED, vérifiez une éventuelle réinstallation du serveur ou modification DNS avant de supprimer l'entrée.
• Si une modification bloque l'accès, restaurez le fichier complémentaire depuis la session existante ou la console, puis exécutez sshd -t.

Documentation officielle et guides associés

• Red Hat : sécuriser les communications avec OpenSSH
• Manuel OpenSSH de sshd_config
• Manuel OpenSSH de ssh-keygen
• Playbooks Ansible et sécurité de l'automatisation SSH
• Comptes de gestion et vérification des clés d'hôte avec Kubespray

La sécurité des clés SSH dépend de tout leur cycle de vie. Gardez les clés privées sur le client, vérifiez l'empreinte du serveur, testez une nouvelle session avant de renforcer la politique et prévoyez la révocation immédiate des clés compromises. Ces étapes permettent à la connexion par clé d'améliorer réellement la sécurité.