SSH keygen auth problems

[Matt Palmer_2]

Hi,

I have a situation where I would like to use secure keys to send data between to Suse SLES 8 hosts, but I am having difficulty in creating successful keys.

Currently I am trying ssh-keygen -d on both hostA and hostB then copying the id_dsa.pub to authorized_keys on the 'other' hosts.

after this I am using ssh-agent sh -c'ssh-add' which tells me that the identity has been successfully added.

The problem that I have is that the process although I have used the same procedure on both boxes is only working on one of them. I.E:I can ssh HostA from HostB without having to type in a password. When I try to use it the other way around, the ssh process keeps asking me to type in the password for user@HostB. I hope my info is not too vague.

Any help would be greatly appreciated.I wonder if I have missed something or if there is a default file that may exist on the unsuccessful machine.

Many thanks

[Alexander Chuzhoy]

ssh-keygen -d
creates by default the file ~/.ssh/id_dsa.pub

you have to copy it to destined machine:
x.x.x.x:/home/username/.ssh/authorized_keys
then when issuing this command:
ssh username@x.x.x.x
you'll login to this machine without the prompt of username password.Check that you do exactly the same steps...

[Matt Palmer_2]

Hi,

this is what I have tried already, but it is not working on the 2nd machine.

thanks

Matt

[Alexander Chuzhoy]

Remove the files authorized_keys ,known_hosts
from the "bad" machine and try the procedure again.
In case it doesn't help try reinstalling
the openssh package.

[Matt Palmer_2]

still no joy..

[Olivier Drouin]

run the ssh clients and deamon in debug ( -dd )

[Alexander Chuzhoy]

check the permission on .ssh directory .Only the owner should have the permissions.If the permission is too open -there's a problem

[Matt Palmer_2]

I'll give the -dd a try, that might give me some leads.

Many Thanks

[Abdul Rahiman]

Well, few more hints.. may be helpful.
1. By any chance did you copy-paste the key on the other server instead of actually sftp/scp-ing?
2. Are you running the exact same version of ssh on both servers? Check ssh -V on both. If the versions are different, there are some addiional steps required to export/import the keys.
3. Check to see if there is any differences between the /etc/ssh/sshd_config files.
4. Try to authentciate without ssh-agent initially, just using the keys on the file instead to see if that works.
5. If none works, post the poutput of sshd debug log as well as ssh -vvv (connection log)

regds,
abdul.

[Steven E. Protter]

Attached is a word doc. You can bypass the X part and use cat, but pay special attention to permissions in the doc.

SEP

[Stuart Browne]

When you generated the keys using 'ssh-keygen', did you put in a password?

Also, did you use 'ssh-agent' on both sides?

If you put a password in when generating the keys, you will always be prompted for it, unless you use 'ssh-agent' (which is a password-cache for known keys basically).

[Matt Palmer_2]

Hi Everyone,

I've cracked it!! thanks for all the help. In the end after verbosing the o/p, the key auth was not getting processed because the directory permissions on the home directory for the user on the remote box were not 755 so the connection was not allowed. -Even though the .ssh directory inside there was fine.

So changed file perms and now everything is fine

Many Thanks

Matt

[Alexander Chuzhoy]

Hm,
the permissions on home directory shouldn't be 755 for this purpose (it works perfectly even when the permission is 700).
It's the permission on .ssh folder that matters.It shouldn't be too open, i.e. granting 777 will prompt for password,755 however will alow passwordless login.


Best regards.

[Olivier Drouin · Accepted solution]

All the permission from "/" up to "~/.ssh" are important.

If .ssh is 700 but your home directory is 777 it will ask for a passwd.