Authentification par clé SSH (ED25519)

L'authentification par mot de passe en SSH a une limite : les mots de passe peuvent être devinés par brute-force. Les clés SSH offrent une sécurité bien supérieure : et une fois configurées, plus de saisie de mot de passe pour chaque connexion. C'est la méthode recommandée pour tout serveur professionnel.

Le principe clé publique / clé privée

Imaginez un cadenas (clé publique) et sa clé (clé privée) :

• Vous déposez le cadenas ouvert sur le serveur (dans authorized_keys)
• Vous gardez la clé sur votre machine, bien protégée
• Pour vous connecter, le serveur "ferme le cadenas" avec votre clé publique → seul celui qui possède la clé privée peut "ouvrir"

Personne n'a besoin de connaître votre clé privée : elle ne quitte jamais votre machine.

Générer une paire de clés ED25519

ED25519 est l'algorithme recommandé en 2026 : plus court que RSA et plus sécurisé.

# Sur votre machine locale (pas sur le serveur !)
ssh-keygen -t ed25519 -C "jean-tech@entreprise.fr"

# Résultat :
# Generating public/private ed25519 key pair.
# Enter file in which to save the key (/home/jean/.ssh/id_ed25519):
# Enter passphrase (empty for no passphrase): [mot de passe de protection optionnel]
# Your identification has been saved in /home/jean/.ssh/id_ed25519
# Your public key has been saved in /home/jean/.ssh/id_ed25519.pub

Deux fichiers sont créés dans ~/.ssh/ :

• id_ed25519 → clé privée (ne jamais partager, chmod 600 obligatoire)
• id_ed25519.pub → clé publique (à déposer sur les serveurs)

Déployer la clé publique sur un serveur

# Méthode automatique (recommandée)
ssh-copy-id alice@192.168.1.10
# Demande le mot de passe une dernière fois, puis configure authorized_keys

# Méthode manuelle
cat ~/.ssh/id_ed25519.pub | ssh alice@srv-glpi "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Le fichier ~/.ssh/authorized_keys sur le serveur contient une clé publique par ligne. SSH l'utilise pour vérifier l'identité du client.

Se connecter avec la clé (sans mot de passe)

ssh alice@192.168.1.10
# Connexion immédiate, pas de mot de passe demandé !

Simplifier avec ~/.ssh/config

Ce fichier de configuration permet de définir des alias et options par serveur :

# ~/.ssh/config

Host glpi
    HostName 192.168.1.10
    User alice
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host backup-srv
    HostName 192.168.1.30
    User technicien
    IdentityFile ~/.ssh/id_ed25519_backup
    Port 2222

Avec ce fichier, la connexion devient simplement :

ssh glpi          # au lieu de ssh alice@192.168.1.10
scp fichier glpi:/tmp/   # au lieu de scp fichier alice@192.168.1.10:/tmp/

Désactiver l'authentification par mot de passe

Une fois les clés déployées sur tous les accès nécessaires :

# Dans /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes

# Recharger SSH
sudo systemctl reload sshd

Attention : vérifiez que votre clé fonctionne AVANT de désactiver les mots de passe, sinon vous pourrez vous retrouver bloqué hors du serveur.

sequenceDiagram
  participant C as Client (jean-tech)
  participant S as Serveur SSH

  Note over C: Possède id_ed25519 (privée)
  Note over S: authorized_keys contient id_ed25519.pub

  C->>S: Demande de connexion avec clé ED25519
  S->>S: Génère un challenge chiffré avec la clé publique
  S-->>C: Envoie le challenge
  C->>C: Déchiffre avec la clé privée
  C-->>S: Envoie la réponse
  S->>S: Vérifie la réponse
  S-->>C: Authentification réussie → shell ouvert

Cas concret

Vous configurez l'accès SSH sans mot de passe pour les scripts de sauvegarde automatiques (cron) :

# 1. Sur le serveur de sauvegarde, générer une clé dédiée (sans passphrase pour l'automatisation)
ssh-keygen -t ed25519 -C "backup-script" -f ~/.ssh/id_ed25519_backup -N ""

# 2. Déployer sur le serveur GLPI
ssh-copy-id -i ~/.ssh/id_ed25519_backup.pub alice@srv-glpi

# 3. Tester la connexion automatique
ssh -i ~/.ssh/id_ed25519_backup alice@srv-glpi "hostname"
# srv-glpi

# 4. Dans le script cron
ssh -i /home/backup/.ssh/id_ed25519_backup alice@srv-glpi "mysqldump glpi" > /opt/backups/glpi.sql

Erreurs fréquentes

• Mauvais droits sur ~/.ssh/ ou authorized_keys : SSH est très strict. Le dossier doit être en 700, le fichier en 600. Sinon SSH refuse silencieusement les clés.
• Générer la clé sur le serveur au lieu de la machine cliente : la clé privée doit rester sur VOTRE machine. Sur le serveur, on ne dépose que la clé publique (*.pub).
• Perdre sa clé privée sans backup : sans clé privée ET sans mot de passe, vous n'avez plus accès. Sauvegardez ~/.ssh/ dans un gestionnaire de mots de passe.

À retenir

• ssh-keygen -t ed25519 génère la paire : id_ed25519 (privée, secret) + id_ed25519.pub (publique, à déposer).
• ssh-copy-id user@serveur déploie la clé publique en une commande.
• ~/.ssh/config simplifie les connexions avec des alias et options par hôte.

Mini-exercice

Sur votre machine, générez une paire de clés ED25519 avec ssh-keygen -t ed25519. Affichez la clé publique avec cat ~/.ssh/id_ed25519.pub : c'est cette ligne que vous déposerez dans authorized_keys sur vos serveurs. Notez le format : ed25519 [clé-base64] [commentaire].