Fail to ssh login with public key

Question

I try to use a public key to connect to a remote server running centos7.

I generated a key by

ssh-keygen

then copy the key to the server by

ssh-copy-id [email protected]

the authorized_keys is created on the remote machine, but the ssh login still requires the password.

I try to login with triple verbose option

ssh -v [email protected]

and it give me something like:

OpenSSH_7.6p1 Ubuntu-4ubuntu0.7, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to chip02.phy.ncu.edu.tw [140.115.32.12] port 22.
debug1: Connection established.
debug1: identity file /home/longhoa/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/longhoa/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/longhoa/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/longhoa/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/longhoa/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/longhoa/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/longhoa/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/longhoa/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to chip02.phy.ncu.edu.tw:22 as 'hoa'
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:ALKc8EF9HMXaCSs/aN4wsfpFN8Bh1W9twUxOTueP5Kk
debug1: Host 'chip02.phy.ncu.edu.tw' is known and matches the ECDSA host key.
debug1: Found key in /home/longhoa/.ssh/known_hosts:1
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=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)

debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:S79m96anBkvF16Rjihe80MYbcU1fZlfPxE5686k/vn4 /home/longhoa/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/longhoa/.ssh/id_dsa
debug1: Trying private key: /home/longhoa/.ssh/id_ecdsa
debug1: Trying private key: /home/longhoa/.ssh/id_ed25519
debug1: Next authentication method: password
[email protected] password: 
debug1: Authentication succeeded (password)

I searched on google, some mentioned setting the correct permission, I followed the instruction and ended up with the key on my computer:

-rw------- 1 longhoa longhoa 1.7K 23-01-08|14:14:40 id_rsa
-rw-r--r-- 1 longhoa longhoa  399 23-01-08|14:14:40 id_rsa.pub

the permission on the remote server:

drwx------. 2 hoa zh 4.0K 23-01-08|15:10 /home/hoa/.ssh
-rw-------. 1 hoa zh  399 23-01-08|14:23 /home/hoa/.ssh/authorized_keys
dr-xr-xr-x. 29 root root  4096 22-12-27|17:26 /
drwxrwxrwx. 41 root root  4096 22-11-24|18:38 /home
drwx------. 58 hoa  zh   12288 23-01-11|00:47 /home/hoa/

There are other answer mention SELinux and debuging from the server but I don't have root access to that server, so I can't not do anything.

So how do I make it work? Thank you very much.

---

Update 1

I tried @roaima suggestion.

ssh -nvv -o NumberOfPasswordPrompts=0 [email protected] 2>&1 | grep "debug2: host key"

which returns:

debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519

I also tried id_dsa and id_ed25519, but none seems to work.

---

Update2 @roaima and @telcoM pointed out that the remote host was not set up correctly. I will update the status after I talk to the admin.

Answer 1

I think it's likely that the server administrators have correctly and sensibly disabled the default ssh-rsa host key algorithm. This means that the default use of ssh-keygen will produce a key pair that's ignored.

You can check this by running this command on the client:

ssh -nvv -o NumberOfPasswordPrompts=0 [email protected] 2>&1 | grep 'debug2: host key'

It will list the acceptable host key algorithms that are supported by both client and server. You should find that ssh-rsa has been disabled on the server for (very good) security reasons and as a result is not listed in the second line output of this command.

As an example, here is the output from my running this command against a local system here. You can see that although ssh-rsa is listed in the first line (the client) but it is not listed on the second line (the server). The host key algorithm must be listed on both lines for it to be available:

debug2: host key algorithms: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519

In such a situation, you need to use a specific variation of ssh-keygen that uses a key type present on both client and server. Here is one that will generate an ED25519 key pair instead of the default RSA key pair.

ssh-keygen -t ed25519

References

• https://levelup.gitconnected.com/demystifying-ssh-rsa-in-openssh-deprecation-notice-22feb1b52acd
• man sshd_config

Answer 2

drwxrwxrwx. 41 root root  4096 22-11-24|18:38 /home

On the remote host, everyone has write access to /home, allowing anyone to e.g. rename or delete anyone else's home directory. That is not correct, and it will cause sshd to distrust any authorized_keys files within that sub-tree. As a result, SSH public key authentication will not work for any user that has their home directory within /home and no custom authorized_keys file located elsewhere. This affects all key types, not just RSA.

There should be no need whatsoever for regular users to write into /home: if there is some sort of centralized user account management (AD, LDAP, NIS or similar) but each system has independent user home directories, then the admin of the remote host might need to install & configure pam_mkhomedir.so to automatically create home directories with correct permissions on first login.

The sysadmin of the remote host should do a sudo chmod 755 /home or equivalent as soon as possible to set the permissions of /home to the standard drwxr-xr-x. Having /home writeable by anyone will allow users to attack each other with a number of old, well-known tricks. Vandalism by a total deletion of another user's home directory is just the simplest possibility.