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 at 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).
>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 at 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 at 10.0.0.1: Permission denied (publickey).
On Wed, Feb 3, 2021 at 2:48 PM Wim S <wimsharing at 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.