L'autenticazione della chiave SSH non riesce

Sto cercando di accedere a un server CentOS su cui non ho alcun controllo. L'amministratore ha aggiunto la mia chiave pubblica al server e insiste sul fatto che l'errore ricade su di me, ma non riesco a capire cosa sia sbagliato.

Config in .ssh:

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

Autorizzazione per i miei file chiave:

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

Registro delle connessioni che non riesco a capire:

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).

Questo di solito risolve la maggior parte dei problemi di autorizzazione delle chiavi autorizzati SSH sul lato server , supponendo che qualcuno non abbia apportato ulteriori modifiche alle autorizzazioni.

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

Se il tuo amministratore ha creato la directory .ssh / o .ssh / authorized_keys come root (che è più comunemente come viene realizzato), non è permesso avere il file di proprietà di un altro utente (anche se root!).

Userify (disclaimer: co-fondatore) fa automaticamente esattamente allo stesso modo .. https://github.com/userify/shim/blob/master/shim.py#L285

Ho avuto lo stesso identico problema su due server: un Linux con Debian stretch e un NAS (Synology DS715)

si è scoperto che in entrambi i casi, le autorizzazioni della home directory sul server erano errate

il file auth.log sul server è stato molto utile

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

su Linux, aveva il bit write / group su (drwxrwxr - x), quindi ho dovuto rimuovere almeno il write on group (chmod gw ~ /) e poi ha funzionato

sulla Synology, per qualsiasi motivo, c'era un po 'appiccicoso

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

Ho dovuto cambiarlo con

chmod -t ~/

e potrei quindi collegarmi senza password

Quando si utilizza CentOS 7, e sono sicuro che si applica anche ad altri sistemi operativi Linux che usano sshd. Con l'accesso root, è possibile determinare di più sul motivo per cui l'autenticazione potrebbe non riuscire. Per farlo:

1. Abilita registrazione per sshd: vi /etc/ssh/sshd_config
2. Sotto commento di registrazione:

SyslogFacility AUTH LogLevel INFO

1. Cambia LogLevel INFO in LogLevel DEBUG
2. Salva ed esci
3. Riavvia sshd systemctl restart sshd
4. Guarda il file dei messaggi tail -l /var/log/messages
5. Utilizzando un altro terminale, provare a connettersi con ssh
6. Tentativo di connettersi con ssh
7. Rivedere il registro di autenticazione per la causa esatta

Ad esempio, stavo riscontrando alcuni degli stessi problemi di cui sopra.

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

Utilizzando questi passaggi sono stato in grado di confermare che il problema riguardava le autorizzazioni sul file authorized_keys. Impostando chmod su 644 sul file di chiavi autorizzato del mio utente, il problema è stato risolto.

Sembra che le autorizzazioni per la tua .sshcartella non siano state copiate + incollate correttamente. Potresti aggiungerlo di nuovo?

Se la modalità rigorosa è abilitata, dobbiamo assicurarci di disporre .sshdelle autorizzazioni corrette per:

• .ssh/ dovrebbe avere permanenti 0700/rwx------
• .ssh/*.pub i file dovrebbero essere 644/rw-r--r--
• .ssh/* (altri file in .ssh) 0600/rw-------

In che modo le cose ti cercano in termini di autorizzazione?

Nel caso in cui qualcuno si imbattesse in questa risposta - nessuna delle raccomandazioni ha funzionato nel mio scenario. Alla fine, il problema era che avevo creato un account senza password impostata. Dopo aver impostato la password utilizzando usermod -p "my password" usernamee quindi sbloccato forzatamente l'account, usermod -U usernametutto era perfetto.

Ho avuto un problema simile , in cui la connessione ssh prova la chiave ~/.ssh/id_rsaprima di fermarsi inaspettatamente:

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

Nel mio caso, era dovuto a un vecchio file di chiave pubblica presente nella .sshdirectory:

[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

Lo spostamento / eliminazione id_rsa.pubdalla .sshdirectory ha risolto il problema.

Da quello che ho capito: quando sul lato client è presente una chiave pubblica, SSH 1st convalida la chiave privata rispetto ad essa. In caso contrario, non tenterà di utilizzare la chiave privata per connettersi in remoto.

Ho inviato un'e-mail alla mailing list di openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .

Abbiamo riscontrato questo problema. Le autorizzazioni e la proprietà sui file .ssh erano tutte corrette. In / var / log / messaggi abbiamo trovato:

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

Quindi, la soluzione per sviluppatori vm in cui non ci preoccupiamo della sicurezza è disabilitare selinux. Modifica / etc / sysconfig / selinux e cambia SELINUX = disabilitato e riavvia.

Nel caso in cui ciò salvi anche qualcuno. Stavo cercando di copiare una chiave dalla mia macchina Ubuntu 18.04 su 2 server CentOS 7. Ho usato ssh-copy-idper trasferirli. Uno ha funzionato, uno no. Quindi ho passato tutti i permessi di debug e non ho trovato nulla. Quindi alla fine ho tirato su il file /etc/ssh/sshd_configsu entrambi i server e li ho attraversati riga per riga. Alla fine l'ho trovato, probabilmente qualcosa che qualcuno ha modificato molto prima di iniziare il lavoro.

Una lettura: AuthorizedKeysFile .ssh/authorized_keys

E un altro leggi:, AuthorizedKeysFile ~/.ssh/authorized_keysche era sul server che non accettava le mie chiavi. Ovviamente guardando tra i due file e notando il commento che afferma che i modelli di ricerca predefiniti non includono i primi, l' ~/ho rimosso e riavviato sshd. Problema risolto.

Si è verificato anche questo problema. setroubleshoot non sembrava funzionare nel mio ambiente quindi non c'erano record di registro in / var / log / messages. Disabilitare SELinux non era un'opzione per me, quindi l'ho fatto

restorecon -Rv ~/.ssh

Dopo che il login con la chiave rsa ha funzionato bene.

La ragione nel mio caso è stata un'opzione impostata AuthorizedKeysFilenel file /etc/ssh/sshd_config. Era impostato sulla home /home/webmaster/.ssh/authorized_keysdirectory di un altro utente ( ), quindi l'utente a cui stavo tentando di accedere non aveva accesso a quel file / directory.

Dopo averlo modificato e riavviato ssh-server ( service ssh restart) tutto è tornato alla normalità. Ora posso accedere con la mia chiave privata.

Nel nostro caso i problemi erano legati al fatto che le nostre regole di firewall e NATing non erano configurate correttamente.

la porta 22, veniva indirizzata al server errato in cui le nostre chiavi e l'utente non venivano riconosciuti.

Se qualcuno arriva a questo punto. tcpdump e telnet possono essere tuoi amici

[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
^]

Noterai che questi due server hanno diverse versioni di openssh. Questo mi ha aiutato a individuare il problema abbastanza rapidamente. Se i tuoi host utilizzano le stesse versioni di ssh, dovrai provare a fare una traccia impacchettata sulla destinazione per vedere se il traffico sta arrivando alla destinazione.

Ssh può generare molto traffico che rende tcpdump difficile da trovare quello che stai cercando.

Questo mi ha aiutato

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

Prova a telnet da 3 server diversi, non dal tuo computer corrente @ [mylocalip]. Vuoi vedere quale traffico raggiunge effettivamente il tuo server.

Un registro errori sul lato client che termina in questo modo:

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:

può essere causato da una limitazione lato server (remota) all'accesso root quando il file di configurazione sshd contiene:

PermitRootLogin: no

Il suggerimento di JonCav di abilitare la registrazione è stato utile nel debug di un tale problema. Mentre spew di debug sul lato client era notevolmente inutile, inserendo quanto segue nel file sshd_config del server sshd :

SyslogFacility AUTH
LogLevel DEBUG

ha finito per produrre utili messaggi di registro:

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 ...

Nel caso in cui solo l' accesso alla radice non riesca, e purché l'uso della sola autenticazione basata su chiave per l'accesso alla radice sia consentito dalla politica di sicurezza, una modifica al file sshd_config può aiutare:

 PermitRootLogin without-password

Il tuo chilometraggio può variare, anche se questo spesso aiuta, alcune altre configurazioni potrebbero comunque interferire in base a un commento trovato in alcuni file sshd_config :

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

Anche se non è possibile modificare facilmente la configurazione del server remoto per eseguire il debug in questo modo, è possibile provare in una certa misura la configurazione lato client utilizzando gli stessi file di identità per ssh su un account non root sullo stesso server remoto.

Posso capire perché la sicurezza può disturbare le persone. Ho appena avuto di ssh won't use my keynuovo il problema. L'ho risolto accedendo al server remoto ed eseguendolo

/usr/sbin/sshd -sDp 23456

e poi dal mio desktop, (cercando di ssh sul server)

ssh -vvvv server -p 23456

Sul server ho Authentication refused: bad ownership or modes for directory /

Alcuni nuovi amministratori di sistema avevano incasinato l'autorizzazione e la proprietà, che ho risolto con:

chmod 0755 / ; chown root:root /

(Sono abituato ad aver bisogno chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubma sshd che controlla / trova i permessi di root è uno nuovo per me.) Ora vado a cercare un rootkit e poi pulisco e reinstallo comunque.

Nel mio caso, i problemi riguardavano l'esecutivo della shell errato.

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

File / etc / passwd modificato per quell'utente

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

Ho avuto questo problema su CentOS 7. Sono un normale utente Linux basato su Debian, quindi ero un pesce fuor d'acqua. Ho notato che in alcuni dei server ha funzionato e in uno solo non ha funzionato. Audit.log non ha detto nulla di utile e neanche secure.log ha dato nulla. Ho scoperto che l'unica vera differenza erano alcune differenze nel contesto di sicurezza su file e directory tra quelli che funzionavano e quelli che non lo facevano. Ottieni la sicurezza con

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

della directory (presumo molte impostazioni predefinite su sshd_config).

Dovresti vedere alcuni ssh_home_te user_home_tattributi. In caso contrario, utilizzare ilchcon comando per aggiungere gli attributi mancanti.

Per esempio

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"

Nel mio caso, il mio sospetto è che l'utente sia stato creato in modo non standard. La sua casa era una directory in /var/lib.

Maggiori informazioni in: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/