Clés SSH ou mot de passe ?

Sur un VPS NeoHeberg, la première connexion SSH se fait en root avec le mot de passe fourni dans le dashboard. Ce secret donne tous les droits sur la machine, et il est aussi la cible la plus scannée d'Internet. Les clés SSH suppriment ce point faible, à condition de garder une porte de secours.

Comment fonctionne une paire de clés

Une clé SSH se compose d'une clé privée, qui reste sur votre poste, et d'une clé publique, copiée dans ~/.ssh/authorized_keys sur le serveur. À la connexion, le serveur envoie un défi que seul le détenteur de la clé privée peut signer. Le secret ne circule jamais sur le réseau et le serveur ne stocke rien qui permette de se connecter à votre place.

Créer et installer la clé

Générez une clé Ed25519, plus courte et plus solide que RSA pour un usage courant :

ssh-keygen -t ed25519 -a 100 -C "poste-principal"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@VOTRE_IPV6

La première commande crée ~/.ssh/id_ed25519 (privée) et ~/.ssh/id_ed25519.pub (publique). La seconde ajoute la publique au serveur et crée les permissions correctes : 700 pour ~/.ssh, 600 pour authorized_keys. Testez sans fermer la session existante :

ssh -o PreferredAuthentications=publickey root@VOTRE_IPV6

Phrase secrète, agent et clé matérielle

Une phrase secrète chiffre la clé privée sur le disque. Sans elle, un fichier volé suffit à se connecter ; avec elle, il faut aussi la deviner. ssh-agent mémorise la clé déverrouillée pour la session et évite de la retaper à chaque commande. Une clé FIDO2 (ssh-keygen -t ed25519-sk) exige en plus une confirmation physique à chaque connexion, ce qui protège même si le fichier est copié.

Prévoyez toujours un second moyen d'accès : une deuxième clé présente dans authorized_keys, une copie chiffrée de la clé privée hors du poste, ou la console du dashboard. La console accepte le mot de passe root même quand l'authentification par mot de passe est désactivée pour SSH.

Désactiver le mot de passe

Gardez une session ouverte et validez la configuration dans une seconde session avant de couper quoi que ce soit. Créez un fichier dédié plutôt que de modifier le fichier principal :

sudo tee /etc/ssh/sshd_config.d/10-cles-seulement.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF
sudo sshd -t
sudo systemctl reload ssh

sshd -t vérifie la syntaxe sans appliquer la configuration. PermitRootLogin prohibit-password autorise root par clé et refuse le mot de passe ; créez un utilisateur sudo si vous préférez interdire root en SSH.

Vérifier et dépanner

• sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin' affiche la configuration effective.
• ssh -v root@VOTRE_IPV6 montre quelle méthode d'authentification est tentée.
• journalctl -u ssh -n 50 explique un refus côté serveur.

En cas de verrouillage, ouvrez la console noVNC depuis le dashboard : vous restez root sur la machine. Supprimez la ligne fautive de authorized_keys pour révoquer une clé, puis rechargez SSH.