Subject: ssh: ssh with public key authentication seems paranoid about home dir permissions

From: era eriksson <[email-masked]>
Date: Thu, 03 Oct 2002 15:44:38 +0300

Package: ssh
Version: 1:3.4p1-1
Severity: normal

I tried to set up ssh with public key authentication but it turned out
to be impossible without changing the permissions of my home directory.
While this is not a major obstacle, figuring out what the permissions
ought to be was less than obvious.

Turns out that chmod 2700 and 2711 ~ is okay, while anything with read
permissions for group is unacceptable. (I'm speculating a bit here
because I haven't done exhaustive testing [*].)

This bug is probably a packaging error, seeing as the owner=group
convention is somewhat specific to Debian (and Red Hat, IIRC) while
the upstream edition of SSH probably wants to continue to be paranoid
about group-readable home directories.

Troubleshooting this was hard because there is no fair warning -- it
took me a while to notice the error messages in auth.log. It would be
ideal if the error could be displayed on the terminal of the user who
is attempting to log in (I fail to see how this could open up any
major security problems).

So I'd like to see

 1) the Debian package fixed so that group ownership checks are
    ignored if the group ID is equal to the user's login ID (and/or
    the user ID is in the interval defined to be reserved for local
    users as per Debian policy)

 2) any home directory permission requirements clearly documented

 3) permission warnings to be displayed to the user who is trying to
    log in, and getting rejected because of permission problems

 4) tangentially, the behavior when permissions are wrong is a bit
    strange when it comes to prompting for a password. Specifically,
    if I have added the key with ssh-add, I will get three password
    prompts: 

    1. when the authorization agent's public key is checked and rejected,
       it will ask for the key's passphrase -- to no avail, it's not the
       lack of a passphrase which is causing the rejection

    2. falls back to using the regular identity key, same thing again
       (even if the agent was trying the identity key originally!)

    3. and then finally fall back to regular password authentication
       (which doesn't suffer from problems with home directory checks)

    See also BTS bug #157138.

That's a tall order; if you'd like me to break it up into smaller
bugs, write back and I'll see what I can do.

/* era */

[*] The only link where I can test this is a GPRS connection running
at approximately 9,600 bps. The simple command "ssh there echo moo"
takes on the order of three minutes to complete. I've run about ten of
those tests ...

-- System Information
Debian Release: 3.0
Kernel Version: Linux there.afraid.org 2.2.17 #1 Sun Jun 25 09:24:41 EST 2000 i586 unknown

Versions of the packages ssh depends on:
ii  adduser        3.47           Add and remove users and groups
ii  debconf        1.0.32         Debian configuration management system
ii  libc6          2.2.5-11.1     GNU C Library: Shared libraries and Timezone
ii  libpam-modules 0.72-35        Pluggable Authentication Modules for PAM
ii  libpam0g       0.72-35        Pluggable Authentication Modules library
ii  libssl0.9.6    0.9.6c-2.woody SSL shared libraries
ii  libwrap0       7.6-9          Wietse Venema's TCP wrappers library
ii  zlib1g         1.1.4-1        compression library - runtime

---

From: era eriksson <[email-masked]>
Date: Fri, 4 Oct 2002 09:49:37 +0300

> to be impossible without changing the permissions of my home directory.

Sorry for leaving out a couple of "obvious" details.

The home directory on the host I'm trying to log in +to+ were the ones
which were problematic. I haven't looked at how SSH behaves when the
originating client's home directory permissions are lax; presumably
you get roughly the same behavior (but at least hopefully a
user-visible warning).

The message I get in /var/log/auth.log is

Oct  3 14:50:06 there sshd[26047]: Authentication refused: bad ownership or modes for directory /home/era

Even with ssh -d none of this is visible to the client who is trying
to connect, which makes this awfully hard to troubleshoot for a normal
user (who might not even have permissions to look at /var/log/auth.log).

/* era */

-- 
   tee -a $HOME/.signature <$HOME/.plan >http://www.iki.fi/era/index.html