Où sont stockées les clés SSH sous Linux — Et comment les gérer de manière sécurisée

SSH (Secure Shell) est l’un des outils les plus critiques de l’écosystème Linux. Les administrateurs système, les développeurs et les ingénieurs DevOps l’utilisent quotidiennement pour l’accès aux serveurs distants, les transferts de fichiers sécurisés, l’automatisation du déploiement et la gestion de l’infrastructure. Bien que la plupart des utilisateurs interagissent avec SSH via une simple commande de terminal, le véritable fondement de la sécurité réside dans les paires de clés SSH — des identifiants cryptographiques qui permettent l’authentification sans mot de passe, les flux de travail automatisés et le contrôle d’accès renforcé.

Que vous gériez une seule instance VPS Hosting ou orchestriez l’accès sur des dizaines de Serveurs Dédiés, comprendre exactement où les clés SSH sont stockées — et comment les gérer correctement — n’est pas facultatif. C’est une exigence fondamentale de sécurité.

Ce guide couvre tout : les emplacements de stockage des clés par défaut, les clés d’hôte au niveau du système, les configurations personnalisées, les exigences de permissions et les meilleures pratiques pour la gestion sécurisée des clés.

Qu’est-ce que les clés SSH et pourquoi sont-elles importantes ?

Les clés SSH utilisent la cryptographie asymétrique pour authentifier les utilisateurs et les serveurs. Chaque paire de clés se compose de :

• Clé privée — conservée secrète sur la machine client, jamais partagée
• Clé publique — placée sur le serveur distant pour vérifier l’identité

Lorsque vous vous connectez à un serveur, SSH utilise une négociation cryptographique pour vérifier que vous possédez la clé privée correspondant à la clé publique sur le serveur — sans jamais transmettre la clé privée elle-même. C’est fondamentalement plus sécurisé que l’authentification par mot de passe.

Emplacement de stockage par défaut des clés SSH (clés utilisateur)

Pour tout utilisateur Linux standard, les clés SSH sont stockées dans un répertoire caché dans le dossier personnel :

~/.ssh/

Cela se développe en chemin complet :

/home/username/.ssh/

Pour l’utilisateur root spécifiquement :

/root/.ssh/

Fichiers courants dans ~/.ssh/

Lorsque vous exécutez ssh-keygen, les clés sont écrites dans ce répertoire par défaut, sauf si vous spécifiez explicitement un chemin différent lors de la génération de clés.

Emplacements des clés SSH au niveau du système (clés d’hôte)

Au-delà des clés utilisateur, le daemon SSH (sshd) — le composant côté serveur — maintient son propre ensemble de clés d’hôte. Celles-ci sont stockées au niveau du système à :

/etc/ssh/

Fichiers de clés d’hôte dans /etc/ssh/

Ces clés d’hôte servent un objectif différent des clés utilisateur. Lorsqu’un client se connecte à un serveur pour la première fois, le serveur présente sa clé publique d’hôte. Le client stocke cette empreinte dans ~/.ssh/known_hosts. Lors des connexions ultérieures, SSH vérifie que l’empreinte correspond — protégeant contre les attaques de l’homme du milieu.

> Important : Les clés d’hôte sont générées automatiquement lors de l’installation du serveur SSH. Vous ne devriez jamais avoir besoin de les créer manuellement, mais vous devriez savoir où elles se trouvent à des fins d’audit et de sauvegarde.

Emplacements personnalisés des clés SSH

Vous n’êtes pas limité au répertoire ~/.ssh/ par défaut. Les clés SSH peuvent être générées et stockées n’importe où sur le système de fichiers. Pour utiliser une clé stockée dans un emplacement non par défaut, spécifiez-la explicitement :

ssh -i /path/to/custom_key user@host

Utilisation de ~/.ssh/config pour plusieurs clés

La gestion de plusieurs serveurs, projets ou comptes utilisateur devient beaucoup plus propre avec un fichier ~/.ssh/config correctement configuré. Cela vous permet de définir des paramètres par hôte, y compris la clé à utiliser :

Host production-server
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/production_ed25519

Host staging-server
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/staging_ed25519

Host github.com
    User git
    IdentityFile ~/.ssh/github_key

Avec cette configuration, l’exécution de ssh production-server utilise automatiquement la clé correcte sans aucun drapeau supplémentaire.

Comment les clés SSH sont utilisées : Client vs. Serveur

Connexions sortantes (côté client)

Lorsque vous initiez une connexion SSH, le client SSH recherche les clés privées dans ~/.ssh/ par défaut. Ces clés sont utilisées pour vous authentifier auprès du serveur distant.

Les outils qui utilisent les clés client SSH incluent :

• ssh — accès direct au shell distant
• scp — copie sécurisée de fichiers
• rsync — synchronisation de fichiers via SSH
• git — lors de l’utilisation de dépôts distants basés sur SSH

Connexions entrantes (côté serveur)

Sur le serveur, SSH vérifie un fichier spécifique pour déterminer quels utilisateurs sont autorisés à se connecter :

~/.ssh/authorized_keys

Ce fichier contient une clé publique par ligne. Chaque entrée accorde au détenteur de la clé privée correspondante la permission de se connecter en tant que cet utilisateur.

Exemple pratique : Si l’utilisateur alice souhaite se connecter en SSH à un serveur en tant qu’utilisateur webadmin, la clé publique d’Alice doit être présente dans /home/webadmin/.ssh/authorized_keys — pas dans le répertoire personnel d’Alice sur ce serveur.

Autorisations de fichiers — Critiques pour la sécurité SSH

C’est là que de nombreux administrateurs commettent des erreurs coûteuses. SSH est délibérément strict concernant les autorisations de fichiers. Si les autorisations sont trop ouvertes, SSH refusera silencieusement d’utiliser vos clés ou rejettera entièrement les tentatives de connexion.

Paramètres d’autorisation requis

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/config

Tableau de référence des autorisations

Pour corriger les autorisations en une seule commande :

chmod 700 ~/.ssh && chmod 600 ~/.ssh/* && chmod 644 ~/.ssh/*.pub

Génération sécurisée de clés SSH

Préférez toujours Ed25519 à RSA pour les nouvelles clés. Ed25519 offre une sécurité plus forte avec des tailles de clé plus courtes et des performances plus rapides.

ssh-keygen -t ed25519 -C "your_email@example.com"

Pour les systèmes hérités qui nécessitent RSA, utilisez au moins 4096 bits :

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Définissez toujours une phrase de passe lorsque vous y êtes invité. Une phrase de passe chiffre la clé privée sur le disque, donc même si un attaquant accède à votre système de fichiers, il ne peut pas utiliser la clé sans la phrase de passe.

Gestion des clés avec ssh-agent

Entrer votre phrase de passe à chaque fois que vous utilisez une clé SSH devient impratique. ssh-agent résout ce problème en mettant en cache les clés déchiffrées en mémoire pour la durée de votre session.

Démarrage de ssh-agent et ajout d’une clé

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Vous serez invité à entrer la phrase de passe une fois. Après cela, les opérations SSH utilisent la clé en cache automatiquement.

Commandes ssh-agent utiles

# List currently loaded keys
ssh-add -l

# Remove a specific key from the agent
ssh-add -d ~/.ssh/mykey

# Remove all keys from the agent
ssh-add -D

Copie des clés publiques vers des serveurs distants

Le moyen le plus simple d’installer votre clé publique sur un serveur distant est avec ssh-copy-id:

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

Cela ajoute votre clé publique à ~/.ssh/authorized_keys sur le serveur distant et définit automatiquement les permissions correctes.

Si ssh-copy-id n’est pas disponible, faites-le manuellement:

cat ~/.ssh/id_ed25519.pub | ssh user@remote-host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Audit et débogage des problèmes de clés SSH

Journalisation détaillée des connexions

Quand l’authentification SSH échoue, le mode verbeux révèle exactement ce qui se passe :

ssh -v user@host

Pour encore plus de détails :

ssh -vvv user@host

Cette sortie montre quels fichiers d’identité ont été tentés, si l’agent a été consulté, et où l’authentification a échoué.

Vérifier le journal SSH côté serveur

Sur le serveur distant, les événements d’authentification SSH sont enregistrés dans :

# Debian/Ubuntu
tail -f /var/log/auth.log

# CentOS/RHEL/Fedora
tail -f /var/log/secure

# Systems using journald
journalctl -u sshd -f

Vérifier votre fichier authorized_keys

# Check the file exists and has correct permissions
ls -la ~/.ssh/authorized_keys

# View its contents
cat ~/.ssh/authorized_keys

# Count how many keys are authorized
grep -c "ssh-" ~/.ssh/authorized_keys

Meilleures pratiques de sécurité des clés SSH

La gestion appropriée des clés va au-delà de savoir où les fichiers sont stockés. Suivez ces pratiques sur chaque système que vous gérez :

1. Utilisez une clé par objectif

Ne réutilisez jamais la même clé SSH dans différents environnements, clients ou projets. Utilisez des clés distinctes pour l’accès personnel, l’automatisation du déploiement et l’accès partagé en équipe.

2. Renouvelez les clés régulièrement

Traitez les clés SSH comme des mots de passe — renouvelez-les périodiquement, en particulier après le départ de membres de l’équipe ou en cas de compromission suspectée.

3. Auditez les fichiers authorized_keys

Examinez régulièrement les clés publiques autorisées sur chaque serveur. Supprimez toutes les clés appartenant à d’anciens employés, à une automatisation obsolète ou à des sources non reconnues :

# Find all authorized_keys files on a system
find / -name "authorized_keys" 2>/dev/null

4. Désactivez l’authentification par mot de passe

Une fois les clés SSH configurées, désactivez complètement la connexion SSH basée sur les mots de passe dans /etc/ssh/sshd_config :

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Redémarrez sshd après les modifications :

systemctl restart sshd

5. Limitez l’utilisation des clés root

Évitez d’utiliser des clés SSH root dans plusieurs environnements. Utilisez plutôt des comptes utilisateur activés pour sudo avec des clés individuelles.

6. Utilisez l’authentification basée sur les certificats pour la mise à l’échelle

Pour les grandes infrastructures, envisagez les certificats SSH (via une autorité de certificats SSH) au lieu de gérer les entrées authorized_keys individuelles. Cela simplifie considérablement la gestion des accès sur de nombreux serveurs.

Clés SSH dans les environnements Cloud et Hosting

Lors du déploiement de serveurs dans des environnements cloud ou d’hébergement géré, la gestion des clés SSH devient encore plus critique. La plupart des plateformes — y compris les fournisseurs d’Hébergement VPS — vous permettent d’injecter une clé publique au moment du provisionnement, vous donnant un accès sécurisé immédiat sans jamais définir de mot de passe.

Pour les équipes gérant plusieurs environnements, envisagez d’associer votre stratégie de clé SSH à une configuration structurée de Panneaux de Contrôle VPS, qui peut simplifier la gestion des utilisateurs et le contrôle d’accès dans votre infrastructure.

Si vous exécutez des applications web ou des services qui nécessitent une communication sécurisée au-delà de SSH, l’association de votre configuration de serveur avec des Certificats SSL correctement configurés garantit un chiffrement de bout en bout pour tout le trafic — pas seulement l’accès administratif.

Pour les équipes qui s’appuient sur l’Hébergement Email aux côtés de leur infrastructure de serveur, la gestion des clés SSH s’étend à la sécurisation des systèmes qui gèrent votre courrier — une autre raison pour laquelle une hygiène des clés cohérente sur tous les serveurs est importante.

Référence rapide : Emplacements des fichiers de clé SSH

Conclusion

Comprendre où les clés SSH sont stockées dans Linux — et les gérer avec discipline — est l’une des compétences les plus importantes pour quiconque travaille avec des serveurs, que vous soyez un développeur indépendant ou membre d’une grande équipe d’exploitation.

Pour résumer les points clés à retenir :

• Les clés utilisateur se trouvent dans ~/.ssh/ et sont utilisées pour l’authentification côté client
• Les clés d’hôte se trouvent dans /etc/ssh/ et identifient le serveur aux clients qui se connectent
• authorized_keys contrôle l’accès entrant — auditez-le régulièrement
• Les permissions de fichier sont non négociables — des permissions incorrectes cassent silencieusement SSH
• Ed25519 est le type de clé préféré pour la génération de nouvelles clés
• Utilisez toujours des phrases de passe et ssh-agent pour la gestion quotidienne des clés
• Faites tourner et auditez les clés dans le cadre de votre hygiène de sécurité régulière

Sur les systèmes de production — que vous exécutiez des Serveurs Dédiés ou une infrastructure partagée — la mauvaise gestion des clés SSH est l’un des vecteurs les plus courants d’accès non autorisé. L’investissement de temps pour bien faire les choses porte ses fruits en matière de sécurité, de fiabilité et de tranquillité d’esprit.

Traitez vos clés SSH avec le même soin que vous accorderiez à toute autre information d’identification critique. Parce que c’est exactement ce qu’elles sont.