ssh public key - keeps prompting for password

[Mauro Livi]

Hi all,
I'm pulling my hair out on this. Using OpenSSH_3.6.1p2 and am using ssh public keys and keep getting prompted for a password. The process I've done is as follows:

1) ssh-keygen -t rsa
2) copied the id_rsa.pub to the /home/.ssh directory of the remote host into an authorized_keys2 file.
3) made sure that permissions on the .ssh directory on both servers is 700
4) made sure that permissions for the authorized_keys2 file is 644 on the remote host. The id_rsa.pub on the client also has 644 permissions.
5) I need to have ssh working both ways between the servers. If I do it from one server as outlined above, it prompts for a password, if I do it the other way, it does not and works beautifully.
6) I've checked ssh.config and sshd.config between the servers, they're exactly alike.

I'm attaching the ssh -v [servername] output. Obviously I would expect a line in there saying that the public key is being accepted, but that is not happening, so it falls through to password authentication. Does anyone have any clues? I've obviously gone through many other threads on the subject and nothing has worked thus far.

I would be eternally grateful for any clue.
Thanks
Mauro

ssh -v server output
-----------------------
ssh -v sargon
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090702f
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: Connecting to sargon [172.16.3.44] port 22.
debug1: Connection established.
debug1: identity file /home/appltest/.ssh/id_rsa type 1
debug1: identity file /home/appltest/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
debug1:


debug1: Mechanism encoded as toWM5Slw5Ew8Mqkay+al2g==
debug1:


debug1: Mechanism encoded as A/vxljAEU54gt9a48EiANQ==
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'sargon' is known and matches the RSA host key.
debug1: Found key in /home/appltest/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: external-keyx,gssapi,publickey,passwo
rd,keyboard-interactive
debug1: Next authentication method: external-keyx
debug1: Authentications that can continue: external-keyx,gssapi,publickey,passwo
rd,keyboard-interactive
debug1: Next authentication method: gssapi
debug1:


debug1:


debug1:


debug1: Next authentication method: publickey
debug1: Offering public key: /home/appltest/.ssh/id_rsa
debug1: Authentications that can continue: external-keyx,gssapi,publickey,passwo
rd,keyboard-interactive
debug1: Offering public key: /home/appltest/.ssh/id_dsa
debug1: Authentications that can continue: external-keyx,gssapi,publickey,passwo
rd,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: external-keyx,gssapi,publickey,passwo
rd,keyboard-interactive
debug1: Next authentication method: password
appltest@sargon's password:

[OldSchool]

I'm running OpenSSH 4.3p2, so take it *may* be different, however, I did note that on my installation, it is "authorized_keys" (not authorized_keys2), and permissions on that file needed to be "600" not "644".

maybe the above will help

[Mauro Livi]

Thanks OldSchool...tried your suggestions, but no luck. What really kills me is that if I try the same process outlined above going the other way, it works fine. I'm guessing somehing in a config somewhere, but I'll be darned if I can find it.

[Doug O'Leary · Accepted solution]

Hey;

Oldschool may have the right answer.

grep -i authorizedkeysfile /opt/ssh/etc/sshd_config

and see what ssh is looking for. Older versions used the authorized_keys2 for whatever reason, possibly to separate ssh ver 1 from ver 2 keys. Newer versions went straight for the authorized_keys file.

If that doesn't pan out, check syslog. ssh is usually very good about logging why it's not letting a public key authenticate.

If *that* doesn't pan out, change the SyslogFacility to AUTH and the LogLevel to VERBOSE in the sshd_config file, sighup sshd and try again. You should see something in syslog then.

HTH;

Doug

[Tingli]

You also need to check your user home directory's permission. That means, for group and world, the permission must be lower than 55 with no write permission. This also can be checked in file /var/adm/syslog/syslog.log. It might tell you that you need to change home directory permission too.

[OldSchool]

debug1: Offering public key: /home/appltest/.ssh/id_dsa
<---- you should have gotten a message that the key was accepted here.....
===========================================================================
debug1: Authentications that can continue: external-keyx,gssapi,publickey,passwo
rd,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: external-keyx,gssapi,publickey,passwo
rd,keyboard-interactive
debug1: Next authentication method: password
appltest@sargon's password:

====================================================

suggest you crank the logging up one more level w/
ssh -vv sargon


Also, on the destination server, the destination directory that you are logging into needs to have permissions set to r/x for "group" and "others", .ssh directory is 700 and all the files are 600 correct? you've tried redistributing the keys or regen/redistribute?

[Mauro Livi]

I feel so stupid!!! It was permissions on the /home/ directory causing the problem. I was under the impression that if you had your .ssh directory set with the appropriate permissions, you'd be ok. Once I put the appropriate permissions on the home directory, it worked. You guys are awesome! I will assign points momentarily. Thanks for your help!

Mauro

[Mauro Livi]

I meant the user's home directory. I though only the user's .ssh directory needed the appropriate permissions.
Thanks again,
Mauro

[OldSchool]

uhh...how do you think *I* knew :-)

[Steven Schweda]

> [...] I though only the user's .ssh
> directory needed the appropriate
> permissions. [...]

It's a pretty reasonable security policy.

If its parent directory lets anyone play
around, then it doesn't matter much what the
permissions on ".ssh" itself are, because
then anyone could change the permissions on
".ssh", play around in it, and change them
back. Unless the permissions are restrictive
all the way to the top, they're really not
restrictive.

[Mauro Livi]

Yeah, it all makes sense now...live and learn I guess.
Mauro

[OldSchool]

If you really need to relax the permissions (which I don't recommend) then the
"StrictModes" parameter in sshd_config allows those checks to be bypassed....


as I said tho, its not recommended for the reasons Steve noted.......