Unable To Perform A "Passwordless" SSH Login To A Server

Greetings!

I am trying to perform a passwordless SSH login from a HPUX 11.31 client to a HPUX 11.31 server. Whenever I do a "ssh -l root serverA" from the client, I am prompted for a password. Giving the password, I am able to successfully login. However I am trying to accomplish a "passwordless" authentication.

Yes, I have generated the keys on the client and exported them to the /root/.ssh/authorized_keys file on the server

On the server the permissions are set as follows:

# ls -al /root/.ssh
total 48
drwxr-xr-x 2 root sys 8192 Apr 19 16:58 .
drwxrwxrwx 5 root bin 96 Apr 16 14:55 ..
-rw-r--r-- 1 root sys 392 Apr 19 16:52 authorized_keys
-rw-r--r-- 1 root sys 884 Apr 19 17:25 known_hosts
#

From the client, I am able to successfully accomplish passwordless logins to other servers. It is only on serverA that I am prompted for a password.

When running ssh debug from the client, this is what I am getting:

# ssh -v root@serverA
OpenSSH_4.2p1-hpn, OpenSSL 0.9.7e 25 Oct 2004
HP-UX Secure Shell-A.04.20.009, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Connecting to serverA [x.x.s.x] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/3
debug1: identity file /.ssh/id_rsa type 1
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_5.2p1+sftpfilecontrol-v1.3-hpn13v5
debug1: match: OpenSSH_5.2p1+sftpfilecontrol-v1.3-hpn13v5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2p1-hpn
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(1024<1024<8192) 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 'serverA' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:98
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: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password:

Any ideas on what is going on that is preventing me from doing a passwordless SSH login?

Thanks!

robs

ssh -v is very informative, as is the web. Permissions on keys and their directories are critical, for instance. You can tell ssh which auth to limit itself to, so there is no prompt and it stops. Start with "ssh localhost pwd" and later move to trying the local ip, host name, remote ip, host name.

Okay, I finally discovered what the problem was and fixed it. I would like to share the solution with the members of this thread because, even though the problem is now fixed, there was something in the solution
that I am not understanding (detailed down below).

Upon reading the system log (/var/adm/log/syslog/syslog.log), it reads as follows:

Apr 20 10:33:30 fyman00 sshd[25874]: Authentication refused: bad ownership or modes for directory /root

That, of course, got me in the ballpark...

I then looked at the permissions on /

# ls -al /
drwxrwxrwx 5 root bin 96 Apr 16 14:55 root

At that point, I knew the problem was going to be either "root bin" (improper owner) or "drwxrwxrwx" (incorrect permissions) or a
combination of both on the file /root

To determine which was the culprit, I corrected each one separately and then tested separately.

I then set the ownership to the correct setting: "root root". Retested and still could not achieve a successful passwordless (publickey) login. I then changed the mode to drwxr-xr-x I retested and then, you guessed it, I was able to successfully achieve a passwordless login. The final correction to /root reads as follows:

drwxr-xr-x 5 root root 96 Apr 16 14:55 root

Okay, here is the part that I do not understand: Why, after changing the mode from a LESS restrictive setting (drwxrwxrwx) to a MORE restrictive setting (drwxr-xr-x), why was I then allowed to finally authenticate correctly? This seems so counterintuitve... I'm quite certain that I am overlooking something rather basic...

Any ideas so I can finally put this one to bed? Thanks!

Rob S.

ssh refuses to operate on keys with incorrect permissions for security reasons. If /root is world-writable, there's no telling who actually put the keys in there!

So, are you saying that the ssh application decides what permissions
are correct/incorrect?

Thanks!

Rob Sandifer

No, sanity. No user should be able to change or steal another's keys, say to allow them to log in without password and no permissions.

I understand the underlying meaning of what you are saying...that the
/root directory (which contains the public key) should always be secure.

What I am asking...is....what is the mechanism which drives the enforcement of the permissions? In other words, what I am asking is
what is actually causing the ssh public key authentication to actually
become disabled when directory level permissions on /root are loosened
rather than tightened.... Stated anothery way... is it the unix operating system or is it the ssh application itself which causes public key authentication to fail? Thanks.

Rob S.

It's the ssh program itself.

Well, root is not the usual case. Root can read and write anyone's keys, but root must not allow anyone to get to his or any other user's private keys.

The UNIX O/S does not know what ssh is up to, it is nothing special; ssh deals with applying the rules and finding, passing, accepting the keys. Since sshd runs as root, it can create sessions for any user. Anyone could write such an access protocol, no O/S cooperation is required.

The very idea is likely the product of other O/S, where they hack the OS for every app, in place of providing facilities and staying out of the way. This is to support and sell proprietary software only. Long ago, that was all there was!

Thanks to all of you for your very thoughtful and insightful input!

Rob S.