On Sun, Dec 24, 2017 at 9:54 PM, David Newall <openssh@xxxxxxxxxxxxxxx> wrote: > On 25/12/17 00:11, John Devitofranceschi wrote: >> >> Besides ssh.com’s PrivX product, has anyone created a web service that can >> be used to issue temporary certkeys to authenticated users? >> >> Any pointers appreciated! > > > I expect that what I'm about to say is exactly what you're not interested in > hearing, but I think it's something that should be said nonetheless. > > The benefit of a central authority issuing a key so that a user can > authenticate himself or herself with it is dubious at best. please take my following comments as coming from someone who spends his days securing ssh for an enterprise. thousands of users * 10's of thousands of machines; I have a strong interest in centralization. > First, it's backwards. The principle of user authentication is that users > should be free to choose their own password with which to secure their > access, and that these passwords should be secrets known only to the > individual users. This is one reason why passwords are not stored. A > public/private key pair is an alternative form of password, but, still, > users should be free to generate their own keys, which they use to say, > "this is me." If a central authority generates the keys, then they are > effectively saying, "this is you." It's just backwards. in an enterprise, I don't trust what the user chooses for a password or a key. > Second, it is more easily compromised. Here's why: the act of generating a > public and private key pair is approximately as secure if a user generates > them or if a central authority generates them, and the act of transmitting > half of the pair can be approximately as secure transmitting one or the > other. But, that's not to say that transmitting the key is without risk. > Somebody could intercept the transmission and take a copy of the key. If > it's a public key then nothing of great value has been obtained. If it's a > private key then the veracity of authentication is completely compromised. > The public key should be sent from user to server; the private key must not > be sent from server to user. this might be true if ssh weren't an encrypted transport. but a client can easily forward their ssh agent to a certificate distributing server and, over an encrypted channel, receive both a private and public key. > Third, it doesn't scale. If every SSH server generated keys (or had them > generated on their user's behalf), then every user would need as many keys > as SSH servers that they used. That's an n-squared growth of keys. If > users generate their own keys, they can use the same private key for all > servers, if that's what they want. That's a linear growth of keys (grows by > number of users, not number of servers.) for an enterprise, this is precisely wrong. with certkeys, you distribute a single pubkey to every host and all users with certs signed by the corresponding private key get access. this is the opposite of needing to distribute the pukeys of N-users on M-machines. > Fourth, it's putting faith in a demonstrably untrustworthy party. I'm not > saying that PrivX, to use your example, cannot be trusted; I'm saying that > no central authority can be trusted. So many have been compromised that the > only rational assumption is that none can be trusted. Each user has his or > her own security standard, and I'm willing to accept that a central > authority is less likely to be compromised than a single user, but > compromising a central authority breaks the security of all of its users, > not just of a single user. > > For these reasons I advise do not use a web service to create the keys that > users can and should create for themselves. There is nothing that I can see > such a service offering that is of any real value, and there is much damage > that can be wreaked by them. I would agree that using a random service for signing certs is a bad idea. thankfully there are a few full featured opensource ssh CA's already available. I have it on good authority that another is going to be released in the near future as well. > The particular question was about temporary keys. A key is only useful if > the public half is registered. If you want it to be temporary, schedule a > job to remove it after the requisite time. How? "man cron". if there's nothing inherent in the key that forces expiration, you're gonna have a bad time. finally (and it seems like no one talks about this), ssh certs work for hosts as well. that means no more "host key doesn't match" warnings, ever. that's, "drops mic" level badassary. > I apologise if my comments seem needlessly dismal or sermon-like. I imagine > the question was based on a notion that users are capable of using SSH but > not capable of generating their own keys. I reject that notion. Users > learn how to drive motor vehicles, and that's much harder than generating > SSH keys. Don't pander to mere laziness. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
