Conexiunea SSH funcționează pentru root, dar nu pentru utilizator; eșuează după „Încercare cheie privată”

Configurați o conexiune ssh fără parolă la un server de la distanță Debian. Am generat o cheie pe computerul meu local și am introdus cheia ambii /root/.ssh/authorized_keys și /home/user/.ssh/authorized_keys. Permisiunile sunt setate la 700 pentru .ssh și 600 pentru authorized_keys. Utilizatorul este „root ca utilizator” și are privilegii sudo.

Deci eu poate sa ssh in direct ca rădăcină: ssh root@server. Bun.

Dar când încerc să intru direct ca utilizator Înțeleg:

debug1: Citirea datelor de configurare /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config linia 19: Se aplică opțiuni pentru *
debug1: se conectează la server.xxx [24.11.45.113] portul 22.
debug1: Conexiune stabilită.
...
debug1: șir de versiune locală SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.5
debug1: versiunea protocolului la distanță 2.0, versiunea software la distanță OpenSSH_8.7p1 Debian-1
debug1: potrivire: OpenSSH_8.7p1 Debian-1 pat OpenSSH* compat 0x04000000
debug1: se autentifică la server.xxx:22 ca „utilizator”
depanare1: SSH2_MSG_KEXINIT trimis
depanare1: SSH2_MSG_KEXINIT primit
debug1: kex: algoritm: curve25519-sha256
debug1: kex: algoritm cheie gazdă: ecdsa-sha2-nistp256
debug1: kex: server->cifrare client: [email protected] MAC: <implicit> compresie: niciuna
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compresie: niciunul
debug1: aștept SSH2_MSG_KEX_ECDH_REPLY
debug1: Cheie de gazdă a serverului: ecdsa-sha2-nistp256 SHA256:GALVeyDsqFCWLB/7hh6JWnqt5swCSl3VeYnt0dJ0HzE
debug1: Gazda „server.xxx” este cunoscută și se potrivește cu cheia gazdă ECDSA.
debug1: Cheia găsită în /home/localuser/.ssh/known_hosts:5
debug1: reintroduceți cheia după 134217728 blocuri
debug1: SSH2_MSG_NEWKEYS trimis
debug1: aștept SSH2_MSG_NEWKEYS
depanare1: SSH2_MSG_NEWKEYS primit
debug1: reintroduceți cheia după 134217728 blocuri
depanare1: SSH2_MSG_EXT_INFO primit
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha256-nist ,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected]>
depanare1: SSH2_MSG_SERVICE_ACCEPT primit
debug1: Autentificări care pot continua: cheie publică, parolă
debug1: Următoarea metodă de autentificare: cheie publică
debug1: Oferă cheie publică: ED25519 SHA256:YcJ7U0/gHFMRFlLWWpHdMF/6mAt3gmxCML6dAQPAGDw /home/localuser/.ssh/id_ed25519
debug1: Autentificări care pot continua: cheie publică, parolă
debug1: Se încearcă cheia privată: /home/localuser/.ssh/id_rsa
debug1: Se încearcă cheia privată: /home/localuser/.ssh/id_dsa
debug1: Se încearcă cheia privată: /home/localuser/.ssh/id_ecdsa
debug1: Următoarea metodă de autentificare: parola
parola [email protected]: 

Deci trece direct la parolă în loc să accepte cheia privată.

Nu există erori în tail /var/log/auth.log, doar comentariul

9 noiembrie 12:24:04 server sudo: pam_unix(sudo:session): sesiune deschisă pentru utilizator root(uid=0) de către utilizator(uid=1003)

Aveți idee de ce utilizatorul (cu privilegii sudo) nu poate ssh direct, dar root poate cu aceeași cheie?

Permisiunile directorului .ssh și ale fișierului authorized_keys sunt bune, dar dreptul de proprietate nu este.

Proprietarul trebuie să fie utilizatorul care încearcă să se autentifice, altfel sshd nu poate citi acele fișiere. Alerga chown -R utilizator:utilizator ~user/.ssh și ar trebui să funcționeze.