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

[robs58]

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

[Steven Schweda · Accepted solution]

> debug1: Next authentication method: keyboard-interactive

The server hates your keys. The server
system log file probably says why.

> # 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 ..

777 permissions _WHERE_?!?!?!

> [...] It is only on serverA [...]

Did you compare this (crazy?) stuff with the
corresponding stuff on another (working)
server?

[Michael Steele_2]

/etc/ssh/sshd_config file.
PermitRootLogin no/yes
restart the sshd service

[Bill Hassell]

It is critical to set the correct permissions for the keys on every server. NEVER use 777 for any directory except /tmp and /var/tmp. I know there are a lot of bad textbooks on Unix that tell you to 'fix' permission problems with chmod 777 but it is a very bad practice. The proper permission for /root is 700 or perhaps 755, but answer the question: Do any ordinary users on my system need to look into the /root directory? I recommend 700.

Then .ssh must also be 700 -- no one should be able to look in there. And the rest of the files must not be readable by anyone (except the owner) which means 600 permission.

The one feature missing from ssh -vvv is debug details when a public key is not acceptable, such as parent directory or file permission and ownership. So:

chmod 700 /root /root/.ssh
chmod 600 /root/.ssh/*

Finally, make sure that the public key has been appended to authorized_keys correctly. If you use vi, there may be extra spaces and line breaks. The proper format is:

ssh-rsa AAAA...one_long_line... comments

Rather than use vi, just append the key:

cat mykey.pub >> /root/.ssh/authorized_keys

[Steven Schweda]

> /etc/ssh/sshd_config file.
> [...]

Around here, that's
"/opt/ssh/etc/sshd_config", and
"PermitRootLogin yes" is the default.


> The one feature missing from ssh -vvv is
> debug details when a public key is not
> acceptable, [...]

That "feature" may be missing because when
someone is trying to break into one's server,
one may not wish to reveal to the culprit
exactly why the attack has been failing.


> chmod 700 /root /root/.ssh

Let's not get carried away. These
directories do not need to un_read_able by
anyone, only unwritable. 755 is fine. The
022 bits are the bad ones.

> chmod 600 /root/.ssh/*

And here, only "authorized_keys" and the
private key files (and "prng_seed"?) need to
be so restricted. (The public key files, for
example, are, after all, _public_ key files.)


For the record, "around here" means:

rux # uname -a
HP-UX rux B.11.31 U ia64 1678555272 unlimited-user license

rux # ssh -V
OpenSSH_5.2p1+sftpfilecontrol-v1.3-hpn13v5, OpenSSL 0.9.8k 25 Mar 2009
HP-UX Secure Shell-A.05.20.015, HP-UX Secure Shell version

(Which suggests that
OpenSSH_4.2p1-hpn, OpenSSL 0.9.7e 25 Oct 2004
HP-UX Secure Shell-A.04.20.009, HP-UX Secure Shell version
may not be maximally shiny.)

[robs58]

Many thanks to all who replied. Points have
been assigned! Now I will go back through and sort through all of this and figure out what is going on.... Thanks!

Rob S.

[robs58]

Thanks to all who replied!

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 reviewing the system log (thank you,
Steven Schweda!), it stated:

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 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.

[Bill Hassell]

> 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...

Actually, there are several programs that won't work with wrong permissions and ownership: remsh,rcp,rexec,rlogin,sendmail and of course, ssh/sshd. Programs that are designed for security will fail if the security is too open. In the case of ssh, the permissions of the authorized_keys, the key files, the .ssh directory *AND* the parent must be restricted. The reason is that open permissions (ie, 777 for .ssh) means that NOTHING in that directory can be trusted. Any file can be renamed, or removed or replaced even if the file itself is write-protected. So ssh verifies that the directory permission meet minimum standards and if not, silently refuses to negotiate.

Although it is tempting to 'fix' permission errors with 666 and 777, it is the wrong approach. The reason for the permission denied error must be determined and then permissions adjusted carefully. And always be resistant to changing HP-supplied permissions. A couple of exceptions are /usr/local directories which have been wrong for about 20 years (777) but finally fixed, and possibly /usr/share man files which need to be writable for man page formatting.

[robs58]

Thanks again for the explanation. I know that fully open permissions are bad; I was only trying to understand the mechanism which enforces the disabling of public key
authentication if the permissions are set too
loosely. Thanks!

Rob S.

[Steven Schweda]

> [...] Any file can be renamed, or removed
> or replaced [...]

Of course, the critical matter is not _that_
a file can be modified, but _who_ can do it.
It's generally not a problem if the user is
the owner, and if the owner can modify it.
The problem comes when some other user
(which, for 777 permissions, could be _any_
other user) can modify it.

Also, as may be obvious by now, if
restrictive permissions are required on any
particular file, then similar restrictions
are required on parent directories, all the
way up. Write permission anywhere in the
tree allows changes anywhere below.

I don't know if SSH is smart enough to worry
about access control lists, or if its concern
is confined to the usual user/group-based
permissions. (And it would be
implementation-dependent, too.)


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

You mean that "777 permissions _WHERE_?!?!?!"
was too subtle?