L'authentification par clé SSH échoue

J'essaye de ssh dans un serveur CentOS sur lequel je n'ai aucun contrôle .. l'administrateur a ajouté ma clé publique au serveur et insiste sur le fait que la faute réside en moi mais je ne peux pas comprendre ce qui ne va pas.

Config .ssh:

tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa

Autorisation sur mes fichiers clés:

tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim  746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub

Journal de connexion dont je ne peux pas comprendre le sens:

tim@tim-UX31A:~$ ssh -vvv root@10.0.12.28
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: 
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Cela résout généralement la plupart des problèmes d'autorisation de clé autorisés SSH côté serveur , en supposant que quelqu'un n'a pas apporté de modifications supplémentaires aux autorisations.

sudo chown yourusername:yourusername /home/yourusername/ -R
sudo chmod o-rwx /home/yourusername/ -R

Si votre administrateur a créé le fichier .ssh / ou .ssh / authorized_keys en tant que root (ce qui est le plus souvent le cas), alors le fichier appartenant à un autre utilisateur (même si root!) N'est pas autorisé.

Userify (clause de non-responsabilité: co-fondateur) procède automatiquement exactement de la même manière. Https://github.com/userify/shim/blob/master/shim.py#L285

J'ai eu exactement le même problème sur deux serveurs: un Linux exécutant un tronçon Debian et sur un NAS (Synology DS715)

il s'est avéré que dans les deux cas, les autorisations du répertoire personnel sur le serveur étaient incorrectes

l'auth.log sur le serveur a été très utile

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

sous Linux, le bit d'écriture / groupe était activé (drwxrwxr - x), j'ai donc dû supprimer au moins le groupe d'écriture (chmod gw ~ /), puis cela a fonctionné

sur la Synology, pour une raison quelconque, il y avait un morceau collant

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

Je devais le changer avec

chmod -t ~/

et je pourrais alors me connecter sans mot de passe

Lorsque vous utilisez CentOS 7, et je suis convaincu qu'il s'applique également aux autres systèmes d'exploitation Linux utilisant sshd. Avec l'accès root, vous pouvez en savoir plus sur les raisons de l'échec de l'authentification. Pour faire ça:

1. Activez la journalisation pour sshd: vi /etc/ssh/sshd_config
2. Sous enregistrement décommentation:

SyslogFacility AUTH LogLevel INFO

1. Changer LogLevel INFO en LogLevel DEBUG
2. Sauvegarder et quitter
3. Redémarrez sshd systemctl restart sshd
4. Regardez le fichier des messages tail -l /var/log/messages
5. En utilisant un autre terminal, essayez de vous connecter avec ssh
6. Tenter de se connecter avec ssh
7. Consultez le journal d'authentification pour la cause exacte

Par exemple, je rencontrais certains des mêmes problèmes que ceux mentionnés ci-dessus.

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

En utilisant ces étapes, j'ai pu confirmer que le problème était des autorisations sur le fichier authorized_keys. En définissant chmod sur 644 sur le fichier de clés autorisées de mon utilisateur, le problème a été résolu.

Il semble que les autorisations sur votre .sshdossier n'aient pas été copiées + collées correctement. Pourriez-vous l'ajouter à nouveau?

Si le mode strict est activé, nous devons nous assurer que .sshles autorisations sont correctes:

• .ssh/ devrait avoir des perms 0700/rwx------
• .ssh/*.pub les fichiers doivent être 644/rw-r--r--
• .ssh/* (autres fichiers en .ssh) 0600/rw-------

À quoi les choses vous ressemblent-elles en termes de permission?

Juste au cas où quelqu'un tomberait sur cette réponse - aucune des recommandations n'a fonctionné dans mon scénario. Au final, le problème était que j'avais créé un compte sans mot de passe. Une fois que j'ai défini le mot de passe en utilisant usermod -p "my password" usernamepuis déverrouillé de force le compte, usermod -U usernametout était pêche.

J'ai eu un problème similaire , où la connexion ssh essaie la clé ~/.ssh/id_rsaavant de s'arrêter de façon inattendue:

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

Dans mon cas, cela était dû à un ancien fichier de clé publique qui traînait dans le .sshrépertoire:

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

Le déplacement / la suppression id_rsa.pubdu .sshrépertoire a résolu le problème.

D'après ce que je comprends: lorsqu'une clé publique est présente côté client, SSH 1st valide la clé privée par rapport à celle-ci. S'il échoue, il n'essaiera pas d'utiliser la clé privée pour se connecter à distance.

J'ai envoyé un e-mail à la liste de diffusion openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .

Nous avons rencontré ce problème. Les autorisations et la propriété des fichiers .ssh étaient toutes correctes. Dans / var / log / messages, nous avons trouvé:

Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82

SO, la solution pour les développeurs vm où nous ne nous soucions pas de la sécurité est de désactiver selinux. Modifiez / etc / sysconfig / selinux et changez SELINUX = désactivé et redémarrez.

Juste au cas où cela sauverait aussi quelqu'un. J'essayais de copier une clé de ma machine Ubuntu 18.04 sur 2 serveurs CentOS 7. J'avais l'habitude ssh-copy-idde les transférer. L'un a fonctionné, l'autre non. J'ai donc parcouru toutes les autorisations de débogage et je n'ai rien trouvé. J'ai finalement récupéré le fichier /etc/ssh/sshd_configsur les deux serveurs et je les ai parcourus ligne par ligne. Finalement, je l'ai trouvé, probablement quelque chose que quelqu'un a modifié bien avant de commencer.

Une lecture: AuthorizedKeysFile .ssh/authorized_keys

Et une autre lecture:, AuthorizedKeysFile ~/.ssh/authorized_keysqui était sur le serveur qui n'acceptait pas mes clés. Évidemment, en regardant entre les deux fichiers et en notant le commentaire qui indique que les modèles de recherche par défaut n'incluent pas le début, ~/je l'ai supprimé et redémarré sshd. Problème résolu.

A également rencontré ce problème. setroubleshoot ne semble pas fonctionner dans mon environnement, il n'y a donc pas d'enregistrement de ce type dans / var / log / messages. Désactiver SELinux n'était pas une option pour moi, donc je l'ai fait

restorecon -Rv ~/.ssh

Après cette connexion, la clé rsa a bien fonctionné.

La raison dans mon cas était une option définie AuthorizedKeysFiledans le fichier /etc/ssh/sshd_config. Il était défini sur le /home/webmaster/.ssh/authorized_keysrépertoire personnel d'un autre utilisateur ( ), donc l'utilisateur auquel j'essayais de me connecter n'avait pas accès à ce fichier / répertoire.

Après l'avoir changé et redémarré ssh-server ( service ssh restart), tout est revenu à la normale. Je peux me connecter avec ma clé privée maintenant.

Dans notre cas, les problèmes étaient liés au fait que nos règles de pare-feu et de NAT n'étaient pas correctement configurées.

le port 22, était dirigé vers le serveur incorrect où nos clés et notre utilisateur n'étaient pas reconnus.

Si quelqu'un arrive à ce point. tcpdump et telnet peuvent être vos amis

[aaron@aaron-pc ~]$ telnet someserver 22
Trying 1.1.1.1...
Connected to someserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1
^]
telnet> 

[aaron@aaron-pc ~]$ telnet someotherserver 22
Trying 1.1.1.2...
Connected to someotherserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
^]

Vous remarquerez que ces deux serveurs ont des versions openssh différentes. Cela m'a aidé à repérer le problème assez rapidement. Si vos hôtes utilisent les mêmes versions ssh, vous devrez essayer de faire une trace compressée sur la destination pour voir si le trafic arrive réellement à la destination.

Ssh peut générer beaucoup de trafic, ce qui rend tcpdump difficile à trouver ce que vous recherchez.

Cela m'a aidé

 tcpdump -i any  "not host [mylocalip] and not localhost and not ip and not arp"

Essayez de telnet à partir d'un 3 serveur différent et non de votre ordinateur actuel @ [mylocalip]. Vous voulez voir quel trafic atteint réellement votre serveur.

Un journal des erreurs côté client se terminant comme ceci:

Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@x.x.x.x's password:

peut être provoqué par une restriction côté serveur (distante) sur la connexion root lorsque le fichier de configuration sshd contient:

PermitRootLogin: no

La suggestion de JonCav pour activer la journalisation a été utile pour déboguer un tel problème. Bien que le débogage côté client ait été remarquablement inutile, le placement des éléments suivants dans le fichier sshd_config du serveur sshd :

SyslogFacility AUTH
LogLevel DEBUG

a fini par produire des messages de journal utiles:

Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...

Dans le cas où seule la connexion root échoue et à condition que l'utilisation de l'authentification par clé uniquement pour la connexion root soit autorisée par votre politique de sécurité, une modification du fichier sshd_config peut aider:

 PermitRootLogin without-password

Votre kilométrage peut varier, bien que cela aide souvent, une autre configuration peut toujours interférer selon un commentaire trouvé dans certains fichiers sshd_config :

# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".

Même si vous ne pouvez pas facilement modifier la configuration du serveur distant pour déboguer de cette manière, on peut éprouver la configuration côté client dans une certaine mesure en utilisant les mêmes fichiers d'identité pour ssh vers un compte non root sur le même serveur distant.

Je peux voir pourquoi la sécurité peut déranger les gens. J'ai juste eu lessh won't use my key nouveau problème. Je l'ai résolu en me connectant au serveur distant et en exécutant

/usr/sbin/sshd -sDp 23456

puis à partir de mon bureau (en essayant de ssh vers le serveur)

ssh -vvvv server -p 23456

Sur le serveur, j'ai Authentication refused: bad ownership or modes for directory /

Un nouveau sysadmin avait gâché la permission et la propriété, que j'ai corrigée avec:

chmod 0755 / ; chown root:root /

(Je suis habitué à avoir besoin chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubmais sshd vérifiant / trouvant les autorisations root est un nouveau pour moi.) Maintenant, je vais vérifier un rootkit, puis essuyer et réinstaller de toute façon.

Dans mon cas, les problèmes étaient liés à l'exécution incorrecte du shell.

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

Fichier / etc / passwd modifié pour cet utilisateur

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....

J'ai eu ce problème sur CentOS 7. Je suis un utilisateur Linux régulier basé sur Debian, j'étais donc un poisson hors de l'eau. J'ai remarqué que dans certains serveurs, cela fonctionnait et dans un seul, cela ne fonctionnait pas. L'audit.log n'a rien dit d'utile et le secure.log n'a rien donné non plus. J'ai trouvé que la seule vraie différence était quelques différences de contexte de sécurité sur les fichiers et les répertoires entre ceux qui fonctionnaient et ceux qui ne fonctionnaient pas. Obtenez la sécurité avec

sudo ls -laZ <user-home>/.ssh

du répertoire (je suppose que beaucoup de valeurs par défaut sur sshd_config).

Vous devriez en voir ssh_home_tetuser_home_t attributs . Si vous ne le faites pas, utilisez la chconcommande pour ajouter les attributs manquants.

Par exemple

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

Dans mon cas, je soupçonne que l'utilisateur a été créé de manière non standard. Sa maison était un répertoire/var/lib .

Plus d'informations sur: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/