openssh unix dev - Apr 2022 - Match PubkeyType (sshd_config feature request)

Hey there,

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


For background, I already have something like this:

```
AllowGroups     public-ssh

Match Address 127.0.0.0/16,localhost,192.168.0.0/16,10.1.0.0/24
AllowGroups     private-ssh root
PermitRootLogin prohibit-password

Match Address 10.0.0.0/8
AllowGroups     private-ssh
```

So, someone in the private-ssh group usually needs to proxyjump through a
public-ssh user (which has a very restricted account.) Now I want to relax it so
that the private-sshers can bypass proxyjumping so long as they have a cert.

I thought about something like this:

```
Match Group ssh-cert-users
PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01 at openssh.com
```

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

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

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.

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

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?

Al

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.