4 ms·
Certificates are better - you don't need to worry about distributing your public keys everywhere. Here's a nice article about setting up a CA for your OpenSSH
by alexk 10y ago
Certificates are better - you don't need to worry about distributing your public keys everywhere.
Here's a nice article about setting up a CA for your OpenSSH servers:
https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu https://www.digitalocean.com/community/tutorials/how-to-crea...
It's better to generate short lived certificates and teleport does exactly that - you can use it with existing OpenSSH infrastructure:
http://gravitational.com/teleport/docs/admin-guide/#using-teleport-with-openssh http://gravitational.com/teleport/docs/admin-guide/#using-te...
- awqrre 10y agokeys are better, even though you need to distribute them, nobody else has them...
- Daviey 10y agoErr, letting the world have your public keys is perfectly normal. Both GitHub and Launchpad provide a public registry for these: - https://github.com/USERNAMEE.keys - https://launchpad.net/~USERNAME/+sshkeys For example, mine are: - https://github.com/Daviey.keys - https://launchpad.net/~davewalker/+sshkeys Feel free to add them to your servers. :)
- awqrre 10y agoIf you use someone else's CA, wouldn't they have your private keys?
- ckwalsh 10y agoNo, The CA only signs the public key, the private key never leaves your machine.
- Drdrdrq 10y agoBut can't they sign some other key pair, representing you?
- wtetzner 10y agoNo, they can't represent you, because they don't have your private key.
- Dylan16807 10y agoThe server doesn't care what private key you use. If it's signed by the CA, the server trusts it. Unless I'm missing something, anyone with control over your CA can easily sign in as you.
- monkeywork 10y agoThis is only true if you don't trust the machine you are connecting to. Private key (only you know) -> signed by CA -> public key you share. You put the public key on the server , the CA can't change that file... And they can't make that particular cert work without a private key that you hold. Most CA can do is revoke and break the chain on you.
- Daviey 10y agoUhm. No... he's right. In the browser world.. A a rouge CA, I could generate a certificate pair for https://google.com https://google.com and your web browser would trust it. The same is true with this setup... the solution, for this is to be your own CA and add the CA to all of your clients, rather than adding all of your clients to the server. So this reverses the problem, which for many should be easier. (I honestly can't see anyone using a public CA for this.. it would be nuts)
- awqrre 10y agoYou might be surprised to see the nut things people would do for convenience... but in this case you are probably right as the average computer user probably don't use SSH.
- Daviey 10y agoSo this is awesome for 3 main reasons.. Trusting host keys... I no longer need to check (or ignore and just type yes) when I first connect to a server.. which is literally as bad as on a brand new machine hitting a web browser, going to your online bank and ignoring the certificate warning. Distributing trust, New employee - I don't need to push public keys out to all servers or rely on centralised auth such as LDAP/AD/Kerberos. But the real gem is time limited access.. All without touching each server separately. Ie, I want access to your fleet of servers for 2 hours, on Sunday 18th between 10:00-12:00 UTC. I create a certificate pair with that validity, pass you the public part and you sign it using the CA. Without you needing to touch any of your servers, I now have full access for the window as agreed.