Configurer une clé SSH sur un VPS Linux sans perdre l’accès

Une clé SSH permet à un client SSH, le Secure Shell, de s’authentifier sur un serveur distant Linux sans saisir le mot de passe du compte à chaque connexion. Cette cryptographie asymétrique repose sur une clé privée conservée sur la machine locale et une clé publique installée sur la machine distante.

Ce guide concerne un administrateur de VPS sous Debian, Ubuntu ou une distribution Unix proche. Il explique comment créer les clefs, les transférer, tester la connection SSH et modifier le fichier de configuration sans perdre l’accès au shell Bash.

Avant de commencer : garder un accès de secours

Ouvrez une première connexion SSH et ne la fermez pas pendant toute l’opération. Cette connexion de secours permet de corriger une erreur si la nouvelle authentification échoue. Notez l’adresse IP du VPS, le nom d’utilisateur distant, le port TCP utilisé par SSH et le nom du service lancé sur votre distribution.

Si votre hébergeur propose une console de secours, identifiez-la aussi. Elle peut aider à restaurer le fichier de configuration du serveur SSH en cas de problème de service ou de pare-feu. Vérifiez également qu’un compte administrateur de récupération existe réellement.

Générer une paire de clés sur le poste client

Depuis votre poste local, utilisez la ligne de commande et la commande SSH ssh-keygen. Ed25519 est un choix courant pour une nouvelle clé. RSA reste présent sur de nombreux environnements hérités, mais son usage doit respecter la politique du système et de l’organisation :

ssh-keygen -t ed25519 -C "admin-vps"
# Alternative pour un environnement ancien :
ssh-keygen -t rsa -b 4096 -C "admin-vps"

Validez le chemin proposé ou choisissez un nom distinct si vous avez déjà des clefs. Protégez la clé privée, parfois appelée clef privée, par une phrase secrète. La clé privée reste sur le poste client et ne doit pas être copiée dans un ticket, un dépôt Git ou sur le serveur distant.

Copier la clé publique vers le VPS

La clé publique, ou clef publique, se termine généralement par .pub. Avec un accès SSH existant, transférez-la vers le compte distant avec ssh-copy-id :

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@ADRESSE_IP

Si le serveur écoute sur un autre port TCP, précisez-le avec -p PORT. Le nom d’utilisateur ou login doit être celui du compte qui ouvrira le shell. La ligne complète de la clé publique doit être ajoutée dans ~/.ssh/authorized_keys, sans retour à la ligne au milieu.

Si ssh-copy-id n’est pas disponible, affichez la clé publique avec cat ~/.ssh/id_ed25519.pub, puis ajoutez son contenu dans authorized_keys du compte distant. Le transfert peut aussi être réalisé avec SCP si cet outil est autorisé. Ne copiez jamais le fichier sans extension : il s’agit de la clé privée.

Vérifier les permissions de la clé

Le serveur SSH peut refuser un fichier de clés dont les permissions sont trop ouvertes. Sur la machine distante, contrôlez le dossier et le fichier :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ls -ld ~/.ssh ~/.ssh/authorized_keys

Les fichiers doivent appartenir au bon nom d’utilisateur. Si vous intervenez dans le compte d’un autre administrateur, vérifiez le propriétaire et corrigez-le uniquement avec les privilèges adaptés. Une clé publique mal placée, un dossier appartenant à root ou un chemin incorrect suffit à faire échouer la connexion.

Tester la connexion SSH par clé

Depuis un second terminal, testez explicitement la nouvelle clé. Gardez la première session ouverte tant que ce test n’est pas réussi :

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 utilisateur@ADRESSE_IP

Pour un port personnalisé, utilisez ssh -p PORT -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 utilisateur@ADRESSE_IP. Un test réussi doit ouvrir un shell avec le bon compte distant. Vérifiez l’identité de la machine avec whoami et hostname pour ne pas confondre deux serveurs.

La même authentification peut ensuite être utilisée par des outils SFTP ou par des scripts d’administration. Testez ces usages séparément, car un script peut employer un autre nom d’utilisateur, une autre clé ou un autre port. Une authentification par mot de passe encore active doit aussi être traitée selon votre politique de sécurité.

Vérifier la configuration du serveur SSH

Avant de modifier /etc/ssh/sshd_config, créez une copie de sauvegarde :

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Contrôlez le fichier de configuration et la configuration effective avant de recharger le service :

sudo sshd -t
sudo sshd -T | grep -E "pubkeyauthentication|passwordauthentication|port"

Une commande sans message d’erreur indique généralement que la syntaxe est acceptée. Si le contrôle échoue, ne rechargez pas SSH : corrigez le fichier depuis la connexion encore ouverte, puis recommencez le test.

Désactiver le mot de passe seulement après le test

Une fois l’authentification par clé confirmée dans le second terminal, vous pouvez adapter la politique du service. Les directives courantes sont PubkeyAuthentication yes et, si tous les comptes concernés ont une clé fonctionnelle, PasswordAuthentication no. La désactivation du mot de passe doit tenir compte des comptes de secours, des automatisations et de la procédure de récupération.

Après chaque modification du fichier de configuration, relancez sudo sshd -t. Rechargez ensuite le service sans couper la session actuelle :

sudo systemctl reload ssh

Selon la distribution, le nom du service peut être sshd. Si le rechargement échoue, conservez la connexion existante et consultez l’état du service avec sudo systemctl status ssh --no-pager. Ne redémarrez pas le service avant d’avoir validé la syntaxe.

Diagnostiquer un échec de connexion

Lancez le client SSH en mode verbeux depuis le poste local :

ssh -vvv -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 utilisateur@ADRESSE_IP

Les causes fréquentes sont un mauvais nom d’utilisateur, un port erroné, une clé publique incomplète, des permissions incorrectes, une clé privée non chargée ou un pare-feu qui bloque la connexion TCP. Côté serveur, les journaux du service SSH indiquent souvent si la clé a été lue, refusée ou recherchée dans un mauvais chemin.

Ne publiez pas ces journaux : ils peuvent contenir des noms de comptes, des adresses IP ou des détails sur la machine distante. Si le serveur est totalement inaccessible, suivez d’abord une procédure de diagnostic réseau avant de modifier davantage le fichier SSH.

Bonnes pratiques après la configuration

• Conservez une clé de secours protégée et documentée, sans la partager.
• Retirez les anciennes clefs de authorized_keys seulement après avoir identifié leur propriétaire.
• Utilisez un compte administrateur nominatif et limitez l’usage direct de root selon votre politique.
• Documentez le port SSH, le nom d’utilisateur, la console de secours et la procédure de restauration.
• Testez périodiquement une connexion SSH et un transfert SFTP depuis le poste prévu.

Pour approfondir votre préparation, consultez aussi les premiers réglages de sécurité d’un serveur dédié, le guide Docker sur un VPS, le diagnostic d’un VPS inaccessible, la page VPS Ubuntu et les serveurs dédiés.