AuthorizedKeysCommand

[Katsumoto san]

Hi there,

We could set AuthorizedKeysCommand script, this will allow only to replace
authorized_keys file with keys stored in a database... But why this command
is so limited?

Why i can't just set a command script which will get a username and public
key as arguments and let him do it's own authorization??
I think this will allow for much more powerful tricks. For example do to an
database lookup with keys to identify and authorize or deny access and so
on...

So is this so difficult to do? What do you all think about this?

Thanks.
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Daniel Kahn Gillmor]

On 01/14/2013 10:36 AM, Katsumoto san wrote:
> We could set AuthorizedKeysCommand script, this will allow only to replace
> authorized_keys file with keys stored in a database... But why this command
> is so limited?
>
> Why i can't just set a command script which will get a username and public
> key as arguments and let him do it's own authorization??

It sounds to me like you're proposing a different interface than the
current AuthorizedKeysCommand -- the current interface maps quite
cleanly to the AuthorizedKeysFile, and can be processed in a similar way
by ssh (it's just reading the list of authorized keys from a different
kind of file descriptor).

What you're proposing sounds rather different (but i agree it could be
useful). It's more of a KeyAuthorizationCommand (since it takes a
single key and decides whether it is authorized) than an
AuthorizedKeysCommand.

But note that an ssh client can offer several keys to the ssh server [0]
to see which ones might be acceptable. So the command you describe
might need to be invoked several times per attempted connection.

Maybe you could propose a concrete specification for what you want? How
would the public key and user account be structured as arguments to the
command?

> I think this will allow for much more powerful tricks. For example do to an
> database lookup with keys to identify and authorize or deny access and so
> on...

Note that the current API can still do a database lookup by the user
account, as long as the database is able to enumerate the keys that are
acceptable for authorizing access.

--dkg

[0] https://tools.ietf.org/html/rfc4252#section-7

[Bostjan Skufca]

Seems very useful.

Implementation-wise I would not exclude AuthorizedKeysFile if
AuthorizedKeysCommand was present, because if script will be connecting to
external services which mail fail or hang, one still needs access to
machine in case of emergency.
In this respect, execution of external command should be time-limited to
avoid locking admin out of the system in troubled times.

b.

[Iain Morgan]

On Mon, Jan 14, 2013 at 09:36:26 -0600, Katsumoto san wrote:
> Hi there,
>
> We could set AuthorizedKeysCommand script, this will allow only to replace
> authorized_keys file with keys stored in a database... But why this command
> is so limited?
>
> Why i can't just set a command script which will get a username and public
> key as arguments and let him do it's own authorization??
> I think this will allow for much more powerful tricks. For example do to an
> database lookup with keys to identify and authorize or deny access and so
> on...
>
> So is this so difficult to do? What do you all think about this?
>

I believe the intent was to minimize the risks by keeping the
implementation simple. However, you can embed some flexibility either
in the command which you invoke or, potentiall, in the repository used
to store the keys.

I don't quite see the advantage of the approach that you are suggesting.
Could you elaborate on it a bit? What sort of "tricks" are you thinking
of?

--
Iain Morgan

[Damien Miller]

On Mon, 14 Jan 2013, Katsumoto san wrote:

> Hi there,
>
> We could set AuthorizedKeysCommand script, this will allow only to replace
> authorized_keys file with keys stored in a database... But why this command
> is so limited?

The output of AuthorizedKeysCommand may contain any directive that is
allowed in authorized_keys, so it's actually quite powerful.

> Why i can't just set a command script which will get a username and public
> key as arguments and let him do it's own authorization??
> I think this will allow for much more powerful tricks. For example do to an
> database lookup with keys to identify and authorize or deny access and so
> on...

You'll have to explain this example more, because it seems to me that this
is well within the capabilities of the current AuthorizedKeysCommand.

-d

[Alan Barrett]

On Tue, 15 Jan 2013, Damien Miller wrote:
> You'll have to explain this example more, because it seems to
> me that this is well within the capabilities of the current
> AuthorizedKeysCommand.

Imagine that the result from "select authorized_keys_line from
database where username = {x}" was so large that you did not
want to process that much data. Then the ability to say "select
authorized_keys_line from database where (username = {x} AND key
= {y})" would be helpful. To be able to take advantage of that,
the AuthorizedKeysCommand would have to be passed the key as a
parameter.

--apb (Alan Barrett)

[Shogun]

Yes, i agree, this is also important.

14.01.13 19:00, Bostjan Skufca ?????:

> Seems very useful.
>
> Implementation-wise I would not exclude AuthorizedKeysFile if
> AuthorizedKeysCommand was present, because if script will be
> connecting to external services which mail fail or hang, one still
> needs access to machine in case of emergency.
> In this respect, execution of external command should be time-limited
> to avoid locking admin out of the system in troubled times.
>
> b.
>
>
> On 14 January 2013 16:36, Katsumoto san <shog...@gmail.com

> <mailto:shog...@gmail.com>> wrote:
>
> Hi there,
>
> We could set AuthorizedKeysCommand script, this will allow only to
> replace
> authorized_keys file with keys stored in a database... But why
> this command
> is so limited?
>
> Why i can't just set a command script which will get a username
> and public
> key as arguments and let him do it's own authorization??
> I think this will allow for much more powerful tricks. For example
> do to an
> database lookup with keys to identify and authorize or deny access
> and so
> on...
>
> So is this so difficult to do? What do you all think about this?
>
> Thanks.
> _______________________________________________
> openssh-unix-dev mailing list

> openssh-...@mindrot.org <mailto:openssh-...@mindrot.org>

[Shogun]

14.01.13 21:22, Iain Morgan пишет:

> On Mon, Jan 14, 2013 at 09:36:26 -0600, Katsumoto san wrote:
>> Hi there,
>>
>> We could set AuthorizedKeysCommand script, this will allow only to
replace
>> authorized_keys file with keys stored in a database... But why this
command
>> is so limited?
>>
>> Why i can't just set a command script which will get a username and
public
>> key as arguments and let him do it's own authorization??
>> I think this will allow for much more powerful tricks. For example
do to an
>> database lookup with keys to identify and authorize or deny access
and so
>> on...
>>
>> So is this so difficult to do? What do you all think about this?
>>
> I believe the intent was to minimize the risks by keeping the
> implementation simple. However, you can embed some flexibility either
> in the command which you invoke or, potentiall, in the repository used
> to store the keys.
>
> I don't quite see the advantage of the approach that you are suggesting.
> Could you elaborate on it a bit? What sort of "tricks" are you thinking
> of?

More flexible doesn't mean more difficult or risky.
The advantages is like you've said flexibility, a lot of flexibility.
The users may write custom acl's and so on... why to limit them? For ex.
Github uses his own patched ssh which allow to lookup a database for pub
keys, this allow to users access repos with
g...@github.com:username/repository, so git "namespace" for many users...
and many more advantages allowed by this approach.

[Shogun]

14.01.13 18:22, Daniel Kahn Gillmor пишет:

> On 01/14/2013 10:36 AM, Katsumoto san wrote:
>> We could set AuthorizedKeysCommand script, this will allow only to
replace
>> authorized_keys file with keys stored in a database... But why this
command
>> is so limited?
>>
>> Why i can't just set a command script which will get a username and
public
>> key as arguments and let him do it's own authorization??
> It sounds to me like you're proposing a different interface than the
> current AuthorizedKeysCommand -- the current interface maps quite
> cleanly to the AuthorizedKeysFile, and can be processed in a similar way
> by ssh (it's just reading the list of authorized keys from a different
> kind of file descriptor).

Yes, like i've said AuthorizedKeysCommand now is almost like a
simulation of AuthorizedKeysFile.

> What you're proposing sounds rather different (but i agree it could be
> useful). It's more of a KeyAuthorizationCommand (since it takes a
> single key and decides whether it is authorized) than an
> AuthorizedKeysCommand.

Yes is not what now AuthorizedKeysCommand does, this could be named
different (not so important), i've just expected from this command to
work so.

>
> But note that an ssh client can offer several keys to the ssh server [0]
> to see which ones might be acceptable. So the command you describe
> might need to be invoked several times per attempted connection.
>
> Maybe you could propose a concrete specification for what you want? How
> would the public key and user account be structured as arguments to the
> command?
>

I'm not sure if client send all this keys at once or not, but if so will
be good i think to run script one time and get all the keys as "array",
also the script should get the username.
Now command script could access $SSH_ORIGINAL_COMMAND from env so this
data may also set there, or maybe pass as script arguments ...

>> I think this will allow for much more powerful tricks. For example
do to an
>> database lookup with keys to identify and authorize or deny access
and so
>> on...
> Note that the current API can still do a database lookup by the user
> account, as long as the database is able to enumerate the keys that are
> acceptable for authorizing access.

This is also limited to the username. What if we have only a user for ex
'git' accessed by many users? So we need to identify them by pub keys
like Github does. This also will allow more flexibility on controlling
this action, custom acl's and so on...
> --dkg
>
> [0] https://tools.ietf.org/html/rfc4252#section-7

[Peter Stuge]

Shogun wrote:
> I'm not sure if client send all this keys at once or not

It does not.

> Now command script could access $SSH_ORIGINAL_COMMAND from env so
> this data may also set there, or maybe pass as script arguments ...

Please look into the SSH protocol. It is not known at authentication
time what the remote user wants to do once they have been authenticated.


//Peter

[Damien Miller]

On Tue, 15 Jan 2013, Alan Barrett wrote:

> On Tue, 15 Jan 2013, Damien Miller wrote:
> > You'll have to explain this example more, because it seems to me that this
> > is well within the capabilities of the current AuthorizedKeysCommand.
>
> Imagine that the result from "select authorized_keys_line from
> database where username = {x}" was so large that you did not
> want to process that much data. Then the ability to say "select
> authorized_keys_line from database where (username = {x} AND key =
> {y})" would be helpful. To be able to take advantage of that, the
> AuthorizedKeysCommand would have to be passed the key as a parameter.

Thanks, that's a good example. Would passing the entire public key on
the commandline be preferable to just passing the fingerprint?

-d