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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev