Hacker News new | past | comments | ask | show | jobs | submit login

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-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-te...




So 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.


keys are better, even though you need to distribute them, nobody else has them...


Err, 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. :)


If you use someone else's CA, wouldn't they have your private keys?


No, The CA only signs the public key, the private key never leaves your machine.


But can't they sign some other key pair, representing you?


No, they can't represent you, because they don't have your private key.


The 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.


This 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.


Uhm. No... he's right.

In the browser world.. A a rouge CA, I could generate a certificate pair for 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)


You 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.


The whole point of using a CA is to not put every public key on every server.

If the public key is going to be there, then the CA is not doing anything.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: