ssh-copy-id succeeded, but still prompt password input

Question

1. I have ssh-copy-id root@c199 succeeded before.
2. I can login by ssh root@c199 without password prompt
3. I want to auto login by another user ufo (remote machine has this user)

4. ssh-copy-id ufo@c199 ask me enter password,

   /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
   /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
   ufo@c199's password:
   
   Number of key(s) added: 1
   
   Now try logging into the machine, with:   "ssh 'ufo@c199'"
   and check to make sure that only the key(s) you wanted were added.
   

5. But login by ssh ufo@c199 still prompt password input .

---

I try to login remote centos on msys2(on Windows) by ssh , I found there are many same lines like

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCs7RTfvn83Rxdmvgfh+F4kUlM5FzIUb9rRHaqq11xKIW1gztn/+G4tr+OWl4o6GTW2Z361hIi
ugy8DPtMATN66nTTDUYO0sSvw2BrQfDY4iIENdLpkkHO8KQVGpQE+8tDkaZfD6EQLVtl0uvDE3D77tfcnBLODXgZPQsUSlssMi+pxDbSVjjKgrP
hM1G/L9OTrEHKWDhF+ZBgY1RuLl7ZEdoATbhJaK4FFb9hNn/2CSibVfLts8HJGYQXIQRX/RBzaDZp47sKZvq302ewkkVorNY+c9mmoze6mi8Ip2
zEQOMi6S9zM/yRiD0XZrbmzYfNkoXA03WTmMR/DynVvX2nV /c/Users/xxxx/.ssh/id_rsa

in centos's /home/ufo/.ssh/authorized_keys ,

I have changed .ssh user's folder permissions to 700 and authorized_keys file to 644 .

Same ssh key, ssh root@c199 promptless login , but ssh ufo@c199 prompt password input ..

---

UPDATE

ssh ufo@c199 -vv output:

....
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:zmCg5vHhBAMd5P4ei82+KsVg072KXbC63C44P0w3zbU
debug1: Host 'c199' is known and matches the ECDSA host key.
debug1: Found key in /c/Users/xxxxx/.ssh/known_hosts:35
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /c/Users/xxxxx/.ssh/id_rsa (0x60006bec0), agent
debug2: key: /c/Users/xxxxx/.ssh/id_dsa (0x0)
debug2: key: /c/Users/xxxxx/.ssh/id_ecdsa (0x0)
debug2: key: /c/Users/xxxxx/.ssh/id_ed25519 (0x0)
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /c/Users/xxxxx/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /c/Users/xxxxx/.ssh/id_dsa
debug1: Trying private key: /c/Users/xxxxx/.ssh/id_ecdsa
debug1: Trying private key: /c/Users/xxxxx/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

Solution 1

Thanks to https://unix.stackexchange.com/a/55481/106419, which told me how to debug ssh.

To enable ssh debug to see what happen

systemctl stop sshd
/usr/sbin/sshd -d -p 22

I found:

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

All guys only told:

• /home/ufo/.ssh ownership is correct 700
• /home/ufo/.ssh/authorized_keys ownership is correct 600/644

But sshd still check the user home folder !!! No one mentioned this !

sudo chmod 700 /home/ufo solve this problem.

---

Summary:

You need ensure:

• /home/ufo ownership is 700
• /home/ufo/.ssh ownership is 700
• /home/ufo/.ssh/authorized_keys ownership is 600

change ufo to you home folder name

Solution 2

I had to add the following to my sshd_config file:

PubkeyAcceptedKeyTypes=+ssh-dss

the restart ssh

Comments

[Patrick]

You need to login into the machine using the new command like the prompt displayed: "Now try logging into the machine, with: "ssh 'ufo@c199'"" So try doing ssh ufo@c199 and see if that prompts you for your password. If you continue to have issues, you'll need to run sshd in debug mode using /usr/sbin/sshd -d on the target machine and try to connect, then update your post with the debug output.

[Mithril]

@B Layer Sorry, a copy miss .. @Patrick But I don't want to see the prompt , I need auto login without prompt .That's what ssh-copy-id use for , right ?

[Patrick]

@Mithril, you are setting up promptless login with ssh-copy-id, you still need to use ssh ufo@c199 to make the actual connection to the target. If keys are set up correctly you will get a "promptless login" and be dropped straight into a shell after the SSH command.

[Mithril]

@Patrick That's is what I exactly described, ssh-copy-id ufo@c199 succeeded , but ssh ufo@c199 still prompt password input, that's the problem I am asking .

[Patrick]

@Mithril That means your keys are set up incorrectly. There could be several reasons for this: the first thing I would check is that your remote target .ssh user's folder is permissions 700 and your authorized_keys file is 644

[Mithril]

@Patrick They are all 777, I am sure the key added correctly , see my update content. The weird thing is same key inserted more than once . (I think because I run ssh-copy-id several times, which also indicate ssh-copy-id ufo@c199 works)

[Mithril]

@Patrick And it is the same key in /root/.ssh/authorized_keys , I can promptless login by root, but can't by ufo.

[Patrick]

If they are all 777, you need to adjust them to the values I stated above using the chmod command. E.g. chmod 644 ~/.ssh/authorized_keys

[Mithril]

@Patrick Doesn't 777 cover 644 ? Why I need change to 644 , I think it just for security. I have changed to that permission and restart sshd, still doesn't work.

[RubberStamp]

Use the -vv option when trying to login... look for lines like this one debug1: Offering public key: RSA

[Mithril]

@RubberStamp I have updated the output in question . This line problem we did not send a packet, disable method ?

[Jeff Schaller]

See also: unix.stackexchange.com/q/36540/117549

[Patrick]

@Mithril It is for security, but SSHD enforces that security, hence why it will refuse the connection if the permissions aren't correct. 777 is bad. It's saying everyone (owner, group, everyone else) has read, write and execute permissions. You don't want that on files that are supposed to stay private, like things in the .ssh folder, because then someone else could control who has access to the ufo account. You want to just the ufo user to have that control.

[Jeff Schaller]

Do note that the user is explicitly trying to log in with the key to a different user, and used ssh-copy-id successfully to that user, and during troubleshooting in the comments found that the directory permissions weren't correct. See that the OP has already accepted an answer saying so.