openssh unix dev - Oct 2012 - AuthorizedKeysCommand support added

Hi,

I just commited the patch on https://bugzilla.mindrot.org/b/1663 It adds
an AuthorizedKeysCommand option to sshd_config to use helper program to
fetch a user's authorized keys. Quite a few people have asked for this
to allow storage of public keys in LDAP or other databases.

The program is executed (directly, not via the shell) with a single
argument of the user being logged in. It produces on stdout zero or more
lines in authorized_keys format. The program must terminate normally and
with a zero exit status or its output is disregarded.

The program is executed as the user being logged in, unless a different
user is specified using AuthorizedKeysCommandUser.

A facility like this grants a large opportunity to shoot oneself in
the foot. We try to prevent obvious mistakes (like having the command
writable by others), but the best approach is to use a well-audited
helper, owned and writable only by root, that runs under a dedicated
account that is not used by anything else.

Portable OpenSSH snapshots with this change will be available tomorrow
(dated 20121101 or later). If you have an interest in this feature then
please help review and test it before out next release. It would be
handy if there were a good selection of helper commands ready then for
common backends (LDAP at least).

The patch was mostly written by Jan Chadima from Redhat, and I apologise
for taking too long to polish and integrate it.

-d

Hello Damien,
> I just commited the patch on https://bugzilla.mindrot.org/b/1663 It adds
> an AuthorizedKeysCommand option to sshd_config to use helper program to
> fetch a user's authorized keys. Quite a few people have asked for this
> to allow storage of public keys in LDAP or other databases.
thank you very much! I've been looking forward for that for a long time now.

> The program is executed (directly, not via the shell) with a single
> argument of the user being logged in. It produces on stdout zero or more
> lines in authorized_keys format. The program must terminate normally and
> with a zero exit status or its output is disregarded.
Reading the patch I see that STDERR is redirected to /dev/null; that might 
be interesting to know.
(Perhaps it would be better to allow some logfile, or even syslog, as 
destination for that output?)

Furthermore, how about setting alarm(60) or some similar timeout, and 
perhaps a CPU limit in the child handler, so that it doesn't run forever?


TBH, I can see the point that having a simple shell script inbetween - that 
can do all of this, too.



Well, thanks a lot!
Hoping for a new release soon, so that the distributions get the new 
feature, too...


Regards,

Phil

On 31 Oct 2012, at 00:16, Damien Miller wrote:
> A facility like this grants a large opportunity to shoot oneself in
> the foot
One potential anti-foot-shooting-device would be a configurable
regexp of usernames passed to such a command.

Or have you by this time checked the username is in some way sane?

-- 
Alex Bligh

On Wed, 31 Oct 2012, Alex Bligh wrote:
> 
> On 31 Oct 2012, at 00:16, Damien Miller wrote:
> 
> > A facility like this grants a large opportunity to shoot oneself in
> > the foot
> 
> One potential anti-foot-shooting-device would be a configurable
> regexp of usernames passed to such a command.
If you want to limit this to particular users, then you can do that
already using Match blocks.

Match group maybetrustworthy
	AuthorizedKeysCommand /usr/libexec/authorized_keys_ldap
> Or have you by this time checked the username is in some way sane?
It is only invoked if the user actually has an account on the host, so
there is no risk of bad usernames percolating through to the helper.

-d

Hi,

Just curious:
> ...
> The program is executed (directly, not via the shell) with a single
> argument of the user being logged in. It produces on stdout zero or more
> lines in authorized_keys format. The program must terminate normally and
> with a zero exit status or its output is disregarded.
> 
> The program is executed as the user being logged in, unless a different
> user is specified using AuthorizedKeysCommandUser.
Does this allow:

* Login as user x
* Fork a daemon process to stay alive after logout
* Logout
* Login again
* Let the daemon process running as x attach to the key-fetch-script running as
x, take over fds, ..
* Let key-fetch-script return something nice

This would of course only work, if e.g. ptrace-attach to non-children with same
UID is allowed, which is OK on older kernels/distros, new ones should block
that.

Roman

On Wed, 31 Oct 2012, Fiedler Roman wrote:
> Hi,
> 
> Just curious:
> 
> > ...
> > The program is executed (directly, not via the shell) with a single
> > argument of the user being logged in. It produces on stdout zero or
more
> > lines in authorized_keys format. The program must terminate normally
and
> > with a zero exit status or its output is disregarded.
> > 
> > The program is executed as the user being logged in, unless a
different
> > user is specified using AuthorizedKeysCommandUser.
> 
> Does this allow:
> 
> * Login as user x
> * Fork a daemon process to stay alive after logout
> * Logout
> * Login again
> * Let the daemon process running as x attach to the key-fetch-script
running as x, take over fds, ..
> * Let key-fetch-script return something nice
>
> This would of course only work, if e.g. ptrace-attach to non-children
> with same UID is allowed, which is OK on older kernels/distros, new
> ones should block that.
Well, it would let you break into your own account. This is a risk of using
the target user for the login script, which is something we explicitly
recommend against.

-d