7
  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
Mithril
  • 525
  • 2
    Step 5 is you logging in with ssh but you show messages coming from ssh-copy-id...what? – B Layer Nov 28 '17 at 01:35
  • 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. – Patrick Nov 28 '17 at 01:41
  • @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 ? – Mithril Nov 28 '17 at 01:53
  • @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. – Patrick Nov 28 '17 at 01:55
  • @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 . – Mithril Nov 28 '17 at 01:58
  • @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 – Patrick Nov 28 '17 at 02:01
  • @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 Nov 28 '17 at 02:07
  • @Patrick And it is the same key in /root/.ssh/authorized_keys , I can promptless login by root, but can't by ufo. – Mithril Nov 28 '17 at 02:10
  • 1
    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 – Patrick Nov 28 '17 at 02:11
  • @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. – Mithril Nov 28 '17 at 02:17
  • Use the -vv option when trying to login... look for lines like this one debug1: Offering public key: RSA – RubberStamp Nov 28 '17 at 02:22
  • @RubberStamp I have updated the output in question . This line problem we did not send a packet, disable method ? – Mithril Nov 28 '17 at 02:29
  • See also: https://unix.stackexchange.com/q/36540/117549 – Jeff Schaller Nov 28 '17 at 02:33
  • @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. – Patrick Nov 28 '17 at 02:47

5 Answers5

9

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

Mithril
  • 525
1

I had to add the following to my sshd_config file:

PubkeyAcceptedKeyTypes=+ssh-dss

then restart sshd.

Stephen Kitt
  • 434,908
millican
  • 11
0

Apparently you have not put an entry in the authorized_keys file of the user ufo.....or the permissions are wrong on ~ufo/.ssh files/directories.

mdpc
  • 6,834
0

Make sure that you add your public key to your directory and not the root or another users.

Jamie
  • 1
  • 2
    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. – Jeff Schaller Nov 16 '20 at 19:29
0

This is another solution in case you cannot access or modify sshd_config as suggested by millican in their answer. A solution is to creates a new SSH key using the ED25519 algorithm:

ssh-keygen -t ed25519 -C "your_email@example.com"

as explained here. This solved my problem, which was caused by the fact that the RSA SHA-1 hash algorithm is deprecated.

Gianmarco
  • 1