Unable to ssh with authorized keys, password always prompted

Question

I've been through several posts here to try to correct this issue but I am being unable to do so.

A few days ago the login to the server with the authorized_keys mapped stopped working, there was no one changing the file or the folder itself, I am the only one that manipulates the server.

Following some posts in here, I tried re-creating the ssh key set and rename the old .ssh folder but it didn't work.

Another post mentioned that I had to change the permissions on .ssh to 750 and re-create the authorized_keys file again after a brand new .ssh was generated, and did not worked as well.

Linux ssh folder

Can someone assist me with this issue? I am not an advanced user.

The linux server is CentOS 7

Edit

The output of ssh -vvv in the server as requested:

$ ssh -vvv root@131.72.xxx.xxx
OpenSSH_8.2p1, OpenSSL 1.1.1e  17 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname 131.72.xxx.xxx is address
debug2: ssh_connect_direct
debug1: Connecting to 131.72.222.241 [131.72.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_rsa type 0
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_rsa-cert type -1
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_dsa type -1
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_dsa-cert type -1
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_ecdsa type -1
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_ecdsa-cert type -1
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_ecdsa_sk type -1
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_ed25519 type -1
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_ed25519-cert type -1
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_ed25519_sk type -1
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_xmss type -1
debug1: identity file /c/Users/Andre Fr\303\263es/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 131.72.xxx.xxx:22 as 'root'
debug3: hostkeys_foreach: reading file "/c/Users/Andre Fr\303\263es/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /c/Users/Andre Fr\303\263es/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys from 131.72.xxx.xxx
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,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,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,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com,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,3des-cbc,aes256-cbc,aes192-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,aes256-cbc,aes192-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,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
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,blowfish-cbc,cast128-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,blowfish-cbc,cast128-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
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
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: ecdsa-sha2-nistp256 SHA256:oDemkeTUNqSXDkAz6sx/w/978fNZR4QQsIYFfdb0BiA
debug3: hostkeys_foreach: reading file "/c/Users/Andre Fr\303\263es/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /c/Users/Andre Fr\303\263es/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys from 131.72.xxx.xxx
debug1: Host '131.72.xxx.xxx' is known and matches the ECDSA host key.
debug1: Found key in /c/Users/Andre Fr\303\263es/.ssh/known_hosts:4
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /c/Users/Andre Fr\303\263es/.ssh/id_rsa RSA SHA256:MgYlmw9i3/fmZCu8+0uIjZZu4qer+zJnKBh7epHx26w
debug1: Will attempt key: /c/Users/Andre Fr\303\263es/.ssh/id_dsa
debug1: Will attempt key: /c/Users/Andre Fr\303\263es/.ssh/id_ecdsa
debug1: Will attempt key: /c/Users/Andre Fr\303\263es/.ssh/id_ecdsa_sk
debug1: Will attempt key: /c/Users/Andre Fr\303\263es/.ssh/id_ed25519
debug1: Will attempt key: /c/Users/Andre Fr\303\263es/.ssh/id_ed25519_sk
debug1: Will attempt key: /c/Users/Andre Fr\303\263es/.ssh/id_xmss
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
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 publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /c/Users/Andre Fr\303\263es/.ssh/id_rsa RSA SHA256:MgYlmw9i3/fmZCu8+0uIjZZu4qer+zJnKBh7epHx26w
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: Trying private key: /c/Users/Andre Fr\303\263es/.ssh/id_dsa
debug3: no such identity: /c/Users/Andre Fr\303\263es/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /c/Users/Andre Fr\303\263es/.ssh/id_ecdsa
debug3: no such identity: /c/Users/Andre Fr\303\263es/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /c/Users/Andre Fr\303\263es/.ssh/id_ecdsa_sk
debug3: no such identity: /c/Users/Andre Fr\303\263es/.ssh/id_ecdsa_sk: No such file or directory
debug1: Trying private key: /c/Users/Andre Fr\303\263es/.ssh/id_ed25519
debug3: no such identity: /c/Users/Andre Fr\303\263es/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /c/Users/Andre Fr\303\263es/.ssh/id_ed25519_sk
debug3: no such identity: /c/Users/Andre Fr\303\263es/.ssh/id_ed25519_sk: No such file or directory
debug1: Trying private key: /c/Users/Andre Fr\303\263es/.ssh/id_xmss
debug3: no such identity: /c/Users/Andre Fr\303\263es/.ssh/id_xmss: No such file or directory
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@131.72.xxx.xxx's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to 131.72.xxx.xxx ([131.72.xxx.xxx]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 4
debug1: Remote: Ignored authorized keys: bad ownership or modes for directory /root
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0

That is the log from the client. You need to check the log from the server. — Michael Hampton, Nov 03 '20 at 21:31

score 1 · Answer 1 · answered Nov 03 '20 at 12:07

1

Check /etc/ssh/sshd_config it has a Authentication section. Check that PubkeyAuthentication isn't set to no. The configuration to the path to the AuthorizedKeysFile is also set there. Check those settings, adjust them if necessary and restart the sshd service using systemctl restart sshd. In case the sshd_config file looks fine investigate the problem using journalctl -u sshd it will display all the messages and errors related to sshd. If there is a permission problem with the AuthorizedKeysFile it should be in there.

Edit: Check journalctl before restarting sshd to reduce the risk of completely locking yourself out of the server.

answered Nov 03 '20 at 12:07

Henrik Pingel

9,380
2
28
39

Thanks for the quick reply! The config file seems ok, https://i.ibb.co/b1fKzTK/ssh-file-1.jpg, as per the logs, there are a lot of thing there, but I don't understand what that means, most of it is "pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"" – André Fróes Nov 03 '20 at 12:16
Have you tried to connect with a non root user. Looks like that pam forbids that. You could check if PermitRootLogin is set to yes in the sshd_config. But I would recommend not to use root user to ssh on a server. Use an unprivileged user to ssh on the server and sudo to gain root privileges. – Henrik Pingel Nov 03 '20 at 12:18
I just did, worked normally with the non root user as well – André Fróes Nov 03 '20 at 12:36
The PermitRootLogin is commented in the file, but in the comments, it is set to yes – André Fróes Nov 03 '20 at 12:38
If it is commented out it means that it defaults to prohibit-password. Which means that something with your /root/.ssh/authorized_keys could be wrong. – Henrik Pingel Nov 03 '20 at 12:47
How can I verify if there is something wrong? I've done this same procedure with the other 2 machines, which was basically **vi authorized_keys** in the **.ssh** folder and paste the **id_rsa.pub** from the machine that I want to have direct access – André Fróes Nov 03 '20 at 13:24
double check that file. Happened to me more than once that I accidentally missed a part of the pub key. – Henrik Pingel Nov 03 '20 at 15:45
Please add the output of `ssh -vvv` to the question. – Tero Kilkanen Nov 03 '20 at 18:53
I triple checked the id_rsa.pub and it was correct. Since I generated the id again, I had to replace it in the other servers and it was ok, worked normally. Still no clue why only in this server the issue is happening. – André Fróes Nov 03 '20 at 19:01
@TeroKilkanen, I've just added the output to the question as requested – André Fróes Nov 03 '20 at 19:04
Sorry, I meant `ssh -vvv user@hostname`, where user is the other system username and hostname is the server address. This will show detailed information about the connection process. – Tero Kilkanen Nov 03 '20 at 19:07
Done, the output is in the question – André Fróes Nov 03 '20 at 20:04
`Ignored authorized keys: bad ownership or modes for directory /root` check the permissions for `/root/.ssh`. It should be 600 (u=rw). – Henrik Pingel Nov 03 '20 at 20:53
I done a "chmod -R 600 ~/.ssh/" but I am still unable to access straight to the server. Should I change it to the entire /root folder? – André Fróes Nov 04 '20 at 01:02

score 1 · Accepted Answer · answered Nov 04 '20 at 09:12

1

You have wrong ownership on /root, in your first image (Linux ssh folder) when you show ls -lah ./ssh it is seen that ../ has ownership suporte.sutic.

chown -R root.root /root

chmod 0550 /root

chmod 0700 /root/.ssh

chmod 0600 /root/.ssh/authorized_keys

answered Nov 04 '20 at 09:12

zorry

136
2

This was it in the end, thank you all for your support! I was really lost here – André Fróes Nov 04 '20 at 11:59

Unable to ssh with authorized keys, password always prompted

Edit

2 Answers2