SSH: résoudre missing privilege separation dir

Sur un serveur Ubuntu ou Debian fraîchement installé, il peut arriver que le service SSH refuse de démarrer ou que la vérification de configuration échoue avec une erreur autour de /run/sshd.

Le cas typique apparaît lorsque l’on lance un test de configuration avec sshd -t :

sudo sshd -t

Et que le serveur renvoie quelque chose comme :

Could not load host key: /etc/ssh/ssh_host_ed25519_key
Missing privilege separation directory: /run/sshdLangage du code : JavaScript (javascript)

Ces deux erreurs peuvent impressionner, surtout sur un serveur distant. Heureusement, elles sont généralement simples à corriger : il faut régénérer les clés hôte SSH manquantes, puis recréer le répertoire runtime attendu par sshd.

Voici la méthode propre pour corriger ces erreurs sans casser l’accès SSH au serveur.

Kinsta: Premium Managed WordPress hosting

Comprendre les deux erreurs

Dans l’exemple ci-dessus, SSH signale deux problèmes différents :

Could not load host key: /etc/ssh/ssh_host_ed25519_key : une clé hôte SSH manque sur le serveur ;
Missing privilege separation directory: /run/sshd : le répertoire temporaire utilisé par le daemon SSH n’existe pas.

Les deux problèmes peuvent apparaître après une installation minimale, une image système incomplète, un conteneur, un chroot, une restauration de serveur, ou une mise à jour qui a laissé SSH dans un état bancal.

La bonne nouvelle : dans la plupart des cas, deux commandes suffisent pour remettre SSH d’aplomb. Le tout, c’est de les lancer proprement.

Précaution avant de toucher à SSH

Si vous êtes connecté à distance, gardez votre session SSH actuelle ouverte pendant toute l’opération.

Ouvrez une deuxième session pour tester les changements, mais ne fermez pas la première tant que vous n’avez pas confirmé que SSH redémarre correctement. Une session SSH ouverte, c’est votre corde de rappel. Et sur un serveur en production, on aime beaucoup les cordes de rappel.

Commencez par identifier le service SSH utilisé par votre distribution :

systemctl status ssh --no-pager

Sur Debian et Ubuntu, le service s’appelle généralement ssh. Sur d’autres distributions, il peut s’appeler sshd.

Corriger l’erreur “Could not load host key”

L’erreur Could not load host key apparaît lorsque certaines clés hôte SSH n’existent pas dans /etc/ssh/.

Ces clés ne sont pas vos clés utilisateur. Ce sont les clés propres au serveur, utilisées pour identifier la machine auprès des clients SSH. Par exemple :

/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_ecdsa_key

Si la clé ED25519 manque, le message peut ressembler à ceci :

Could not load host key: /etc/ssh/ssh_host_ed25519_keyLangage du code : JavaScript (javascript)

Pour générer toutes les clés hôte manquantes, utilisez :

sudo ssh-keygen -A

L’option -A demande à ssh-keygen de générer les clés hôte manquantes pour tous les types de clés pris en charge. Le manuel OpenSSH décrit cette option comme la génération des clés hôte non existantes avec les chemins par défaut. Voir la documentation OpenSSH de ssh-keygen.

Sur un serveur où seule la clé ED25519 manque, le retour peut être :

ssh-keygen: generating new host keys: ED25519Langage du code : JavaScript (javascript)

Vérifiez ensuite les clés présentes :

ls -l /etc/ssh/ssh_host_*_key

Les clés privées doivent appartenir à root et ne doivent pas être lisibles par tout le monde. En pratique, on attend généralement des permissions restrictives, par exemple 600.

Corriger l’erreur “Missing privilege separation directory: /run/sshd”

L’erreur Missing privilege separation directory: /run/sshd signifie que sshd attend le répertoire /run/sshd, mais que celui-ci n’existe pas au moment du test ou du démarrage.

Le répertoire /run contient des données temporaires de runtime. Il est recréé au démarrage et ne doit pas être traité comme un dossier permanent classique. Sur les systèmes avec systemd, le service SSH peut normalement créer son répertoire runtime via la directive RuntimeDirectory=sshd. Cette directive crée le dossier sous /run au lancement du service. Voir la documentation systemd sur RuntimeDirectory.

Pour corriger rapidement l’erreur, créez le répertoire avec les bons droits :

sudo install -d -m 0755 -o root -g root /run/sshd

Cette commande est préférable à un simple mkdir -p, car elle crée le dossier et fixe immédiatement le propriétaire ainsi que les permissions.

Si vous voulez faire au plus court, cette version fonctionne aussi :

sudo mkdir -p /run/sshd
sudo chmod 0755 /run/sshd
sudo chown root:root /run/sshd

Ensuite, relancez le test :

sudo sshd -t

Si la commande ne renvoie rien, la configuration SSH est valide.

Redémarrer ou recharger SSH

Une fois les clés générées et /run/sshd recréé, vous pouvez redémarrer le service SSH.

Sur Debian et Ubuntu :

sudo systemctl restart ssh

Sur certaines distributions, utilisez plutôt :

sudo systemctl restart sshd

Vérifiez ensuite l’état du service :

sudo systemctl status ssh --no-pager

Ou, selon la distribution :

sudo systemctl status sshd --no-pager

Puis ouvrez une nouvelle connexion depuis votre poste local :

ssh utilisateur@adresse-du-serveurLangage du code : CSS (css)

Ne fermez l’ancienne session qu’après avoir confirmé que la nouvelle connexion fonctionne.

Solution rapide en trois commandes

Pour un serveur Debian ou Ubuntu, la correction rapide ressemble donc à ceci :

sudo ssh-keygen -A
sudo install -d -m 0755 -o root -g root /run/sshd
sudo sshd -t

Si le test ne retourne aucune erreur, redémarrez SSH :

sudo systemctl restart ssh

Puis testez une nouvelle connexion.

Pourquoi /run/sshd disparaît-il ?

Le répertoire /run/sshd se trouve dans /run, qui est un espace temporaire recréé à chaque démarrage. Il est donc normal que son contenu ne soit pas persistant.

Le plus lu : Installer Apache, PHP et MySQL sous Ubuntu : stack LAMP complète

Sur une installation standard, systemd recrée le dossier au démarrage du service SSH. Si ce n’est pas le cas, plusieurs causes sont possibles :

service SSH lancé manuellement hors systemd ;
conteneur LXC ou Docker minimal ;
image système incomplète ;
paquet OpenSSH mal configuré ;
fichier de service systemd modifié ;
répertoire /run ou permissions système anormales ;
chroot ou environnement de rescue incomplet.

Si l’erreur revient à chaque démarrage, il ne faut pas seulement recréer le dossier à la main. Il faut vérifier pourquoi le service ne le crée pas lui-même.

Vérifier le fichier systemd du service SSH

Sur un système géré par systemd, inspectez la définition du service SSH :

systemctl cat ssh

Ou, selon votre distribution :

systemctl cat sshd

Cherchez une directive de ce type :

RuntimeDirectory=sshd

Avec cette directive, systemd crée normalement /run/sshd au démarrage du service. Plusieurs discussions techniques autour de cette erreur rappellent d’ailleurs que RuntimeDirectory=sshd doit produire un répertoire /run/sshd lorsque le service est lancé par systemd. Voir cette analyse sur TurnKey Linux.

Si le service n’a pas cette directive, ou si un override l’a supprimée, listez les surcharges systemd :

systemctl show ssh -p FragmentPath -p DropInPaths
systemctl show sshd -p FragmentPath -p DropInPaths

Selon votre distribution, l’une des deux commandes peut ne rien renvoyer d’utile. C’est normal : le nom du service varie.

Cas particulier : conteneurs Docker, LXC et environnements minimaux

L’erreur Missing privilege separation directory: /run/sshd apparaît souvent dans les conteneurs ou environnements minimaux.

Dans un conteneur Docker, par exemple, sshd peut être lancé directement sans systemd. Dans ce cas, personne ne crée automatiquement le répertoire /run/sshd. Il faut donc le créer dans l’image ou dans le script d’entrée.

Dans un Dockerfile, on peut ajouter :

RUN mkdir -p /run/sshd && chmod 0755 /run/sshd

Ou mieux :

RUN install -d -m 0755 -o root -g root /run/sshd

Dans un conteneur LXC, vérifiez plutôt le comportement du service systemd, les permissions de /run, et les mises à jour récentes d’OpenSSH. Plusieurs rapports récents mentionnent encore cette erreur dans des contextes LXC ou Proxmox après mise à jour. Voir un exemple sur le forum Proxmox.

Vérifier la configuration SSH effective

Après correction, vous pouvez afficher la configuration effective de sshd avec :

sudo sshd -T | head

La commande sshd -T affiche la configuration complète après interprétation des valeurs par défaut et des fichiers inclus. Elle est pratique pour comprendre ce que SSH applique réellement.

Pour inspecter les clés hôte déclarées :

sudo sshd -T | grep '^hostkey 'Langage du code : JavaScript (javascript)

Vous verrez par exemple :

hostkey /etc/ssh/ssh_host_rsa_key
hostkey /etc/ssh/ssh_host_ecdsa_key
hostkey /etc/ssh/ssh_host_ed25519_key

Si une clé déclarée manque sur le disque, ssh-keygen -A permet généralement de la recréer.

Attention aux alertes “REMOTE HOST IDENTIFICATION HAS CHANGED”

Si vous régénérez les clés hôte d’un serveur déjà utilisé, les clients SSH peuvent afficher une alerte lors de la prochaine connexion :

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!Langage du code : HTTP (http)

C’est normal si les anciennes clés hôte ont réellement changé. Mais c’est aussi le même message que celui utilisé pour signaler une possible attaque de type man-in-the-middle.

Le plus lu : MySQL : gérer, purger ou désactiver les binary logs

Avant de supprimer l’ancienne entrée de known_hosts, vérifiez que vous êtes bien sur le bon serveur, puis comparez l’empreinte de la nouvelle clé :

sudo ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

Côté client, vous pourrez ensuite supprimer l’ancienne entrée si le changement est attendu :

ssh-keygen -R adresse-du-serveur

Évitez de banaliser ce message. Pour une fois qu’un logiciel vous crie dessus pour une bonne raison, autant l’écouter deux minutes.

Ancienne commande service ssh restart ou systemctl ?

L’ancienne commande fonctionne encore souvent :

sudo service ssh restart

Mais sur les systèmes Ubuntu et Debian modernes, je préfère utiliser systemctl :

sudo systemctl restart ssh

C’est plus explicite, mieux intégré à systemd, et plus pratique pour vérifier l’état du service ensuite :

sudo systemctl status ssh --no-pager

Sur une distribution non Debian, adaptez simplement le nom du service : sshd au lieu de ssh.

Résumé de la correction

Pour corriger les deux erreurs :

Could not load host key: /etc/ssh/ssh_host_ed25519_key
Missing privilege separation directory: /run/sshdLangage du code : JavaScript (javascript)

lancez :

sudo ssh-keygen -A
sudo install -d -m 0755 -o root -g root /run/sshd
sudo sshd -t
sudo systemctl restart ssh

Puis vérifiez :

sudo systemctl status ssh --no-pager

Et testez une nouvelle connexion depuis votre poste local.

Conclusion

L’erreur Missing privilege separation directory: /run/sshd indique simplement que le répertoire runtime attendu par OpenSSH n’existe pas au moment du lancement ou du test de configuration.

L’erreur Could not load host key, elle, signale qu’une clé hôte SSH manque dans /etc/ssh/.

Sur un serveur Ubuntu ou Debian, la correction se résume souvent à générer les clés hôte manquantes avec ssh-keygen -A, recréer /run/sshd avec les bons droits, valider avec sshd -t, puis redémarrer le service SSH.

Simple, rapide, efficace. Le genre de panne qui fait peur deux minutes, puis qui se règle en quatre lignes.