Configurer l'authentification SSH par clé ED25519

L'authentification par clé SSH remplace les mots de passe par une paire de clés cryptographiques : bien plus sûre face aux attaques brute-force, et indispensable pour automatiser les scripts cron ou les déploiements. En helpdesk PME, c'est la base pour accéder à un serveur Linux sans saisir de mot de passe à chaque fois.

Clés vs mots de passe

Un mot de passe peut être deviné, intercepté ou volé. Une clé SSH repose sur la cryptographie asymétrique :

• Clé privée : stockée sur votre poste, ne quitte jamais votre machine.
• Clé publique : déposée sur le serveur. Seule la clé privée correspondante peut prouver votre identité.

ED25519 est l'algorithme recommandé aujourd'hui : plus court, plus rapide et plus sûr que RSA 2048.

Générer la paire de clés

Ouvrez un terminal sur votre poste (Linux, macOS, ou Windows avec OpenSSH installé) :

ssh-keygen -t ed25519 -C "helpdesk@entreprise.com"

• -t ed25519 : algorithme ED25519 (préféré à RSA).
• -C : commentaire identifiant la clé (email ou nom de machine).

Le système demande un emplacement (appuyez sur Entrée pour accepter ~/.ssh/id_ed25519) puis une passphrase. La passphrase chiffre la clé privée sur disque : même si quelqu'un vole votre fichier, il ne peut pas l'utiliser sans elle. Pour les scripts cron automatisés, on peut laisser vide : à peser selon le contexte de sécurité.

Deux fichiers sont créés :

Déployer la clé publique sur le serveur

Méthode rapide : ssh-copy-id

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.1.50

Cette commande ajoute automatiquement la clé dans ~/.ssh/authorized_keys sur le serveur avec les bons droits.

Méthode manuelle (si ssh-copy-id indisponible)

# Sur le serveur, en tant que l'utilisateur cible
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys   # coller le contenu de id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys

Les droits sont critiques : SSH refuse de fonctionner si ~/.ssh est accessible en écriture par d'autres.

Tester la connexion sans mot de passe

ssh user@192.168.1.50

Si la clé est déployée correctement, la connexion s'établit sans demander de mot de passe (ou demande uniquement la passphrase locale si vous en avez défini une).

Désactiver l'authentification par mot de passe

Important : testez la connexion par clé dans un second terminal AVANT de désactiver les mots de passe. Si vous vous enfermez dehors, il faudra accéder au serveur en console physique.

Sur le serveur, éditez /etc/ssh/sshd_config :

sudo nano /etc/ssh/sshd_config

Modifiez ou ajoutez :

PasswordAuthentication no
PubkeyAuthentication yes

Puis redémarrez SSH :

sudo systemctl restart ssh

Simplifier les connexions avec ~/.ssh/config

Le fichier de configuration client évite de retaper les options à chaque fois :

Host glpi-srv
    HostName 192.168.1.50
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Host backup-srv
    HostName 192.168.1.51
    User backupuser
    IdentityFile ~/.ssh/id_ed25519_backup

Connexion simplifiée : ssh glpi-srv au lieu de ssh -i ~/.ssh/id_ed25519 admin@192.168.1.50.

Fonctionnement à la connexion

sequenceDiagram
    participant C as Client (votre poste)
    participant S as Serveur SSH

    C->>S: Demande de connexion (user@serveur)
    S->>C: Challenge chiffré avec la clé publique
    C->>C: Déchiffre le challenge avec la clé privée
    C->>S: Réponse signée
    S->>S: Vérifie la signature avec authorized_keys
    S->>C: Accès accordé (sans mot de passe réseau)

Cas concret PME

Scénario : L'équipe helpdesk doit accéder au serveur GLPI (192.168.1.50) et lancer un script de sauvegarde automatique chaque nuit.

1. Générer une clé ED25519 dédiée au compte de service : ssh-keygen -t ed25519 -C "cron-backup" -f ~/.ssh/id_backup
2. Déployer la clé publique sur le serveur GLPI : ssh-copy-id -i ~/.ssh/id_backup.pub backupuser@192.168.1.50
3. Tester manuellement : ssh -i ~/.ssh/id_backup backupuser@192.168.1.50
4. Configurer le cron sur le poste helpdesk :

# crontab -e
0 2 * * * ssh -i /home/helpdesk/.ssh/id_backup backupuser@192.168.1.50 "/opt/scripts/backup-glpi.sh"

Le script s'exécute à 2h du matin sans intervention humaine et sans mot de passe en clair.

Erreurs fréquentes

• Mauvais droits sur ~/.ssh : si chmod n'est pas appliqué (700 sur le dossier, 600 sur authorized_keys), SSH refuse silencieusement la clé et retombe sur le mot de passe.
• Passphrase oubliée : une clé privée chiffrée avec une passphrase perdue est irrécupérable. Notez-la dans un gestionnaire de mots de passe ou utilisez ssh-agent pour ne la saisir qu'une fois par session.
• Désactiver PasswordAuthentication trop tôt : toujours ouvrir un second terminal et valider la connexion par clé avant de redémarrer SSH. Sinon, risque de se retrouver complètement bloqué hors du serveur.

À retenir

• ED25519 est l'algorithme recommandé : court, rapide, plus sûr que RSA 2048.
• La clé publique va sur le serveur (authorized_keys), la clé privée ne quitte jamais votre poste.
• Toujours tester la connexion par clé dans un terminal séparé avant de désactiver PasswordAuthentication.