Mailing List Archive

On Wed, Feb 3, 2021 at 4:32 AM Wim S <wimsharing@gmail.com> wrote:

> I don't seem to find a way to specify that one of the pubkey in
> AuthenticationMethods pubkey,pubkey should be a valid ssh certificate.
>
> Is there maybe any other way to enforce this ?

it looks like there are a number of ways you can do this:

1. You can set TrustedUserCAKeys to a valid ca pubkey file and set
AuthorizedKeysFile to something like /etc/ssh/empty

2. You can set PubkeyAcceptedKeyTypes to a cert type.

I think both of these will work either globally or in a Match block.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

>it looks like there are a number of ways you can do this:
>
> 1. You can set TrustedUserCAKeys to a valid ca pubkey file and set
>AuthorizedKeysFile to something like /etc/ssh/empty
>
> 2. You can set PubkeyAcceptedKeyTypes to a cert type.
>
>I think both of these will work either globally or in a Match block.

Yes, spot on. These are the relevant stanzas from my sshd_config on a box where I mix certificates for the git user with regular keypair auth for other users:

```
AuthorizedPrincipalsFile /etc/ssh/principals/%u
TrustedUserCAKeys /etc/ssh/ca.pub

AllowGroups public-ssh
AuthorizedKeysFile none
AuthorizedKeysCommand /sbin/authorized_keys
AuthorizedKeysCommandUser nobody

AuthenticationMethods publickey
PubkeyAuthentication yes

Match Address 10.0.0.0/8
AllowGroups private-ssh root
PermitRootLogin prohibit-password

Match User git
PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
```
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hm, I don't want to mix them, I want to use the AuthenticationMethods
feature that enforces that the user must have 1 certificate and 1
normal pubkey to be authenticated.
(I don't think that's possible with your suggestions?)

At the moment, users can just put multiple keys in the
~/.ssh/authorized_keys. If they for example put 2 pubkeys there, they
can access the system because the AuthenticationMethods pubkey,pubkey
rule is satisfied.

But I want to have a rule that one of those 2 pubkeys *must* be a
certificate, so the user uses 1 certificate and 1 normal pubkey
instead of 2 normal pubkeys.

Wim


Op wo 3 feb. 2021 om 22:49 schreef asymptosis <asymptosis@posteo.net>:
>
> >it looks like there are a number of ways you can do this:
> >
> > 1. You can set TrustedUserCAKeys to a valid ca pubkey file and set
> >AuthorizedKeysFile to something like /etc/ssh/empty
> >
> > 2. You can set PubkeyAcceptedKeyTypes to a cert type.
> >
> >I think both of these will work either globally or in a Match block.
>
> Yes, spot on. These are the relevant stanzas from my sshd_config on a box where I mix certificates for the git user with regular keypair auth for other users:
>
> ```
> AuthorizedPrincipalsFile /etc/ssh/principals/%u
> TrustedUserCAKeys /etc/ssh/ca.pub
>
> AllowGroups public-ssh
> AuthorizedKeysFile none
> AuthorizedKeysCommand /sbin/authorized_keys
> AuthorizedKeysCommandUser nobody
>
> AuthenticationMethods publickey
> PubkeyAuthentication yes
>
> Match Address 10.0.0.0/8
> AllowGroups private-ssh root
> PermitRootLogin prohibit-password
>
> Match User git
> PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
> ```
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

>But I want to have a rule that one of those 2 pubkeys *must* be a
>certificate, so the user uses 1 certificate and 1 normal pubkey
>instead of 2 normal pubkeys.

Ah, I see. I'm not sure about that, perhaps it cannot be done.

What's the reason for doing this? You don't increase security by imposing more layers of the same factor. Security is increased by imposing multiple factors, such as requiring a key and restricting logins to only whitelisted IP addresses. A key and a cert are both basically the same type of factor (something-you-have).
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

It's actually 2 factors in our setup, the ssh certificate is created
using MFA (and have a short lifetime), and the pubkey is the users own
private key.

This prevents getting into the system if you have control of the MFA
setup (which is handled by another team) or getting into the system
without MFA :-)

Op wo 3 feb. 2021 om 23:43 schreef asymptosis <asymptosis@posteo.net>:
>
> >But I want to have a rule that one of those 2 pubkeys *must* be a
> >certificate, so the user uses 1 certificate and 1 normal pubkey
> >instead of 2 normal pubkeys.
>
> Ah, I see. I'm not sure about that, perhaps it cannot be done.
>
> What's the reason for doing this? You don't increase security by imposing more layers of the same factor. Security is increased by imposing multiple factors, such as requiring a key and restricting logins to only whitelisted IP addresses. A key and a cert are both basically the same type of factor (something-you-have).
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

>It's actually 2 factors in our setup, the ssh certificate is created
>using MFA (and have a short lifetime), and the pubkey is the users own
>private key.
>
>This prevents getting into the system if you have control of the MFA
>setup (which is handled by another team) or getting into the system
>without MFA :-)

My understanding was the certificate can only be used in conjunction with the user's private key anyway? So I think what you're after already happens automatically.

Eg I have a user set up like this:

$ ls .ssh
config id_ed25519 id_ed25519-cert.pub id_ed25519.pub known_hosts

$ cat .ssh/config
Host repos
User git
Hostname 10.0.0.1
PasswordAuthentication no
PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01@openssh.com
StrictHostKeyChecking accept-new
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes

When I move the id_ed25519 out of ~/.ssh, I get permission denied:

$ ssh repos
no such identity: <home-directory>/.ssh/id_ed25519: No such file or directory
git@10.0.0.1: Permission denied (publickey).
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Wed, Feb 3, 2021 at 2:48 PM Wim S <wimsharing@gmail.com> wrote:

> This prevents getting into the system if you have control of the MFA
> setup (which is handled by another team) or getting into the system
> without MFA :-)

heh, seems like you all have trust issues :)

more seriously though, without over-engineering this, you I *think*
you could do something like

AuthenticationMethods publickey,publickey
TrustedUserCAKeys /etc/ssh/trusted_user_ca.pub
AuthorizedKeysFile none
AuthorizedKeysCommand /pull/a/single/key %h/.ssh/authorized_keys
AuthorizedKeysCommandUser nobody

and then /pull/a/single/key looks like

#!/bin/bash
head -1 $1

or you could store the pubkeys somewhere the user can't control, like
ldap, and use an authorizedkeyscommand to fetch them.

I agree though, if a publickey:certificate option existed, it'd be a
lot cleaner.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Wed, Feb 3, 2021 at 2:55 PM asymptosis <asymptosis@posteo.net> wrote:

> My understanding was the certificate can only be used in conjunction with the user's private key anyway? So I think what you're after already happens automatically.

I'd guess the certificate is based on a keypair the user doesn't
control, eg. it's created by the CA when the user auths. so the cert
key and the non-cert key are distinct.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Well, for our setup we use first oidc to authenticate to (hashicorp)
vault, this oidc entrypoint is protected by mfa, so the user auths and
gets a time limited vault token.
We now generate a new priv/pub keypair, then we're using the previous
vault token to again authenticate with vault, this time to the
ssh-signing endpoint where we upload the pubkey for signing, so we get
a (shortlived) certificate back.
Now the user can login on the servers using the (generated) privkey/certificate

All of the above flow (except the final logging in) is done
automatically with our own windows/linux ssh-agent :-)

(sorry for the double message Peter)

Op do 4 feb. 2021 om 00:01 schreef Peter Moody <mindrot@hda3.com>:
>
> On Wed, Feb 3, 2021 at 2:55 PM asymptosis <asymptosis@posteo.net> wrote:
>
> > My understanding was the certificate can only be used in conjunction with the user's private key anyway? So I think what you're after already happens automatically.
>
> I'd guess the certificate is based on a keypair the user doesn't
> control, eg. it's created by the CA when the user auths. so the cert
> key and the non-cert key are distinct.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

I thought of something similar, but the user said "but I want to have
multiple ssh keys because I use different keys on different devices"
:/

Op wo 3 feb. 2021 om 23:59 schreef Peter Moody <mindrot@hda3.com>:
>
> On Wed, Feb 3, 2021 at 2:48 PM Wim S <wimsharing@gmail.com> wrote:
>
> > This prevents getting into the system if you have control of the MFA
> > setup (which is handled by another team) or getting into the system
> > without MFA :-)
>
> heh, seems like you all have trust issues :)
>
> more seriously though, without over-engineering this, you I *think*
> you could do something like
>
> AuthenticationMethods publickey,publickey
> TrustedUserCAKeys /etc/ssh/trusted_user_ca.pub
> AuthorizedKeysFile none
> AuthorizedKeysCommand /pull/a/single/key %h/.ssh/authorized_keys
> AuthorizedKeysCommandUser nobody
>
> and then /pull/a/single/key looks like
>
> #!/bin/bash
> head -1 $1
>
> or you could store the pubkeys somewhere the user can't control, like
> ldap, and use an authorizedkeyscommand to fetch them.
>
> I agree though, if a publickey:certificate option existed, it'd be a
> lot cleaner.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

What other %-tokens are available with AuthorizedKeysCommand? Could you pass one or more of them to /pull/a/single/key in order to enable a single key that differs per user or per client host or whatever the criteria are?

> On Feb 3, 2021, at 15:21, Wim S <wimsharing@gmail.com> wrote:
>
> ?I thought of something similar, but the user said "but I want to have
> multiple ssh keys because I use different keys on different devices"
> :/
>
> Op wo 3 feb. 2021 om 23:59 schreef Peter Moody <mindrot@hda3.com>:
>>
>>> On Wed, Feb 3, 2021 at 2:48 PM Wim S <wimsharing@gmail.com> wrote:
>>>
>>> This prevents getting into the system if you have control of the MFA
>>> setup (which is handled by another team) or getting into the system
>>> without MFA :-)
>>
>> heh, seems like you all have trust issues :)
>>
>> more seriously though, without over-engineering this, you I *think*
>> you could do something like
>>
>> AuthenticationMethods publickey,publickey
>> TrustedUserCAKeys /etc/ssh/trusted_user_ca.pub
>> AuthorizedKeysFile none
>> AuthorizedKeysCommand /pull/a/single/key %h/.ssh/authorized_keys
>> AuthorizedKeysCommandUser nobody
>>
>> and then /pull/a/single/key looks like
>>
>> #!/bin/bash
>> head -1 $1
>>
>> or you could store the pubkeys somewhere the user can't control, like
>> ldap, and use an authorizedkeyscommand to fetch them.
>>
>> I agree though, if a publickey:certificate option existed, it'd be a
>> lot cleaner.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 03/02/21, Jim Knoble (jmknoble@pobox.com) wrote:
> What other %-tokens are available with AuthorizedKeysCommand? Could
> you pass one or more of them to /pull/a/single/key in order to enable
> a single key that differs per user or per client host or whatever the
> criteria are?

AuthorizedKeysCommand accepts the tokens %%, %f, %h, %k, %t, %U, and %u.
That is, the key/certificate fingerprint, home directory of the user,
base64 key or certificate key, key type, numeric user id or username.

Although this probably isn't appropriate for Wim's use-case, the use of
certificate principals could be considered. One can use the
AuthorizedPrincipalsCommand, AuthorizedPrincipalsCommandUser and
AuthorizedPrincipalsFile to control access based on the permitted
principal names specified in a certificate.

Additionally user identification can be embedded in a certificate.

I guess if one trusts the certificate issuer to only issue certificates
to valid public key holders, and where the certificate is scoped by
principal, the requirement to also validate the original public key on
the target ssh host falls away.

Regretfully, I've been unable to convince my team to trust the use of
certificates sufficiently to do this(!)

Rory
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev