Re: Risk of StrictMode (but read only) - openssh

This is a discussion on Re: Risk of StrictMode (but read only) - openssh ; [Apparently i was on auto-pilot when i sent the message below and neglected to send it to the mailing list and the original poster. Here it is.] ----- Forwarded message from Jim Knoble ----- Date: Tue, 15 Jul 2008 19:47:18 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Risk of StrictMode (but read only)

  1. Re: Risk of StrictMode (but read only)

    [Apparently i was on auto-pilot when i sent the message below and
    neglected to send it to the mailing list and the original poster.
    Here it is.]

    ----- Forwarded message from Jim Knoble -----

    Date: Tue, 15 Jul 2008 19:47:18 -0400
    From: Jim Knoble
    To: Iain Morgan
    Subject: Re: Risk of StrictMode (but read only)

    Circa 2008-07-15 15:31 dixit Iain Morgan:

    : On Tue, Jul 15, 2008 at 07:51:00 -0700, Don Hoover wrote:
    : > Is there a risk associated with having authorized_keys files set to
    : > readable but "StrictMode no"?
    : >
    : > I am thinking particularly in the case of having public keys all
    : > centralized in a directory in /etc or something.
    : >
    : > Is it really a potential hack vector if someone can read a public
    : > key, or is the only real danger if they were writable?
    :
    : If Your OS supports POSIX ACLs, you could set an acl on each
    : authorized_keys file to make it readable by the user without having to
    : turn off StrictModes. (On Linux, you may need to supply the acl mount
    : option to enable POSIX ACL support.)

    StrictModes keeps your ~/.ssh/authorized_keys file and its containing
    directories from being writable by someone other than root or the owner.
    This is what's crucial (so that no one else can add their own public key
    to authorized_keys, for example).

    If by "public keys centralized in a directory..." you are referring to
    the authorized_keys files, then the only real danger is exposure of
    information about who is allowed to log in using public keys and what
    restrictions those logins may or may not have.

    If this concerns you, consider keeping the authorized key files in
    per-user directories; for example (in sshd_config):

    AuthorizedKeysFile /etc/ssh/auth/%u/authorized_keys

    Then, make each user's directory under /etc/ssh/auth/ readable only by
    that user. For example, for users 'alice' and 'bob':

    mkdir -p /etc/ssh/auth/alice /etc/ssh/auth/bob
    chmod 0400 /etc/ssh/auth/alice
    chown alice:0 /etc/ssh/auth/alice
    chmod 0400 /etc/ssh/auth/bob
    chown bob:0 /etc/ssh/auth/bob

    Now alice can read her own /etc/ssh/auth/alice/authorized_keys file, but
    can't read bob's.

    You could even use this to allow specific users to maintain their own
    authorized_keys file, if you so desire.

    Good luck,
    Jim

    ----- End forwarded message -----

    --
    jim knoble | jmknoble@pobox.com | http://www.pobox.com/~jmknoble/
    (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ )
    (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA )
    +----------------------------------------------------------------------+
    |[L]iberty, as we all know, cannot flourish in a country that is perma-|
    | nently on a war footing, or even a near-war footing. --Aldous Huxley|
    +----------------------------------------------------------------------+
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  2. Re: Risk of StrictMode (but read only)

    Circa 2008-07-16 13:32 dixit Jim Knoble:

    : mkdir -p /etc/ssh/auth/alice /etc/ssh/auth/bob
    : chmod 0400 /etc/ssh/auth/alice
    : chown alice:0 /etc/ssh/auth/alice
    : chmod 0400 /etc/ssh/auth/bob
    : chown bob:0 /etc/ssh/auth/bob

    And, of course, i wasn't thinking clearly. There are at least two
    problems with the above:

    (1) For the purpose above, '0500' is the right mode (make directories
    searchable):

    chmod 0500 /etc/ssh/auth/alice
    chmod 0500 /etc/ssh/auth/bob

    (2) Making the users the owner of the directory enables them to
    change the permissions of the directory. That, in turn, enables
    them to change any files contained in it. If that's not what
    you want, you are better off adding each user to their own group
    (as is done by default on many modern Linux-based systems), then
    changing directory ownership to that group and setting
    permissions accordingly. Example:

    groupadd alice
    GROUPS=`id -Gn alice |sed -e 's/ */,/g'`
    GROUPS=${GROUPS:+${GROUPS},}
    usermod -G ${GROUPS}alice alice
    mkdir -p /etc/ssh/auth/alice
    chmod 0750 /etc/ssh/auth/alice
    chown 0:alice /etc/ssh/auth/alice

    Your mileage may vary, depending on whether groupadd and usermod
    are available (you may need to manipulate /etc/groups directly).

    : Now alice can read her own /etc/ssh/auth/alice/authorized_keys file, but
    : can't read bob's.
    :
    : You could even use this to allow specific users to maintain their own
    : authorized_keys file, if you so desire.

    Which is possible by:

    mkdir -p /etc/ssh/auth/alice
    chmod 0700 /etc/ssh/auth/alice
    chown alice:alice /etc/ssh/auth/alice

    Best,
    Jim

    --
    jim knoble | jmknoble@pobox.com | http://www.pobox.com/~jmknoble/
    (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ )
    (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA )
    +----------------------------------------------------------------------+
    |[L]iberty, as we all know, cannot flourish in a country that is perma-|
    | nently on a war footing, or even a near-war footing. --Aldous Huxley|
    +----------------------------------------------------------------------+
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


+ Reply to Thread