Le dossier ~/.ssh : fichiers, autorisations et mise en page

Lorsque SSH cesse d’accepter une clé après avoir copié des fichiers sur un nouvel ordinateur, restauré une sauvegarde ou changé de propriétaire, le premier endroit à vérifier est ~/.ssh. OpenSSH utilise ce répertoire pour vos clés privées et publiques, les enregistrements d’hôte de confiance et les paramètres de connexion par hôte.

Certains fichiers du répertoire sont publics, tandis que d’autres doivent rester privés. Ce guide explique ce que fait chaque fichier, quelles autorisations utiliser et en quoi la présentation diffère entre un client et un serveur SSH.

Référence rapide #

Pour une référence rapide imprimable, consultez l’aide-mémoire SSH .

Où se trouve le dossier #

Le ~/.ssh Le répertoire se trouve dans votre répertoire personnel. Les outils OpenSSH le créent en cas de besoin, par exemple lorsque vous générez une clé ou vous connectez à un hôte pour la première fois.

Vous pouvez confirmer l’emplacement avec :

ls -ld ~/.ssh

drwx------ 2 sara sara 4096 Mar 4 14:22 /home/sara/.ssh

Dans cette sortie, sara est propriétaire du répertoire et rwx------ correspond au mode 700. Cela donne au propriétaire un accès complet tout en bloquant tout le monde.

OpenSSH n’exige pas que tous les fichiers du répertoire soient secrets. Cependant, un accès en écriture de groupe ou mondial peut amener le serveur à rejeter authorized_keystandis que les autorisations de clé privée lâches obligent le client à ignorer cette clé.

Clés privées et publiques #

Lorsque vous générez une paire de clés avec ssh-keygendeux fichiers atterrissent dans ~/.ssh:

ssh-keygen -t ed25519 -C "sara@workstation"

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/sara/.ssh/id_ed25519):

Presse Enter pour accepter le chemin par défaut. Une fois la clé générée, vous aurez deux nouveaux fichiers :

• id_ed25519 est la clé privée. Il doit rester sur la machine sur laquelle vous l’avez généré et ne doit jamais être partagé. Les autorisations sont 600 (propriétaire lecture/écriture uniquement). Si le fichier est même lisible par le groupe, OpenSSH refuse de l’utiliser.
• id_ed25519.pub est la clé publique. Il est destiné à être copié sur d’autres machines, collé dans les tableaux de bord d’hébergement ou ajouté à ~/.ssh/authorized_keys sur les serveurs. Les autorisations sont généralement 644.

Vous pouvez également voir id_rsa et id_rsa.pub sur des systèmes plus anciens. OpenSSH reconnaît ces noms par défaut et les essaie automatiquement lorsqu’aucun IdentityFile est réglé. Pour les nouvelles clés, Ed25519 est la meilleure valeur par défaut car les clés sont plus petites et l’authentification est rapide.

clés_autorisées #

Côté serveur, ~/.ssh/authorized_keys répertorie les clés publiques autorisées à se connecter en tant qu’utilisateur. Chaque ligne est une clé publique complète, exactement telle qu’elle apparaît dans un .pub dossier sur le client.

cat ~/.ssh/authorized_keys

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIE2... sara@workstation
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPgs... sara@laptop

Chaque ligne donne accès à une clé publique. Le commentaire facultatif à la fin, tel que sara@workstationvous aide à identifier d’où vient la clé.

Le fichier doit appartenir au compte qui l’utilise et ne doit pas être accessible en écriture par d’autres utilisateurs. Mode 600 est le réglage recommandé. Avec StrictModes activé (par défaut), le serveur SSH vérifie également le chemin parent, donc votre répertoire personnel ne doit pas être accessible en écriture par un groupe ou par tout le monde, même si ~/.ssh en soi est correct.

Pour copier une clé publique sur un serveur, utilisez ssh-copy-id au lieu de modifier le fichier manuellement :

ssh-copy-id sara@example.com

La commande ajoute votre clé publique et évite de remplacer les clés déjà présentes dans le fichier.

hôtes_connus #

Le ~/.ssh/known_hosts Le fichier enregistre les clés d’hôte des serveurs auxquels vous vous êtes connecté auparavant. La première fois que vous vous connectez en SSH à un nouvel hôte, OpenSSH imprime l’empreinte digitale de l’hôte et vous demande de confirmer. Une fois que vous avez accepté, la clé est ajoutée ici et toute modification future de cette clé d’hôte déclenche un avertissement aigu au lieu d’une reconnexion silencieuse.

ssh-keygen -F example.com

# Host example.com found: line 3
|1|abc...=|def...= ssh-ed25519 AAAAC3Nz...

La sortie affiche l’entrée correspondante et son numéro de ligne. Le leader |1| signifie que le nom d’hôte est haché. OpenSSH utilise ce format lorsque HashKnownHosts yes est activé dans la configuration du client. La valeur par défaut en amont est nobien que votre distribution Linux puisse l’activer dans /etc/ssh/ssh_config.

Lorsqu’un serveur obtient une nouvelle clé d’hôte, par exemple après une réinstallation, supprimez uniquement l’ancienne entrée au lieu de supprimer l’intégralité du fichier :

ssh-keygen -R example.com

Mode 644 est courant car le fichier contient des clés d’hôte publiques. Sur une machine partagée, vous pouvez utiliser le mode 600 pour empêcher les autres utilisateurs de lire les noms de serveurs non hachés.

configuration #

Le ~/.ssh/config Le fichier est l’endroit où se trouvent les raccourcis par hôte et les options par hôte. Un petit exemple :

Host work-server
 HostName example.com
 User sara
 Port 2222
 IdentityFile ~/.ssh/id_ed25519_work
 IdentitiesOnly yes

Host *
 ServerAliveInterval 60
 ServerAliveCountMax 3

Avec cette configuration, ssh work-server se connecte à example.com au port 2222 comme sara et utilise uniquement la clé spécifiée. Le Host * block s’applique à chaque hôte, ce qui en fait un endroit utile pour les valeurs par défaut telles que keepalives.

OpenSSH utilise la première valeur trouvée pour chaque option. Placez les blocs hôtes spécifiques en haut et les paramètres généraux en bas.

OpenSSH nécessite que ~/.ssh/config n’est pas accessible en écriture par d’autres utilisateurs. Mode 600 empêche également les autres utilisateurs de la machine de lire vos noms d’hôte et vos noms de compte.

Réinitialiser les autorisations SSH #

Si les autorisations ont changé après la copie ou la restauration du répertoire, utilisez les commandes suivantes pour réinitialiser les fichiers standard :

chmod 700 ~/.ssh
find ~/.ssh -maxdepth 1 -type f -name 'id_*' ! -name '*.pub' -exec chmod 600 {} +
find ~/.ssh -maxdepth 1 -type f -name '*.pub' -exec chmod 644 {} +
for file in authorized_keys config; do
 ( -e "$HOME/.ssh/$file" ) && chmod 600 "$HOME/.ssh/$file"
done
( -e ~/.ssh/known_hosts ) && chmod 644 ~/.ssh/known_hosts

Le premier find mode jeux de commandes 600 sur les clés privées, tandis que le second définit le mode 644 sur les clés publiques. Les vérifications restantes mettent à jour uniquement les fichiers existants, vous pouvez donc exécuter le blocage sur un compte client ou serveur sans erreur pour les fichiers manquants.

Disposition client ou serveur #

Le même ~/.ssh Le répertoire contient différents fichiers selon que la machine agit en tant que client ou serveur dans une session donnée.

Un client type a :

ls ~/.ssh

config id_ed25519 id_ed25519.pub known_hosts

Ce client dispose d’une paire de clés, d’une configuration de connexion et d’un enregistrement des serveurs connus.

Un compte de serveur typique possède :

ls ~/.ssh

authorized_keys

Le serveur a seulement besoin authorized_keys pour accepter les connexions par clé pour ce compte. Une machine peut également être à la fois client et serveur. Par exemple, votre poste de travail peut utiliser des clés privées pour les connexions sortantes et conserver authorized_keys pour les transferts SCP entrants.

Dépannage #

Permissions 0644 for '~/.ssh/id_ed25519' are too open

La clé privée est lisible par le groupe ou par tout le monde. Courir chmod 600 ~/.ssh/id_ed25519 et réessayez.

Authentication refused: bad ownership or modes for directory /home/sara

OpenSSH vérifie tout le chemin. Le répertoire personnel est accessible en écriture en groupe, ce qui permet à un autre utilisateur de remplacer .ssh. Courir chmod go-w ~ sur le serveur.

Clé publique copiée mais la connexion échoue toujours

Confirmez que la clé a été ajoutée et non écrasée dans authorized_keys. Comparez les empreintes digitales avec ssh-keygen -lf ~/.ssh/id_ed25519.pub sur le client et ssh-keygen -lf ~/.ssh/authorized_keys sur le serveur.

FAQ #

Puis-je déplacer ~/.ssh vers un autre chemin ?

Oui, mais vous devez configurer le nouveau chemin. Sur le client, passez -i ou définir IdentityFile pour chaque hôte. Sur le serveur, définissez AuthorizedKeysFile dans /etc/ssh/sshd_config. Conserver la mise en page par défaut est généralement plus simple.

Est-il sécuritaire de sauvegarder ~/.ssh ?

Les clés publiques peuvent être sauvegardées librement. Le config et known_hosts les fichiers peuvent exposer les noms de compte et les adresses de serveur, alors gardez ces sauvegardes privées. Traitez les clés privées comme des mots de passe : chiffrez la sauvegarde et ne la stockez jamais dans un bucket cloud public ou un référentiel Git.

Pourquoi OpenSSH se soucie-t-il des autorisations du répertoire personnel ?

Si votre répertoire personnel est accessible en écriture en groupe, un autre utilisateur peut le remplacer ~/.ssh avec les leurs. Pour empêcher cette classe d’attaque, OpenSSH refuse d’utiliser un ~/.ssh accessible par un chemin trop permissif.

Conclusion #

Mode d’utilisation 700 pour l’annuaire, 600 pour les clés privées et authorized_keyset 644 pour les clés publiques et known_hosts. Lorsque l’authentification par clé échoue après une copie ou une restauration de fichier, la vérification de ces modes constitue une première étape intéressante.

Pour une lecture connexe, consultez nos guides sur la génération de clés SSH et la commande ssh-copy-id.