Connexion SSH par clé sous Linux : clés ed25519 et désactivation du mot de passe

15 min de lecture 4 vues 0
Sommaire

Tout serveur doté d'une IPv4 publique reçoit des tentatives de force brute SSH quelques minutes après sa mise en ligne, et ce sont les connexions par mot de passe qui sont visées. Ce guide explique comment mettre en place la connexion SSH par clé sous Linux avec une clé ed25519, puis désactiver l'authentification SSH par mot de passe sans vous enfermer dehors. Les étapes s'appliquent à Debian 11/12, Ubuntu 20.04/22.04/24.04, CentOS 7 et Rocky Linux / AlmaLinux 8 et 9, sur un serveur cloud JUSTG à Johannesburg, Moscou, Tokyo ou Séoul comme sur un serveur dédié.

Étape 1 : Générer une paire de clés SSH ed25519 sur votre ordinateur

La clé se crée sur la machine depuis laquelle vous vous connectez, jamais sur le serveur. Les clés ed25519 sont courtes, rapides et prises en charge par toutes les versions récentes d'OpenSSH. Une phrase de passe protège la clé privée en cas de vol du portable ; ssh-agent la mémorise pour la session.

# On your own computer (Linux, macOS, or Windows 10/11 PowerShell)
ssh-keygen -t ed25519 -C "laptop-2026"
# Press Enter to accept ~/.ssh/id_ed25519, then set a passphrase

Vous obtenez id_ed25519 (clé privée, à garder secrète) et id_ed25519.pub (clé publique, à copier sur les serveurs).

Étape 2 : Copier la clé publique sur le serveur

Sous Linux et macOS, le plus simple est ssh-copy-id : il se connecte une dernière fois avec le mot de passe et ajoute la clé à ~/.ssh/authorized_keys sur le serveur.

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
# Custom port example:
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 [email protected]

Windows ne fournit pas ssh-copy-id, mais PowerShell permet d'envoyer la clé par un pipe :

# Windows PowerShell (ssh-copy-id is not included on Windows)
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Étape 3 : Ajouter la clé à la main et corriger les droits d'authorized_keys

Si vous préférez coller la clé vous-même, ou si vous travaillez depuis la console VNC, créez le fichier manuellement. OpenSSH ignore sans prévenir authorized_keys lorsque le dossier ou le fichier est modifiable par d'autres utilisateurs : les permissions comptent autant que la clé.

# On the server, as the user that will log in
mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys      # paste ONE key per line, then save
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$(id -un)":"$(id -gn)" ~/.ssh
# CentOS / Rocky / AlmaLinux with SELinux enforcing:
restorecon -Rv ~/.ssh
Chaque clé publique doit tenir sur une seule ligne commençant par ssh-ed25519. Un retour à la ligne ajouté par un éditeur ou une messagerie est la cause la plus fréquente d'une clé refusée.

Étape 4 : Tester la connexion SSH par clé avant toute modification

Ouvrez un nouveau terminal et connectez-vous en imposant l'authentification par clé. Si aucun mot de passe n'est demandé (hors phrase de passe de la clé), la clé fonctionne.

ssh -i ~/.ssh/id_ed25519 -o PasswordAuthentication=no [email protected]

Étape 5 : Désactiver le mot de passe SSH dans sshd_config

Les distributions récentes chargent /etc/ssh/sshd_config.d/*.conf via une ligne Include en haut du fichier principal, et sshd retient la première valeur lue pour chaque option. Un fichier comme 50-cloud-init.conf contenant PasswordAuthentication yes peut donc annuler discrètement votre modification plus bas dans sshd_config. Un fichier drop-in dont le nom arrive en premier règle le problème.

# Check that the drop-in directory is included
grep -i '^Include' /etc/ssh/sshd_config

# Create a drop-in that sorts first (sshd keeps the FIRST value it reads)
cat > /etc/ssh/sshd_config.d/01-key-only.conf <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF

# Look for files that still turn passwords back on (e.g. 50-cloud-init.conf)
grep -ri 'PasswordAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Sur CentOS 7 et les systèmes plus anciens sans dossier sshd_config.d, placez ces quatre lignes directement dans /etc/ssh/sshd_config et commentez tout PasswordAuthentication yes situé avant. PermitRootLogin prohibit-password autorise root uniquement par clé ; mettez no si vous utilisez un compte sudo classique.

Étape 6 : Valider la configuration SSH et recharger le service

# Validate syntax first - no output means OK
sshd -t
# Show the effective values
sshd -T | grep -Ei 'passwordauthentication|pubkeyauthentication|permitrootlogin|kbdinteractive'

# Debian / Ubuntu
systemctl reload ssh
# CentOS / Rocky / AlmaLinux
systemctl reload sshd

Le rechargement conserve votre session actuelle, mais le test n'est fait qu'à moitié.

Étape 7 : Tester dans une deuxième session avant de fermer la première

Ne fermez pas encore votre fenêtre SSH. Ouvrez un second terminal et reconnectez-vous. Déconnectez-vous seulement quand la nouvelle session fonctionne avec la clé et qu'une tentative par mot de passe seul est refusée.
# From a NEW terminal on your computer
ssh [email protected]
# Must be refused:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]
# Expected: Permission denied (publickey).

En cas d'échec, corrigez le fichier drop-in depuis la première session restée ouverte puis rechargez. Si l'accès est déjà perdu, connectez-vous à l'espace client JUSTG → Mes produits et services → sélectionnez le VPS → panneau de gestion, et utilisez la console VNC ; si vous ne la trouvez pas, ouvrez un ticket.

Questions fréquentes

ed25519 est-il préférable à RSA pour les clés SSH ?

Pour une nouvelle clé, oui : sécurité élevée, clé beaucoup plus courte et négociation plus rapide. Gardez RSA 4096 pour les très anciens systèmes qui ne gèrent pas ed25519.

Le mot de passe est encore demandé, pourquoi ?

Lancez sshd -T | grep -i passwordauthentication. Si la réponse est yes, un autre fichier de sshd_config.d est lu avant le vôtre. Consultez aussi /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (Rocky/AlmaLinux) à la recherche de « bad ownership or modes » concernant ~/.ssh.

Puis-je utiliser la même clé sur plusieurs serveurs JUSTG ?

Oui, copiez la même clé publique sur chaque serveur avec ssh-copy-id. Conservez la clé privée uniquement sur vos appareils et révoquez un appareil perdu en supprimant sa ligne dans authorized_keys.

Si la connexion par clé SSH ne fonctionne toujours pas, ouvrez un ticket sur https://www.justg.com/submitticket.php et le support technique JUSTG vous aidera.

Cette réponse était-elle pertinente?