Mailing List Archive

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@openssh.com, Address 123.123.0.0/16
AllowGroups ssh-cert-users

Match PubkeyType sk-ssh-ed25519@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@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@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Match PubkeyType (sshd_config feature request) [ In reply to ]
On Sat, 2 Apr 2022 at 09:02, Al <allogenes@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@openssh.com, Address 123.123.0.0/16
> AllowGroups ssh-cert-users
> Match PubkeyType sk-ssh-ed25519@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@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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Match PubkeyType (sshd_config feature request) [ In reply to ]
Hey Darren,

Thanks for the explanations, I appreciate it. And no worries, I'll try another approach.

Al
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Match PubkeyType (sshd_config feature request) [ In reply to ]
On Sat, 2 Apr 2022, Al wrote:

> Hey Darren,
>
> Thanks for the explanations, I appreciate it. And no worries, I'll try another
> approach.

Being able to express richer policy around public key authentication is
something that a few people have asked for. I'd love to find a way to
do it...
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev