Mailing List Archive: OpenSSH: Dev

AuthorizedKeysCommand support added

Index | Next | Previous | View Threaded

djm at mindrot

Oct 30, 2012, 5:16 PM

Post #1 of 14 (929 views)
Permalink

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

philipp.marek at linbit

Oct 30, 2012, 11:48 PM

Post #2 of 14 (914 views)
Permalink

Re: AuthorizedKeysCommand support added [In reply to]

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

alex at alex

Oct 31, 2012, 12:42 AM

Post #3 of 14 (911 views)
Permalink

Re: AuthorizedKeysCommand support added [In reply to]

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

djm at mindrot

Oct 31, 2012, 12:59 AM

Post #4 of 14 (912 views)
Permalink

Re: AuthorizedKeysCommand support added [In reply to]

On Wed, 31 Oct 2012, Philipp Marek wrote:

> > 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?)

I want to keep this code simple, and don't want to have to implement
yet another select() loop to handle multiple fds from the helper's
stderr and stdout. I don't think it unreasonable for them to do their own
logging to syslog for errors.

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

The helper is subject to the global login grace timeout (sshd_config
LoginGraceTime).

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

No - the shell environment is too complicated for something that can
be triggered before authentication.

-d

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

djm at mindrot

Oct 31, 2012, 1:01 AM

Post #5 of 14 (916 views)
Permalink

Re: AuthorizedKeysCommand support added [In reply to]

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

alex at alex

Oct 31, 2012, 1:27 AM

Post #6 of 14 (911 views)
Permalink

Re: AuthorizedKeysCommand support added [In reply to]

On 31 Oct 2012, at 08:01, Damien Miller wrote:

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

My concern was partly the LDAP case where (at least with the ldap patches)
it lets you if there is an account on the LDAP server. I'm not sure whether
there is some form of escalation opportunity here. I think with the
Match group thing, perhaps not. Can we guarantee that the username is
a string for which getpwnam returns an entry? If so, perhaps this isn't
a problem, as if admins permit users with | `` < > $ {} etc in, then they
deserve all they get if they don't write safe scripts. It would be useful
to document that the script can rely on the fact that $1 is a username
for which getpwnam returned something sometime in the recent past.

--
Alex Bligh

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Roman.Fiedler at ait

Oct 31, 2012, 1:58 AM

Post #7 of 14 (911 views)
Permalink

AW: AuthorizedKeysCommand support added [In reply to]

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

philipp.marek at linbit

Oct 31, 2012, 3:18 AM

Post #8 of 14 (911 views)
Permalink

Re: AuthorizedKeysCommand support added [In reply to]

Hello Damien,

thank you for your answer!

> > 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?)
>
> I want to keep this code simple, and don't want to have to implement
> yet another select() loop to handle multiple fds from the helper's
> stderr and stdout. I don't think it unreasonable for them to do their own
> logging to syslog for errors.
Yes, of course. See my shell-script remark below.

> > 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?
>
> The helper is subject to the global login grace timeout (sshd_config
> LoginGraceTime).
But I see no code that would kill the process then - only the authentication
would fail, right?

> > TBH, I can see the point that having a simple shell script inbetween -
> > that can do all of this, too.
>
> No - the shell environment is too complicated for something that can
> be triggered before authentication.
Sorry for being unclear, I meant setting CPU (and other) ulimits, STDERR
redirection and so on - these things can be done by a shell script.
(Even syslog, by using logger(1).)

Regards,

Phil
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

djm at mindrot

Oct 31, 2012, 8:55 AM

Post #9 of 14 (898 views)
Permalink

Re: AuthorizedKeysCommand support added [In reply to]

On Wed, 31 Oct 2012, Alex Bligh wrote:

>
> On 31 Oct 2012, at 08:01, Damien Miller wrote:
>
> >>
> >> 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.
>
> My concern was partly the LDAP case where (at least with the ldap patches)
> it lets you if there is an account on the LDAP server. I'm not sure whether
> there is some form of escalation opportunity here. I think with the
> Match group thing, perhaps not. Can we guarantee that the username is
> a string for which getpwnam returns an entry?

Yes.

> If so, perhaps this isn't
> a problem, as if admins permit users with | `` < > $ {} etc in, then they
> deserve all they get if they don't write safe scripts. It would be useful
> to document that the script can rely on the fact that $1 is a username
> for which getpwnam returned something sometime in the recent past.

I'd rather leave them paranoid if it encourages proper care :)

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

djm at mindrot

Oct 31, 2012, 8:57 AM

Post #10 of 14 (899 views)
Permalink

Re: AW: AuthorizedKeysCommand support added [In reply to]

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

djm at mindrot

Oct 31, 2012, 9:00 AM

Post #11 of 14 (896 views)
Permalink

Re: AuthorizedKeysCommand support added [In reply to]

On Wed, 31 Oct 2012, Philipp Marek wrote:

> > > 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?
> >
> > The helper is subject to the global login grace timeout (sshd_config
> > LoginGraceTime).
> But I see no code that would kill the process then - only the authentication
> would fail, right?

search for killpg in sshd.c

> > > TBH, I can see the point that having a simple shell script inbetween -
> > > that can do all of this, too.
> >
> > No - the shell environment is too complicated for something that can
> > be triggered before authentication.
> Sorry for being unclear, I meant setting CPU (and other) ulimits, STDERR
> redirection and so on - these things can be done by a shell script.
> (Even syslog, by using logger(1).)

Why not build them into the helper directly? It isn't someting that will be
need to be written more than once per backend directory.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Roman.Fiedler at ait

Oct 31, 2012, 9:14 AM

Post #12 of 14 (901 views)
Permalink

AW: AW: AuthorizedKeysCommand support added [In reply to]

Hi,

> -----Urspr�ngliche Nachricht-----
> Von: Damien Miller [mailto:djm [at] mindrot]
> An: Fiedler Roman
> Cc: openssh-unix-dev [at] mindrot
> Betreff: Re: AW: AuthorizedKeysCommand support added
>
> 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.

It would let you break in your own account if you just return your keys. Would spread harvoc if any fds from sshd other than stdout are open. I've just looked at the patch and are not quite sure if code might be vulnerable:

You are switching uids before close of fds>STDERR+1. Is it possible to attach to the script between setresuid and closefrom? If kernel allows that, this would give access to all open sshd fds.

To verify, I would have to check the specs or setup a test instance (or do you have one?)

> This is a risk of using
> the target user for the login script, which is something we explicitly
> recommend against.

OK, then documentation is quite important: if I understand it right, the default will be this unsafe mode, unless one uses AuthorizedKeysCommandUser

Roman
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

djm at mindrot

Oct 31, 2012, 1:44 PM

Post #13 of 14 (896 views)
Permalink

Re: AW: AW: AuthorizedKeysCommand support added [In reply to]

On Wed, 31 Oct 2012, Fiedler Roman wrote:

> > Well, it would let you break into your own account.
>
> It would let you break in your own account if you just return your
> keys. Would spread harvoc if any fds from sshd other than stdout are
> open. I've just looked at the patch and are not quite sure if code
> might be vulnerable:
>
> You are switching uids before close of fds>STDERR+1. Is it possible to
>attach to the script between setresuid and closefrom? If kernel allows
>that, this would give access to all open sshd fds.

No sane kernel allows ptrace of processes that have changed uid or gid
by the destination uid or gid.

> > This is a risk of using
> > the target user for the login script, which is something we explicitly
> > recommend against.
>
> OK, then documentation is quite important: if I understand it
> right, the default will be this unsafe mode, unless one uses
> AuthorizedKeysCommandUser

yes, though "unsafe" is relative here. It would be nice to have a dedicated
_ssh_helper account or somesuch that we could rely on to be the default.

Perhaps it would be better to ship with no default whatsoever but support
%u as an option.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

djm at mindrot

Nov 4, 2012, 3:16 AM

Post #14 of 14 (878 views)
Permalink

Re: AW: AW: AuthorizedKeysCommand support added [In reply to]

On Thu, 1 Nov 2012, Damien Miller wrote:

> > > This is a risk of using
> > > the target user for the login script, which is something we explicitly
> > > recommend against.
> >
> > OK, then documentation is quite important: if I understand it
> > right, the default will be this unsafe mode, unless one uses
> > AuthorizedKeysCommandUser
>
> yes, though "unsafe" is relative here. It would be nice to have a dedicated
> _ssh_helper account or somesuch that we could rely on to be the default.
>
> Perhaps it would be better to ship with no default whatsoever but support
> %u as an option.

I just committed this - there is no default AuthorizedKeysCommandUser now;
admins are required to specify one. Hopefully they'll pick a good one :)

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads