Search code examples
gitsshrsadsa

ssh: Identical rsa key generation steps work for one user, but no another


I just went through generating rsa keys so that a windows 10 laptop running cygwin can log onto a CentOS machine without a password. It works fine. The same process however didn't work for setting up password-less login for another remote user. I am still asked for the password.

The steps for the first remote user were as follows

On the Windows10 client (Cygwin):

ssh-keygen -t dsa 
chmod 600 /home/John/.ssh/id_dsa 
scp /home/John/.ssh/id_dsa.pub UserA@my-server.com:

On the CentOS server (logged in as UserA, from the /home/UserA/ directory):

cat id_dsa.pub >> .ssh/authorized_keys 
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Those steps worked fine, but the same steps for a different remote user did not for some reason. ssh UserB@my_server.com still asks for a password after doing

the same steps for another remote user:

On the Windows10 client (Cygwin):

ssh-keygen -t dsa 
chmod 600 /home/John/.ssh/user_b_dsa 
scp /home/John/.ssh/user_b_dsa.pub UserB@my-server.com:

On the CentOS server (logged in as UserB, from the /home/UserB/ directory):

cat user_b_dsa.pub >> .ssh/authorized_keys 
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Any idea why the same steps would cause different results like this? I verified chmod commands worked and verified that authorized_key was correctly updated


Solution

  • So the solution seems to have been that the /home/UserB folder permissions were set to 770 and needed to be 700. Also, like I had originally tried, you don't need a different id_dsa key for the other user. Simply copying the original id_dsa.pub to the /home/UserB file and continuing with the same steps works fine. If you do try to use a different dsa file, that won't work either unless you explicitly tell ssh to use it with ssh -i /home/user/.ssh/my_dsa user@server.com Apparently ssh is really picky about what permissions things are and doesn't even spit out an error message to tell you what the issue is. You have to happen to magically know that ssh logs exist somewhere to get any insight into the issue..