Match PubkeyType (sshd_config feature request)

[Darren Tucker]

On Sat, 2 Apr 2022 at 09:02, Al <allogenes at posteo.net> wrote:
> I've got another feature request :) I would like to be able to add something which looks like this to sshd_config:
> Match PubkeyType ssh-ed25519-cert-v01 at openssh.com, Address 123.123.0.0/16
> AllowGroups ssh-cert-users
> Match PubkeyType sk-ssh-ed25519 at openssh.com, Address 234.234.0.0/16
> AllowGroups ssh-yubikey-users

There isn't really a mechanism in Match to implement this.  The way
Match works is that it updates the effective config at two points in
time: once as soon as the connection is received (ie the source
address is known) and once when the client sends the username.

Public-key authentication attempts do not happen until later in the
protocol.   For a given connection there may be zero or more pubkey
attempts of varying types (potentially requiring multiple of them,
although OpenSSH does not currently implement this).

[...]
> But then (iiuc) they still won't be able to log in unless you give the match an AllowGroup:
> Match Group ssh-cert-users
> AllowGroup ssh-cert-users
> PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01 at openssh.com

This should work.

> Which seems circular ... allow the group if they're in the group, what?

AllowGroups (and AllowUsers) are much simpler mechanisms compared to
Match and predate it by a decade or more.  Interactions like the one
above are ... awkward, although some other interactions read more
sensibly, eg:

Match Address 10.0.0.0/8
    AllowGroups internal-users

With a small addition of a boolean "AllowLogin yes/no" Match could be
a functional superset of AllowUsers/AllowGroups:

AllowLogin no
Match Address 10.0.0.0/8 Group somegroup
    AllowLogin yes

but since it wouldn't allow you to do anything you can't already do
with AllowUsers/AllowGroups it hasn't made it to the top of a to-do
list.

> And there are other possible complications, like what if they are in both ssh-cert-users and ssh-private, and they use different keys for different purposes? "Match Group" doesn't seem to provide the required flexibility.

Match operates on a first-match basis so you could put the least
restrictive group first, or you could have a Match line with two Group
predicates followed by lines specifying the union of the allowed
behaviours, followed by two single Match Group's with their respective
individual behaviours.

> There could be other uses too, like before transitioning to a pure cert/sk setup, you can Match deprecated key types to provide those users with a Banner warning. "We will be disabling ssh-rsa and ssh-ed25519 on 2022-06-30. Please remember to switch to sk keys before then."

That could be done now with ExposeAuthInfo and a couple of lines in
the shell startup script.

> So after circling around the problem for a while, I keep coming back to the same idea: it would be cool to be able to match the incoming key type, as I see a few interesting uses for this.
>
> Do you think it would be doable?

Probably not.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.