openssh unix dev - Jan 2018 - SSH cert extensions and authz key options

HI!

I'm looking at sshd(8), section AUTHORIZED_KEYS FILE FORMAT and
description for CLI arg -O in ssh-keygen(1).

It seems to me that there could be a 1:1 mapping between SSH cert
extensions and authz key options by just adding prefix "permit-" to
the
key option.

But the man pages differ regarding case of "permit-x11-forwarding" and
"X11-forwarding". [1] also says "permit-X11-forwarding". So
it might
only be typo in ssh-keygen(1).

Questions:

Is there a guaranteed 1:1 mapping between SSH cert extensions and authz
key options?

Are SSH cert extensions and authz key options treated case-insensitive?
[1] does not say anything about this.

Background:
I want to let admins specify SSH key options / cert extension in user
entries in the directory and use the same values for issuing short-term
SSH certs (prefixed with "permit-") and distribute authorized keys
(for
platforms without SSH cert support).

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180112/b5b2e288/attachment.p7s>

On Fri, 12 Jan 2018, Michael Str?der wrote:
> HI!
> 
> I'm looking at sshd(8), section AUTHORIZED_KEYS FILE FORMAT and
> description for CLI arg -O in ssh-keygen(1).
> 
> It seems to me that there could be a 1:1 mapping between SSH cert
> extensions and authz key options by just adding prefix "permit-"
to the
> key option.
No, they are separate namespaces that happen to share similar options.
> But the man pages differ regarding case of
"permit-x11-forwarding" and
> "X11-forwarding". [1] also says
"permit-X11-forwarding". So it might
> only be typo in ssh-keygen(1).
"permit-x11-forwarding" may appear in a certificate extension.

"x11-forwarding" may appear in authorized_keys, but doesn't make
any
sense unless preceeded by a "restrict" keyword.
> Questions:
> 
> Is there a guaranteed 1:1 mapping between SSH cert extensions and authz
> key options?
No. E.g. there is no "restrict" option for certs because permissions
are explicit in certificates and (mostly) implicit in the older
authorized_keys format.

If I were writing the authorized_keys file format today then I'd make it
explicit like the cert options/extensions are now...
> Are SSH cert extensions and authz key options treated case-insensitive?
> [1] does not say anything about this.
Cert extensions are case sensitive

authorized_keys options aren't.

-d

Damien,

your advice is appreciated.

Damien Miller wrote:
> On Fri, 12 Jan 2018, Michael Str?der wrote:
>> I'm looking at sshd(8), section AUTHORIZED_KEYS FILE FORMAT and
>> description for CLI arg -O in ssh-keygen(1).
>>
>> It seems to me that there could be a 1:1 mapping between SSH cert
>> extensions and authz key options by just adding prefix
"permit-" to the
>> key option.
> 
> No, they are separate namespaces that happen to share similar options.
Hmm...
>> But the man pages differ regarding case of
"permit-x11-forwarding" and
>> "X11-forwarding". [1] also says
"permit-X11-forwarding". So it might
>> only be typo in ssh-keygen(1).
> 
> "permit-x11-forwarding" may appear in a certificate extension.
> 
> "x11-forwarding" may appear in authorized_keys, but doesn't
make any
> sense unless preceeded by a "restrict" keyword.
Maybe I was not clear enough what I want to achieve.

I'd like to have a limited set of permissions (not exclusions!) in my
user management database and _transform_ this set of permission to
certificate extensions and authorized_keys options.
>> Is there a guaranteed 1:1 mapping between SSH cert extensions and authz
>> key options?
> 
> No. E.g. there is no "restrict" option for certs because
permissions
> are explicit in certificates and (mostly) implicit in the older
> authorized_keys format.
Of course I'd prefix with "restrict" keyword and have only
permissions
added to authorized_keys options to achieve having only explicit
permissions also therein.
> If I were writing the authorized_keys file format today then I'd make
it
> explicit like the cert options/extensions are now...
I have to look for my time machine...?
Better not. ;-)
>> Are SSH cert extensions and authz key options treated case-insensitive?
>> [1] does not say anything about this.
> 
> Cert extensions are case sensitive
> 
> authorized_keys options aren't.
Sorry for nitpicking some more:

Man page ssh-keygen(1) -O says lower-case "permit-x11-forwarding" [1]
but certificate format spec [2] says mixed-case
"permit-X11-forwarding".
So the former is the command-line option and the latter goes literally
into the cert? Sorry, this is a bit confusing.

Also [2] says that options and extensions have to be "lexically
ordered". What does that mean exactly regarding the case?

E.g. in Python it makes a difference sorting case-sensitive or
case-insensitive because capital letters are considered lower. Same in
OpenSSH code?

$ python3
Python 3.6.4 (default, Jan 03 2018, 13:52:55) [GCC] on linux
Type "help", "copyright", "credits" or
"license" for more information.
>>>
sorted(['permit-port-forwarding','permit-X11-forwarding','permit-pty'])
['permit-X11-forwarding', 'permit-port-forwarding',
'permit-pty']
>>>
sorted(['permit-port-forwarding','permit-X11-forwarding','permit-pty'],
key=str.lower)
['permit-port-forwarding', 'permit-pty',
'permit-X11-forwarding']

Ciao, Michael.

[1] https://man.openbsd.org/ssh-keygen.1#permit-x11-forwarding

[2]
https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.certkeys

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180124/18075860/attachment.p7s>