SSH connection works for root but not user; fails after "Trying private key"

Bret Hess

3/9/23, 7:40 PM

I'm setting up password-free ssh connection to a debian remote server. I've generated a key on my local machine and placed the key in both /root/.ssh/authorized_keys and /home/user/.ssh/authorized_keys. The permissions are set to 700 for .ssh and 600 for authorized_keys. The user is "root as user" and has sudo privileges.

So I can ssh in directly as root: ssh root@server. Good.

But when I try to ssh in directly as user I see:

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server.xxx [24.11.45.113] port 22.
debug1: Connection established.
...
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7p1 Debian-1
debug1: match: OpenSSH_8.7p1 Debian-1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to server.xxx:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:GALVeyDsqFCWLB/7hh6JWnqt5swCSl3VeYnt0dJ0HzE
debug1: Host 'server.xxx' is known and matches the ECDSA host key.
debug1: Found key in /home/localuser/.ssh/known_hosts:5
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected]>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: ED25519 SHA256:YcJ7U0/gHFMRFlLWWpHdMF/6mAt3gmxCML6dAQPAGDw /home/localuser/.ssh/id_ed25519
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/localuser/.ssh/id_rsa
debug1: Trying private key: /home/localuser/.ssh/id_dsa
debug1: Trying private key: /home/localuser/.ssh/id_ecdsa
debug1: Next authentication method: password
[email protected]'s password:

So it skips right to password instead of accepting the private key.

There aren't any errors in tail /var/log/auth.log, just the comment

Nov  9 12:24:04 server sudo: pam_unix(sudo:session): session opened for user root(uid=0) by user(uid=1003)

Any ideas why user (with sudo privileges) can't ssh directly in, but root can with the same key?

213

0 + 0

debian

ssh

password

Gerald Schneider

3/9/23, 8:33 PM

Who is the owner of the .ssh directory and the authorized_keys file in the user home directory?

Bret Hess

3/10/23, 11:44 PM

root is owner of .ssh directory and the authorized_keys file in the user home directory. The way that the server is set up is "user" has to sudo to create or delete anything.

Score:0

Server

Gerald Schneider

3/11/23, 5:51 AM

The permissions of the .ssh directory and the authorized_keys file are good, but the ownership isn't.

The owner must be the user that tries to login, otherwise sshd can't read those files. Run chown -R user:user ~user/.ssh and it should work.

0 + 0

Bret Hess

3/12/23, 9:54 PM

I changed the ownership to user, but it didn't help.

Gerald Schneider

3/13/23, 7:05 AM

Then please edit the out of `ls -la ~user/.ssh` into your question.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: SSH connection works for root but not user; fails after "Trying private key"

TH: การเชื่อมต่อ SSH ใช้งานได้กับรูท แต่ไม่ใช่ผู้ใช้ ล้มเหลวหลังจาก "ลองใช้รหัสส่วนตัว"

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

RU: SSH-соединение работает для root, но не для пользователя; сбой после "Попытка закрытого ключа"

VI: Kết nối SSH hoạt động cho root nhưng không hoạt động cho người dùng; không thành công sau khi "Thử khóa riêng"

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.