On Tue, Mar 02, 2021 at 04:17:28PM -0800, Michael Thomas wrote: > > Now, maybe you have something different in mind. > > I'm talking about the server side sshd just fetching the associated ssh keys > with the user trying to log in, maybe with some authz sprinkled in for finer > granularity. It could be LDAP, it could whatever you want. I don't know how > configurable sshd is, so that might limit your choices. I wouldn't want to do this. It's much more complex than the client sending a certificate. And getting their public key(s) (they will almost certainly have more than one, and many ephemeral) into the directory is the equivalent of getting a certificate issued. So you're not saving anything, and you're adding complexity, and if you're using LDAP you're not even getting rid of x.500 or ASN.1. > I'm just using LDAP as an example of a well known corpro directory. It could > be anything. It just needs to be something online that can store the name > public key(s) binding so that the sshd can see if they should allow that > user/key to log in. It can't be anything. It has to be standard-enough. > > The client is also a relying party though, since it has to authenticate > > the server. > > If you care about that, I suppose. I think most people do the leap of faith > and known_hosts ignores the problem. I very much care about that. Certainly in a corporate network. > I don't see how doing nothing at all on the client can be "infinitely > easier" than doing a lot of something else. [...] It's not nothing. New keys? Update the directory. Same complexity as getting keys certified, only worse because the online CA only needs to be online when you want new keys / certs, but the directory has to be online any time you want to use those keys. > Is anybody using PKINIT? Yes. Nico --
