On Sat, 2 Apr 2022 at 09:02, Al <allogenes@xxxxxxxxxx> 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@xxxxxxxxxxx, Address 123.123.0.0/16
> AllowGroups ssh-cert-users
> Match PubkeyType sk-ssh-ed25519@xxxxxxxxxxx, 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@xxxxxxxxxxx
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@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
