openssh unix dev - Jul 2008 - Risk of StrictMode (but read only)

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?

---
Don Hoover
dxh at yahoo.com

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?
> 
> ---
> Don Hoover
> dxh at yahoo.com
>
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.)

-- 
Iain Morgan

[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 <jmknoble at pobox.com> -----

Date: Tue, 15 Jul 2008 19:47:18 -0400
From: Jim Knoble <jmknoble at pobox.com>
To: Iain Morgan <imorgan at nas.nasa.gov>
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 at 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|
+----------------------------------------------------------------------+