On Tue, 2019-06-25 at 18:22 +0100, Erik Johnston wrote: > Hey everyone, > > Basically, I'm trying to figure out if I can configure sshd to > require that the user has a key that has been signed by a trusted > user CA *and* is listed separately as an authorised key (or the user > has a signed key and a different authorised key)? > > The closest I've come is having an `authorized_keys` file have two > entries consisting of the CA key and a normal key with > `AuthenticationMethods: publickey,publickey` option set, so that sshd > requires that a user produces both the normal key and a signed key. > This works, but means a user can't then have multiple keys (e.g. one > per device), and feels somewhat brittle in that adding a key to that > file breaks the requirement that the user presents a signed key. > > The motivation behind this is that I've been looking at using a self- > service cert authority that lets users get their keys signed by the > CA in a restricted way, e.g. be IP locked, have expiry times, > requires third party approval to get access to certain hosts, etc. > However, I'm uncomfortable having a single server have the CA cert, > since if the box gets owned they get credentials to access > everything. Hence wondering if we could require having both a valid > key *and* a valid signature from the CA, as then having the cert by > itself is useless. > > Thoughts and suggestions welcome, including that this sounds like a > terrible idea and I'm doing it wrong. As already said, there is no simple way to do this in OpenSSH itself. But since few releases back, the OpenSSH can publish [1] what authentication was used in OpenSSH for PAM, which can in the end do the final decision whether the authentication was valid or not (two public keys or one of the valid certificate). This was implemented by the guys from CERN primarily for 2fa, but I think this can do also for you with some tweaks. [1] https://bugzilla.mindrot.org/show_bug.cgi?id=2408 Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
