ssh-keygen configuration problem

I am unable to set password less entry from one server to another even after i have generated public key and have put in the authorized_keys of the target server. When i try to debug the ssh using ssh -v, it gives me

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/sasdemo/.ssh/identity
debug1: Offering public key: /home/sasdemo/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering public key: /home/sasdemo/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply

also .. just to test, when i did
$cat id_dsa.pub | ssh user@server_id 'cat >> ~/.ssh/authorized_keys'
it asked for the password and then gave the error message
bsh: ~/.ssh/authorized_keys: 0402-011 Cannot create the specified file.

Any suggestions ???? Can bean shell be a problem ???

Did you enter a passphrase when you created the key?

It could be a filesystem problem: ssh does not like it when the filemode is set too generous. It should be "600", the important thing being "00" for group and world. Depending on your ssh version and the architecture you're running this might be a problem.

I hope this helps.

bakunin

No i didnot enter any passphrase ..

The filesystem ~/.ssh and authorized_keys file already contains the permission of 644 .. and in other server it's working fine ..

Is anyone aware of any type of conflict between bsh and ssh ?

The .ssh directory should be 700.

Still not working ....

What parameters are necessary in sshd_config to get this enabled.. ?
Can someone provide me barely essential parameters settings so that i can verify mine ..

any one with any suggestion ?????????

Well, you said "in other server it's working fine". So you have one server where it works and one server wher it fails. So compare the two servers and find the difference.

Well .. that is what i have kept as the last option .. but my this server is the production server .. so cant risk the security ... was trying to get the barely essential parameters set in /etc/ssh/sshd_config so that security is not threatened at all .. now i guess will have to do hit and trial...

Thanks :o

brandedfundoo,

Perderabo is correct please set permission to 700. Set the permission to /home/<the user your trying to passwdless login> at remote server . I encountered this weird scenario before and setting up the /home/<username> to 700 really helps.

i have already kept my ssh directory with 700 permissions...

Now problem has become more weird ....
The server got a hard reboot and bingo !! everything started working fine..
i do not know the reason as all the entries in /etc/ssh/sshd_config are commented.. but it's working fine now... kinda strange it is... am trying to trace but no luck so far ..

The only parameters uncommented are

X11Forwarding yes
Subsystem sftp /usr/sbin/sftp-server

I forgot mentioning that i got user's default shell changed to ksh from bsh(bean shell) few days before and this one the first hard boot of the server after that ... Could it make difference ..?

Can any one suggest anything in this regard ...?

Well, after the show we are left to guessing, but at least your problem is solved - for now. Problems, even when they do not hit, tend to come back if the solution is not understood.

1. It might have been that the daemon process (sshd) was not running. Obviously it gets started automatically at system boot time, so the problem is gone.

2. Maybe it was running, but started under a users ID instead of root, so that another user could not access its services. In this case too you have no problem any more.

3. Maybe it was started correctly but - for an unknown reason - aborted. You should find residues of this happening in the error log (issue "errpt" and "errpt -a" respectively) and you should find out what condition was causing it, it might come back.

Perhaps there are a lot of other possible reasons, you might want to consider.

I hope this helps.

bakunin

hmm... actually we login into the server through ssh only .. so ssh surely didnot get aborted.. everything was working fine except it was asking for password everytime ..

i m still keeping trace on things .. how they come out to be ..

Yes you are right.. problems tend to come back when the solution is not understood ..

wish me luck.. .. there must be some logical reason behind this kinda behaviour and i will have to find that ..

I notice that you have set your ssh directory to 700, but you say...

This should be 600 not 644!

Permissions on the directory AND the key file can cause this.