server not accepting ssh key

Brazen

Diamond Member
Jul 14, 2000
4,259
0
0
on the server, I created a key with "ssh_keygen" which made an id_rsa and id_rsa.pub in the .ssh folder.

I then copied the public key into the authorized keys file with "cat .ssh/id_rsa.pub > .ssh/authorized_keys"

Then copied the id_rsa private key to a remote computer and put it in .ssh/id_rsa but when I try to connect with "ssh username@server" it still prompts for a password.

I also tried copying the id_rsa to a Windows workstation, converted it with puttygen and tried to use it from Putty. That is where I get the error "Server refused our key" and prompt for a password.

Any ideas how to troubleshoot this? I've double checked everything and it looks like I've done everything I need to.

The server is RHEL 5.0, btw.
 

Skiddex

Golden Member
May 17, 2001
1,380
0
76
all you should need to do is put the contents of id_rsa.pub into authorized_keys on your remote host.

what you are doing with cat .ssh/id_rsa.pub > .ssh/authorized_keys is letting yourself ssh back into the same box without entering a password. if you were to then copy that .ssh/authorized_keys to the remote box, it would work as well. the private key will stay on the box it was generated on.

let me know if you have any other questions
 

Brazen

Diamond Member
Jul 14, 2000
4,259
0
0
Originally posted by: Skiddex
all you should need to do is put the contents of id_rsa.pub into authorized_keys on your remote host.

what you are doing with cat .ssh/id_rsa.pub > .ssh/authorized_keys is letting yourself ssh back into the same box without entering a password. if you were to then copy that .ssh/authorized_keys to the remote box, it would work as well. the private key will stay on the box it was generated on.

let me know if you have any other questions

I actually did try to ssh from the server back into itself, as a troubleshooting step (that didn't work either, and it should, I would think). However, the authorized_keys file does need to stay on the server, and you copy the private key to the client that initiates the ssh connection. I'm pretty certain about that part, and it's worked fine on several other servers I admin. I usually admin Debian/Ubuntu servers though, so I'm thinking there is something funky about RHEL 5.0.
 

xSauronx

Lifer
Jul 14, 2000
19,582
4
81
odd way to start it all out

usually i see the suggestion that the REMOTE client generate the keys, and give the public key to the server, but either way he has the right keys in the right place, by the look of things.

it's possibly permissions. i had setup ssh on debian a few times, but theres another permission i needed to change in CentOS 5 when i was trying it.

the server accepting the ssh connection needs the following permissions:
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

maybe that will help?
 

Brazen

Diamond Member
Jul 14, 2000
4,259
0
0
Originally posted by: xSauronx
odd way to start it all out

usually i see the suggestion that the REMOTE client generate the keys, and give the public key to the server, but either way he has the right keys in the right place, by the look of things.
eh. I do it both ways.

it's possibly permissions. i had setup ssh on debian a few times, but theres another permission i needed to change in CentOS 5 when i was trying it.

the server accepting the ssh connection needs the following permissions:
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

maybe that will help?

Ok, I got it fixed and there are two things. One is the chmod'ing you list above. But I tried that before and it didn't work. I ended up disabling selinux (this is the first server I have had configured to keep it turned on). I had recreated the authorized_keys file to make sure I put the right public key in it, though, so the permissions would have been reset to 664. So after disabling selinux it did not work, but then it still did not work. So, after reading your post, I redid the chmod 600, and it works!

So anyway, just thought I'd give the lengthy explanation so if anyone else comes across this, know that the authorized_keys file needs to be chmod'd 600 and selinux needs to be either disabled or reconfigured to allow ssh keys (I found instructions for doing this on FC8, but it did not work on RHEL 5.0, so I just disabled it).
 

xSauronx

Lifer
Jul 14, 2000
19,582
4
81
Originally posted by: Brazen
Originally posted by: xSauronx
odd way to start it all out

usually i see the suggestion that the REMOTE client generate the keys, and give the public key to the server, but either way he has the right keys in the right place, by the look of things.
eh. I do it both ways.

it's possibly permissions. i had setup ssh on debian a few times, but theres another permission i needed to change in CentOS 5 when i was trying it.

the server accepting the ssh connection needs the following permissions:
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

maybe that will help?

Ok, I got it fixed and there are two things. One is the chmod'ing you list above. But I tried that before and it didn't work. I ended up disabling selinux (this is the first server I have had configured to keep it turned on). I had recreated the authorized_keys file to make sure I put the right public key in it, though, so the permissions would have been reset to 664. So after disabling selinux it did not work, but then it still did not work. So, after reading your post, I redid the chmod 600, and it works!

So anyway, just thought I'd give the lengthy explanation so if anyone else comes across this, know that the authorized_keys file needs to be chmod'd 600 and selinux needs to be either disabled or reconfigured to allow ssh keys (I found instructions for doing this on FC8, but it did not work on RHEL 5.0, so I just disabled it).

there must be something default set differently betweehn RHEL 5 and CentOS 5, then, because i never had to touch anything related to SELinux to get ssh to work. i just had to change those permissions.

oh well, no matter, the odds of me so much as touching a RHEL server anytime soon are slim to none. they use SUSE at school, and i have no idea what they do in the linux admin class. it might actually be a new course, which will probably mean its going to be less interesting than lurking on linux forums.