Corriger l'erreur SSH « Permission denied (publickey) »

La tentative de connexion s'interrompt au bout d'une seconde, aucune demande de mot de passe n'apparaît, juste une seule ligne : Permission denied (publickey). Ce message est si désagréable parce qu'il ne révèle volontairement rien. Le serveur SSH n'indique pas à un attaquant potentiel si l'utilisateur existe, si la clé était mauvaise ou si le fichier est illisible. Mais cette même retenue s'applique aussi à vous, lorsque vous vous présentez tout à fait légitimement devant la porte.

La bonne nouvelle : les causes sont en nombre limité, elles se vérifient dans un ordre fixe, et dans la plupart des cas il s'agit tout simplement des droits sur les fichiers. Cet article passe en revue les causes par ordre de fréquence, donne pour chacune le message exact qui apparaît dans le journal et explique comment décider en trente secondes, avec ssh -vvv, si le problème se situe sur votre machine ou sur le serveur.

Ce que signifie exactement ce message

La parenthèse finale n'est pas un ornement, c'est l'information la plus importante de toute la ligne. Elle indique quelles méthodes d'authentification le serveur propose encore après la tentative échouée :

Permission denied (publickey).
Permission denied (publickey,password).
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Si elle ne contient que publickey, l'authentification par mot de passe est désactivée sur le serveur. Si password figure dans la liste, une connexion par mot de passe aurait été possible sur le principe, elle n'a simplement pas été tentée ou a échoué elle aussi. La variante avec gssapi est typique d'AlmaLinux, de Rocky Linux et de RHEL, où la prise en charge de Kerberos est compilée dans le binaire.

Il faut bien distinguer ce message de ceux qui lui ressemblent, mais décrivent un tout autre problème :

• Permission denied, please try again. sans parenthèse signale un mot de passe erroné, pas un problème de clé.
• Host key verification failed. concerne la clé du serveur enregistrée dans votre known_hosts, pas votre propre clé.
• Received disconnect from 203.0.113.7 port 22:2: Too many authentication failures signifie que votre agent a proposé trop de clés à la suite et que le serveur a coupé au bout de MaxAuthTries.
• Connection refused ou un timeout relèvent du réseau ou du pare-feu. Si vous venez de toucher à un pare-feu UFW ou à Fail2ban, commencez par là.

La bifurcation : bien lire ssh -vvv

Avant de modifier quoi que ce soit, faites-vous montrer le déroulement. Les trois v sont volontaires, avec un seul v il manque les lignes décisives :

ssh -vvv deploy@203.0.113.7

La sortie est longue, mais vous ne cherchez que quatre endroits. Premièrement, le nom d'utilisateur réellement employé pour la connexion :

debug1: Authenticating to 203.0.113.7:22 as 'deploy'

Deuxièmement, quelles clés le client envisage, et troisièmement, laquelle il envoie vraiment :

debug1: Will attempt key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk... agent
debug1: Offering public key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

Et quatrièmement, le message de réussite, justement absent en cas d'échec :

debug1: Server accepts key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk...
debug1: Authenticated to 203.0.113.7 ([203.0.113.7]:22) using "publickey".

De là découle la bifurcation qui vous épargne la moitié du diagnostic :

• Aucune ligne Offering public key n'apparaît avec votre clé. Le problème se situe alors sur votre machine, la clé n'a jamais été envoyée. Passez à la cause 3.
• La ligne Offering public key apparaît, puis à nouveau Authentications that can continue. Le serveur a donc vu votre clé et l'a refusée. Ce sont les causes 1, 2, 4, 5 et 6, toutes côté serveur.
• La ligne send_pubkey_test: no mutual signature algorithm apparaît. Le type de clé est alors en cause, passez à la cause 7.

Deux autres lignes de la sortie de débogage méritent un coup d'œil. debug3: no such identity: /home/tom/.ssh/id_rsa: No such file or directory est inoffensive, le client essaie simplement tous les noms par défaut. En revanche, Permissions 0644 for '/home/tom/.ssh/id_ed25519' are too open. est un vrai indice, votre clé privée est alors ignorée.

Côté serveur : sshd -T et les journaux

ssh -vvv ne montre que le point de vue du client. La raison du refus se trouve uniquement dans le journal du serveur. Si vous avez encore une session ouverte ou si vous pouvez entrer par la console de l'espace client, commencez par regarder là.

Sur Debian et Ubuntu, le service s'appelle ssh, sur AlmaLinux, Rocky Linux et RHEL il s'appelle sshd. C'est un piège classique quand on copie des commandes :

journalctl -u ssh -n 50 --no-pager      # Debian, Ubuntu
journalctl -u sshd -n 50 --no-pager     # AlmaLinux, Rocky, RHEL

Le fichier texte classique n'existe plus partout. Ubuntu 22.04 et 24.04 conservent /var/log/auth.log dans l'installation serveur, car rsyslog y est fourni d'office. Debian 12 et Debian 13 n'installent plus rsyslog dans une installation minimale, le fichier n'existe donc tout simplement pas et tout atterrit dans le journal systemd. Dans la famille Red Hat, le fichier s'appelle /var/log/secure. Si vous voulez récupérer le fichier texte sur Debian, installez rsyslog, sur Debian et Ubuntu avec apt-get install -y rsyslog, dans la famille Red Hat avec dnf install -y rsyslog.

La deuxième commande côté serveur est encore plus importante, car elle affiche la configuration réellement appliquée et résout au passage tous les fichiers inclus :

sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|strictmodes|permitrootlogin'

Si la commande, au lieu d'une configuration, répond uniquement Missing privilege separation directory: /run/sshd sans afficher la moindre ligne, c'est qu'il manque simplement un répertoire d'exécution. Cela arrive sur Debian 11, Debian 12, Ubuntu 22.04 et Ubuntu 24.04 juste après l'installation du paquet, tant que le service n'a jamais démarré, ainsi que dans les conteneurs (containers). En fonctionnement normal, l'unité systemd crée elle-même ce répertoire via RuntimeDirectory=sshd. Si le message apparaît, un mkdir -p /run/sshd préalable suffit, après quoi sshd -T renvoie proprement permitrootlogin, pubkeyauthentication yes, strictmodes yes et authorizedkeysfile. Debian 13 avec OpenSSH 10 et toute la famille Red Hat ne connaissent plus cette limitation. Attention, le message se perd dans un pipe : sshd -T | grep ... n'affiche alors qu'une sortie vide et le véritable code de retour 255 disparaît dans le grep.

Et si vous voulez vraiment voir ce que pense le serveur sans toucher au service en cours d'exécution, lancez une seconde instance en mode débogage sur un port libre. Elle s'arrête d'elle-même après une connexion et ne peut pas vous mettre à la porte.

/usr/sbin/sshd -ddd -p 2222

Depuis votre machine, lancez ensuite ssh -p 2222 deploy@203.0.113.7, et le refus s'affiche en clair dans le terminal du serveur. Le port doit évidemment être ouvert dans le pare-feu.

Cause 1 : droits et propriétaire, le cas de loin le plus fréquent

OpenSSH active l'option StrictModes yes par défaut. Le serveur refuse de lire une clé dans un fichier sur lequel quelqu'un d'autre que l'utilisateur lui-même pourrait écrire. Ce n'est pas une brimade, cela empêche un autre utilisateur d'inscrire tout simplement sa propre clé dans votre authorized_keys.

L'état attendu est défini de façon stricte :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 750 ~
chown -R "$(id -un):$(id -gn)" ~/.ssh

Une seule ligne permet de le vérifier :

stat -c "%a %U %G %n" ~ ~/.ssh ~/.ssh/authorized_keys

On attend 750 ou 700 pour le répertoire personnel, 700 pour .ssh et 600 pour authorized_keys, ainsi que votre propre nom d'utilisateur sur les trois lignes. Le point décisif : le répertoire personnel ne doit pas être accessible en écriture au groupe ni aux autres, 770 ou 777 suffisent donc déjà à faire échouer la connexion.

Un chiffre ne doit surtout pas être pris pour une erreur. Sur AlmaLinux, Rocky Linux et Oracle Linux, /root porte les droits 550 et non 700 comme sur Debian et Ubuntu. stat -c l'affiche correctement et c'est parfaitement normal. Pour StrictModes, seul compte le fait que le groupe et les autres n'aient pas le droit d'écriture, et 550 remplit exactement cette condition. Ajouter ici un chmod 700 /root ne répare pas la connexion, cela ne fait que masquer davantage la cause réelle.

Le journal du serveur est alors très explicite :

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh
Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys
error: Could not open authorized keys '/home/deploy/.ssh/authorized_keys': Permission denied

Deux détails que les autres tutoriels passent volontiers sous silence. D'abord le propriétaire : si vous avez créé le fichier avec sudo nano ~/.ssh/authorized_keys, il appartient à root et non à l'utilisateur, et la connexion échoue malgré des droits 600 parfaits. Ensuite, sshd contrôle tout le chemin en remontant. Si le répertoire personnel ne se trouve pas sous /home mais par exemple sous /srv/clients/deploy, alors /srv et /srv/clients doivent eux aussi appartenir à root ou à l'utilisateur et ne pas être accessibles en écriture au groupe ni aux autres.

Cause 2 : le mauvais nom d'utilisateur

Un utilisateur qui n'existe pas produit exactement le même message qu'une mauvaise clé, car le serveur ne dévoile délibérément pas lequel des deux cas s'applique. Dans le journal, la différence saute aux yeux :

Invalid user deply from 203.0.113.7 port 51234

La cause la plus fréquente est que la clé se trouve dans /root/.ssh/authorized_keys alors que vous vous connectez avec un utilisateur normal, ou l'inverse. Sur les images cloud toutes prêtes, la connexion root est souvent bloquée et un utilisateur préparé existe à la place, selon la distribution debian, ubuntu, almalinux ou rocky. Avec les images standard d'un serveur root KernelHost, vous vous connectez en revanche directement en tant que root.

Vérifiez également si votre ~/.ssh/config ne vous impose pas un autre utilisateur. La commande suivante n'établit aucune connexion, elle montre seulement quels réglages s'appliquent réellement à cette destination :

ssh -G deploy@203.0.113.7

Dans la sortie, ce sont user, hostname, port et la liste des entrées identityfile qui vous intéressent.

Cause 3 : la clé n'est même pas proposée

Si aucune ligne Offering public key avec votre clé n'apparaît dans ssh -vvv, le serveur n'a jamais eu sa chance. Quatre raisons typiques expliquent cela.

La clé porte un nom personnalisé

Automatiquement, OpenSSH n'essaie que les noms par défaut id_ed25519, id_ecdsa et id_rsa. Une clé nommée id_production n'est utilisée que si vous la désignez explicitement :

ssh -i ~/.ssh/id_production -o IdentitiesOnly=yes deploy@203.0.113.7

IdentitiesOnly=yes n'est pas un simple accessoire ici. Sans cette option, ssh propose en plus toutes les clés de l'agent, et après trop de tentatives le serveur coupe avec Too many authentication failures avant même que la bonne clé arrive à son tour.

L'agent ne contient pas la clé

ssh-add -l

Si la commande répond The agent has no identities. ou Could not open a connection to your authentication agent., chargez la clé avec ssh-add ~/.ssh/id_ed25519.

Les droits sur la clé privée

La clé privée doit être en 600, faute de quoi le client refuse de s'en servir. Sous Windows, chmod n'a aucun effet, on passe par les ACL :

icacls %USERPROFILE%\.ssh\id_ed25519 /inheritance:r /grant:r "%USERNAME%":R

Le fichier authorized_keys est abîmé

Une clé publique tient sur exactement une ligne. Lors d'un copier-coller via un éditeur, un système de tickets ou une fenêtre de chat, un saut de ligne se glisse volontiers au milieu du bloc Base64, et plus rien ne correspond. Comptez :

grep -c '^ssh-' ~/.ssh/authorized_keys
awk '{print NR": "NF" champs, type "$1}' ~/.ssh/authorized_keys

Chaque ligne doit commencer par ssh-ed25519, ssh-rsa ou ecdsa-sha2- et comporter deux à trois champs. Le nombre de lignes doit correspondre au nombre de clés. Autre grand classique, la clé privée a été collée par erreur à la place de la clé publique, ce que trahit BEGIN OPENSSH PRIVATE KEY. Et une clé au format PuTTY (.ppk) ne fonctionne pas telle quelle, il faut d'abord l'exporter au format OpenSSH.

Une comparaison d'empreintes indique si la clé privée et la clé publique vont bien ensemble :

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh-keygen -lf ~/.ssh/authorized_keys

La même valeur SHA256 doit apparaître dans les deux sorties. Pour voir à quoi ressemble une mise en place propre, lisez notre article sur la sécurisation de SSH et la connexion par clé.

Cause 4 : PubkeyAuthentication est désactivé

Plus rare, mais parfaitement identifiable. Ne vérifiez pas le fichier de configuration, vérifiez le résultat :

sshd -T | grep -i pubkeyauthentication

Un piège se cache ici, et il coûte beaucoup d'heures. Debian à partir de la version 12 et Ubuntu à partir de 22.04 placent tout en haut de /etc/ssh/sshd_config la ligne Include /etc/ssh/sshd_config.d/*.conf. Chez sshd, la règle est la suivante : pour chaque mot-clé, c'est la valeur trouvée en premier qui compte. Comme l'inclusion figure au début, la moindre broutille venue de sshd_config.d l'emporte sur le fichier principal, quoi qu'il soit écrit plus bas. Si votre modification reste sans effet, allez regarder là :

grep -rniE 'pubkeyauthentication|authorizedkeysfile|allowusers|allowgroups' /etc/ssh/

Le second point de cette catégorie est AuthorizedKeysFile. Les valeurs par défaut sont .ssh/authorized_keys et .ssh/authorized_keys2. Certains scripts de durcissement fixent le chemin sur quelque chose comme /etc/ssh/authorized_keys/%u. Votre fichier dans le répertoire personnel est ensuite totalement ignoré, sans le moindre message d'erreur. Là encore, sshd -T le montre.

Cause 5 : AllowUsers, AllowGroups et Match entrent en jeu

Ces directives écartent des groupes entiers d'utilisateurs, et ce avant même que la clé soit examinée. Voici le texte exact dans le journal :

User root from 203.0.113.7 not allowed because not listed in AllowUsers
User deploy from 203.0.113.7 not allowed because none of user's groups are listed in AllowGroups
User root from 203.0.113.7 not allowed because "PermitRootLogin no"

Retenez l'ordre de priorité : DenyUsers l'emporte sur AllowUsers, et dès que AllowUsers est défini, tous les utilisateurs non cités sont exclus. Pour AllowGroups, l'appartenance au groupe doit être correcte, ce que vous vérifiez avec id deploy.

Pour PermitRootLogin, la distinction est importante : prohibit-password autorise la connexion root avec une clé. Seul no exclut root complètement. N'attendez toutefois pas le mot prohibit-password dans la sortie de sshd -T, c'est l'ancien nom équivalent without-password qui y figure. Et la valeur par défaut est loin d'être identique partout, ce qui sème régulièrement la confusion quand on compare deux serveurs :

Sur AlmaLinux, root peut donc aussi entrer avec un mot de passe, sur les autres systèmes cités non. Si vous déplacez un service d'AlmaLinux vers Debian alors que vous vous connectiez jusque-là en root avec un mot de passe, vous tombez ensuite exactement sur Permission denied (publickey).

Si la règle se trouve dans un bloc Match, utilisez l'option qui évalue la configuration pour un cas concret :

sshd -T -C user=deploy,host=client.example.com,addr=203.0.113.7 | grep -Ei 'pubkeyauth|allowusers|permitrootlogin'

C'est le moyen le plus fiable de voir ce qui s'applique précisément à cet utilisateur depuis précisément cette adresse IP.

Cause 6 : SELinux sur AlmaLinux, Rocky et RHEL

Dans la famille Red Hat, SELinux tourne par défaut en mode Enforcing, alors qu'il ne joue aucun rôle sur Debian et Ubuntu. Le processus sshd n'a le droit de lire authorized_keys que si le fichier porte le contexte ssh_home_t. C'est le cas lorsqu'il a été créé normalement dans le répertoire personnel. Ce n'est pas le cas si vous l'avez récupéré depuis /tmp avec mv ou si vous avez créé le répertoire personnel à la main, car mv emporte l'ancien contexte avec lui.

getenforce
ls -Z ~/.ssh

L'entrée correcte se termine par ssh_home_t. Si vous y lisez user_tmp_t ou user_home_t, la cause est trouvée. La réparation :

restorecon -R -v ~/.ssh

Cette étape concerne exclusivement la famille Red Hat. Sur Debian et Ubuntu, il n'existe pas d'installation SELinux par défaut, le shell répond restorecon: command not found, et ce n'est pas une erreur, c'est simplement un cas sans objet. Mais sur AlmaLinux et Rocky Linux aussi, la commande manque dans une installation allégée, parce que le paquet correspondant n'est pas posé. Installez-le au préalable :

dnf install -y policycoreutils

Les preuves se trouvent dans le journal d'audit, où le refus est écrit en clair :

ausearch -m avc -ts recent

Si les répertoires personnels se trouvent à un emplacement inhabituel, restorecon seul ne suffit pas, car SELinux ne reconnaît pas du tout ce chemin comme un répertoire personnel. Déclarez alors l'équivalence une seule fois, puis relancez la restauration :

semanage fcontext -a -e /home /srv/clients
restorecon -R -v /srv/clients

semanage se trouve dans le paquet policycoreutils-python-utils. Ne désactivez pas SELinux pour faire fonctionner la connexion, cela règle un problème de deux commandes au prix d'une perte de sécurité sur toute la machine.

Cause 7 : serveur ancien, mauvais type de clé

Depuis OpenSSH 8.8, le client refuse les signatures RSA en SHA-1. Ubuntu 22.04 est déjà concerné et Debian 13 livre désormais OpenSSH 10. Si, depuis un système aussi récent, vous voulez atteindre un serveur très ancien qui ne connaît que l'ancien ssh-rsa, la sortie de débogage affiche :

debug1: send_pubkey_test: no mutual signature algorithm

Ce n'est pas un problème de droits, votre clé est parfaitement valable. Pour un accès ponctuel :

ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa deploy@203.0.113.7

De façon permanente, cela se place dans ~/.ssh/config sous une entrée Host, pour que cela ne concerne que ce serveur précis. Sur les clients très anciens, l'option s'appelle encore PubkeyAcceptedKeyTypes. La vraie solution consiste à mettre à jour l'ancien serveur, car à partir d'OpenSSH 7.2 il maîtrise lui aussi les variantes SHA-2, et votre clé RSA existante continue alors de fonctionner sans modification. Seul le procédé de signature change.

Le cas inverse existe également. Une clé ed25519 exige au minimum OpenSSH 6.5 des deux côtés, les tokens matériels de type ed25519-sk au minimum 8.2. Et DSA appartient au passé : depuis OpenSSH 10.0, ssh-dss a été entièrement supprimé, ces anciennes clés ne fonctionnent plus du tout face à Debian 13. Pour savoir quels types votre client connaît :

ssh -Q key

Si ssh manque complètement sur un AlmaLinux, un Rocky Linux ou un RHEL fraîchement installé, cela tient à un piège dans les noms de paquets : dnf install openssh-server n'apporte que le service, pas les outils client. Sans eux, ssh et ssh-add manquent, et donc aussi ssh -Q et ssh -G. L'installation se fait avec un s au pluriel, contrairement au paquet Debian openssh-client :

dnf install -y openssh-clients

Sur AlmaLinux, Rocky et RHEL 9, un second niveau s'ajoute. Des politiques cryptographiques valables pour tout le système déterminent elles aussi ce qui est autorisé, indépendamment de la configuration de sshd :

update-crypto-policies --show

Cet outil est lui aussi purement propre à Red Hat, il n'existe pas sur Debian et Ubuntu. Et même sur Oracle Linux 9 il manque dans l'installation minimale, où dnf install -y crypto-policies-scripts le fournit, après quoi la commande renvoie DEFAULT comme prévu. Si DEFAULT s'affiche, les signatures SHA-1 sont déjà bloquées pour tout le système. update-crypto-policies --set LEGACY lève ce blocage, mais affaiblit la machine entière et ne devrait constituer, tout au plus, qu'une solution transitoire le temps d'une migration.

Si vous vous êtes coupé l'accès

Le moment dangereux n'est pas la panne elle-même, c'est la réparation de sshd_config. Trois règles rendent la perte d'accès pratiquement impossible :

1. Laissez une seconde session ouverte. Un redémarrage de sshd ne coupe pas les connexions existantes. Tant qu'un terminal reste ouvert, vous pouvez annuler n'importe quelle modification.
2. Vérifiez la syntaxe avant chaque redémarrage. sshd -t affiche le numéro de ligne en cas d'erreur et reste muet quand tout est correct. Sinon, une faute de frappe dans la configuration empêche le service de démarrer, et plus personne n'entre. Si vous obtenez à la place Missing privilege separation directory: /run/sshd, votre configuration est bonne et il ne manque que le répertoire d'exécution, voir plus haut.
3. Testez depuis la seconde session, avant de fermer la première.

Les systèmes diffèrent au moment du redémarrage. Sur Debian et Ubuntu, l'unité s'appelle ssh, dans la famille Red Hat sshd. Depuis Ubuntu 22.10 et sur Debian 13, SSH est en plus démarré par une activation de socket : la configuration de sshd_config reste valable, mais une valeur Port modifiée ne prend effet qu'une fois ssh.socket redémarré lui aussi.

sshd -t
systemctl restart ssh          # Debian, Ubuntu
systemctl restart ssh.socket   # en plus, si le port a été modifié
systemctl restart sshd         # AlmaLinux, Rocky, RHEL

Si cela vous arrive quand même, il vous faut un chemin qui contourne SSH. Sur un serveur root KernelHost, vous ouvrez la console VNC dans l'espace client et vous vous y connectez avec le mot de passe root, sans aucun service réseau. Si cela ne suffit pas, par exemple parce que sshd ne démarre plus du tout, le système de secours (rescue) prend le relais : vous démarrez dans un environnement d'urgence, vous montez le système de fichiers de la machine et vous corrigez authorized_keys et les droits directement sur le disque. Pensez à vérifier les propriétaires après le montage, car dans le système de secours vous êtes root et vous créez sinon des fichiers avec le mauvais propriétaire.

Comment savoir que cela fonctionne vraiment

Qu'une connexion aboutisse ne signifie pas encore qu'elle est passée par la clé. Tant que l'authentification par mot de passe est active, le serveur peut vous y ramener en silence. Le test honnête exclut toute autre méthode :

ssh -o BatchMode=yes -o PreferredAuthentications=publickey deploy@203.0.113.7 'id -un; hostname'

BatchMode=yes supprime toute question interactive. Si votre nom d'utilisateur et le nom d'hôte reviennent et que echo $? renvoie ensuite un 0, seule la clé a travaillé.

La deuxième preuve figure dans le journal du serveur, qui nomme même l'empreinte de la clé utilisée :

Accepted publickey for deploy from 203.0.113.7 port 51234 ssh2: ED25519 SHA256:8Qk...

Comparez cette valeur SHA256 avec la sortie de ssh-keygen -lf ~/.ssh/id_ed25519.pub. Si les deux concordent, vous savez non seulement que la connexion fonctionne, mais aussi quelle clé a servi. C'est important lorsque plusieurs clés sont en jeu et que vous voulez en retirer une.

L'ordre dans lequel procéder

Si vous n'avez pas le temps pour la théorie, déroulez cette liste de haut en bas. Elle est triée par fréquence, pas par élégance.

1. Lancer ssh -vvv et déterminer si Offering public key apparaît. Cela partage le problème entre client et serveur.
2. Vérifier les droits : 700 sur ~/.ssh, 600 sur authorized_keys, répertoire personnel non accessible en écriture au groupe, le tout appartenant à l'utilisateur.
3. Vérifier le nom d'utilisateur, au besoin interroger ssh -G et chercher Invalid user dans le journal.
4. Comparer les empreintes de la clé privée et d'authorized_keys, contrôler le nombre de lignes du fichier.
5. Analyser sshd -T : pubkeyauthentication, authorizedkeysfile, strictmodes, permitrootlogin.
6. Contrôler AllowUsers, AllowGroups, DenyUsers et les blocs Match, y compris le répertoire sshd_config.d.
7. Dans la famille Red Hat, ls -Z ~/.ssh et, si nécessaire, restorecon -R -v ~/.ssh.
8. Uniquement face à des serveurs très anciens : étendre l'algorithme de signature avec PubkeyAcceptedAlgorithms=+ssh-rsa.

Au plus tard à ce stade, la cause est trouvée. Si vous voulez ensuite remettre l'accès en place proprement, notre introduction à la connexion SSH et la check-list pour un nouveau serveur root sont les points de rattachement adaptés.