Hacker News Reader

Comment by alexk | Hacker News Reader

I highly recommend to move off password-based SSH at all in favor of SSH keys or (even better, certificates).

Here are some projects to help you roll out new infrastructure without SSH passwords:

https://github.com/gravitational/teleport ( I work on this one with our team) and https://github.com/Netflix/bless (heard great things about it, especially if you are using AWS)

View on HN

Is it better to use certificates or keys? If certificates, how do you set those up? I have SSH keys setup right now.

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.

Certificates are more convenient than keys, but strictly speaking somewhat less secure than keys, because more mechanism is required to verify them.

Realistically, they're basically equivalent. Do whichever you're more comfortable with.

What about for a home network with a laptop, desktops and many VMs? I'd like to have a better setup than manually scp'ing files around, but these systems seem like overkill. Is there a middle ground?

Why'd keys be an overkill? It's just two files which need to be put at proper places.

I find this common "wisdom" or "best practice" questionable. Something to think about:

If I use a password, a suitably designed client can have absolutely no trace of my credential after it has been used.

If I use a key/certificate, that credential must be stored somewhere on the client, and even in encrypted form, it exists in persistent storage.

If someone is able to steal my private key file, then they have probably compromised my computer and could just as well install a keylogger.

Consider the scenario in which your computer is stolen (and might not ever be returned, so whether the attacker installs a keylogger is irrelevant):

The fact that a private key file exists suggests that the user is very likely to be using SSH regularly.

The fact that an SSH client exists is far less informational (there's one by default on most Linuxes and Mac OS).

If I only ever use password authentication with SSH and don't save anything else, not even server keys, the attacker has far less information. That might be important in some scenarios, especially related to anonymity.

You are aware it's usually recommended to have passphrases for keys, yes? Plus, you really should have whole-disk encryption for laptops.

(I get the feeling I'm missing something here, but...)

Passphrases on SSH keys used to be really easy to brute-force by default and I think they still are. Until two or three years ago the only way to slow down brute-forcing attacks was to use a complicated incantation with openssl to convert the keys to use a slower key derivation. Few people did.

Well, except I'm using "Correct Horse...". Oh. Well, I'm actually using a similar scheme to that, but I don't want to give too much away :).

Actually, I think you're probably right about the ease of brute-forcing passphrases in practice. That's not to say some random person is going to get access to your SSH key[1], but if you're actually being targeted as a "person of interest" by a nation-state you're probably SoL unless you're actually practicing due diligence... but then I think that's generally the name of the game, no? I mean OPSEC is still a thing even if you're only doing stuff that's shady-but-definitely-not-illegal.

[1] This isn't quite a "thing" yet, so some random burglar who steals your laptop isn't going to be attempting brute force.

Yes, what you're missing is that userbinator is probably trolling us

Regardless of whether the keyfile has a passphrase, the point is that it exists. And FDE also suggests you may be hiding something.

Sometimes the best way to make something secure, is to make it look like there is actually nothing to secure.

> And FDE also suggests you may be hiding something.

No one needs to bother trying to infer from FDE that I'm hiding something. I will tell them I am if they ask. Financial records, intimate correspondence, and employer trade secrets (I'm authorized to work at home on my personal computer) immediately come to mind and there is probably more.

I'm sure I'm not unusual in this regard. Most people have things they are hiding.

If anyone's targeting your specific laptop for theft they already think that you're hiding something.

If some rando steals your laptop they probably have no clue what SSH even stands for.

Security-by-obscurity only works alongside other layers.

Do you also do things like stop all system logging? Or shell logging? Even with only user-level access, a simple 'history' will show where you're ssh'ing to, regardless of whether you use a keyfile or not.

Not these days. FDE is so common and easy to use now, it might well have been an option you blindly hit upon install. And that's just in consumer environments. In corporate environments, in any company with a half-decent infosec department, all employees' computers will simply be required to have FDE, regardless of what they do on the computers.

FDE is also apparently not entirely impossible to bypass, which leaves you in the same situation of an attacker knowing that those SSH keyfiles exist on your machine.

You may think it's all over at that point, but there's different levels of secrecy, and it'd be better that the attacker cannot even know that a further level exists beyond.

> FDE is also apparently not entirely impossible to bypass

Sounds vague, can you please elaborate or cite? (I am not aware of this and if properly set up, I doubt this is true, so I am excited to learn what you know about this)

If your computer is stolen and you don't have full disk encryption, a leaked private key is probably far from the only problem.

What about your known_hosts? Do you delete that every connection?

HashKnownHosts?

Still establishes that SSH was being used, which seems to be userbinator's concern.

And of course if you do, that is weakening you against other kinds of attacks.

You're essentially arguing for SSH security to be reduced to the "something you know" prong of multifactor authentication.

alexk already addressed your concern: your keys, preferably issued by your org's CA (instead of being generated by you) should be short-lived, oftentimes for the duration of your "work shift". The tools listed above support this.

Which is why you generate your private key with a passphrase (which is used exclusively client side in an ssh client) and only store it on HDD, flash or SSD that uses full disk encryption.

Well you can always keep your keys in a removable drive rather than on persistent storage in your client device.

If you can't trust your client device, you probably have bigger issues with either method - for instance, can you trust that the client is not logging all keystrokes?

You must not be aware that you can set a password (which ssh-keygen calls a passphrase) on your private key file. The private key file will be encrypted and without the password will be useless, if your password is strong. Then you get the best of both.

Setting a passphrase on your key file is also actually widely considered a "best practice" and "conventional wisdom" ... so maybe those old guys knew something after all...

I'm perfectly aware that you can and almost always should encrypt the keyfile; the point I'm trying to make is that you still need a keyfile and the existence of that file can itself be a concern in some situations even it it can't be immediately used by an attacker.

Which can (and should) be stored in a way that requires a password to access (ssh supports this, as do most other certificate systems).

That's why short lived certs are better then just private keys - even if the key is stolen, the system can cut off the access by not issuing the renewed certificate. This makes private key itself to be irrelevant, in fact it can be generated as well once a day for example.

This objection is weak. Generate a unique key pair on the client. De-authorize it when you're done or just delete it.

If your argument is that your client is untrusted, then typing in your password is a lot more risky than generating a fresh key pair.

If someone has remote access to your computer then either way you are screwed. Using password or key file won't change anything.

If your laptop get stolen, then just remove the corresponding line in your authorized_keys file.

I think this "wisdom" or "best practice" is targeted at the overwhelming amount of the population that are concerned with using SSH on a computer they control and are therefore not concerned with leaving footprints behind.

Do you frequently use a computer that you don't control?

If the key is encrypted, then it doesn't exist as long as the password is good enough to resist a bruteforce.

But password requirements in this case are definitely higher. You can restrict login attempts in the remote ssh machine, but you can't restrict bruteforcing of stolen encrypted key.

You can also use bcrypt and adjust the work factor; assuming use of ssh-agent and/or shared connections, you could add a delay of multiple minutes to each try.

Your private key should remain password protected, I don't think anyone here is recommending a passwordless login. Also usually with ssh you are more worried about the remote server being compromised than your local client machine.

smart cards cost like $15

i am somewhat scared to use smart cards because they might break at some point and i am loosing access... if i would use some kind of local ca to provision the keys i could just as well use them directly... so i would need some kind of secured (air gaped and what not) device to provision them. which will be unavailable when i am abroad... all in all it seems to me it doesn't solve more problems than it makes...

The CA or smart card software is only needed for provisioning smart cards for clients, and is likely to be of little concern for setting up a new server. The card itself stores a non-phishable credential which you can physically secure.

This would mean I'd have to either remember to carry around a flash drive to access my server from the computers at the college library, or keep a copy of my private key on my networking drive there, a network I don't have any reason to believe is perfectly secure.

In either case generate different private keys to use there, so you can revoke the ones used from those computers easily without revoking your more tightly controlled keys.

Private keys are like passwords, try not to re-use them.

This can be quite inconvenient, that's why there's a way to make it more user friendly by using 2FA authentication or Google based SSO with your SSH:

http://gravitational.com/teleport/docs/admin-guide/#openid-o...

I wouldn't use untrusted computers to access my servers.

This. If you're typing in your password on a library computer, you're very vulnerable.

My first server was totally exposed in the DMZ. I ran windows RDP with the password "supersecret" for a long time also. I remember at one point also realizing that I could login to ftp anonymously. It was horrendous security in those early days and I had no idea what the heck I was doing.

Don't scare everybody off because it's not a best practice. If his/her server gets pwned they'll fix, learn, and move on.

A password is fine for your fun server. It's not super secure. It you're probably not interesting enough to get pwned using it.

The problem is insecure PCs and servers are a net negative for the Internet as a whole.

I'm now on a fast enough connection with good enough hardware that if you were able to get into one of my desktops or even just the router I'd be inadvertently sending out a lot of spam or "donating" a lot of bandwidth to a DDoS.

Also, scans of the entire IPv4 internet take less than an hour now, so there's absolutely no security-through-obscurity.

This is wrong. Compromised servers often become part of bot nets that cause real damage.

Heck, even compromised wireless routers[1] and CCTV systems[2] become part of botnets. Anything that's known to be insecure will be exploited.

[1]: http://krebsonsecurity.com/2015/01/lizard-stresser-runs-on-h...

[2]: https://blog.sucuri.net/2016/06/large-cctv-botnet-leveraged-...

Any server is interesting enough to get pwned to join in on DDoS botnets. I've seen it happen to so many cheap personal VPSes.

Protect it with a strong passphrase.

https://www.xkcd.com/936/

I recommend reading this XKCD comic for how to come up with strong passphrases.

I recently put up on github the latest incarnation of a password generator I've been using for over a decade now.[1]

It uses gpg to encrypt each site's username and a random password (using /dev/urandom or CryptGenRandom as the entropy source) in a separate file ~/Documents/Passwords/<domain>.gpg . At the time I first wrote it, I wanted something that was future-proof and where I could decrypt my passwords anywhere, and where a hardware fault while adding a new password was unlikely to cause corruption of pre-existing passwords.

Make your xkcd wordlist (http://google.com/search?q=oxford+3000 is a good start), one line per word, and bzip2 compress it as ~/Documents/Passwords/wordlist.txt.bz2 (or My Documents\Passwords\wordlist.txt.bz2 on Windows) and run the password generator with --alphabet 100 (restricting choices of "alphabets" to those with over 99 characters) and you'll get xkcd-style pass phrases. I also put some numbers in my word list, so I get passwords like

    blood Evil pint Urge occupy short railway 38
    Diagram elbow Arrest 80 Ceremony monday salt sector

It defaults to making the password/pass phrase length ceil(96 * log(2) / log(len(alphabet))) (96 bits of entropy). If you want to dial that up to 128 bits (or down to 80 bits), put { "bits" : 128 } in ~/Documents/Passwords/config.json (My Documents/Passwords/config.json on windows).

[1]https://github.com/kmag/store_password_gpg

Look at diceware for another great system to generate passwords.

Yes, I started out with a script that used the diceware wordlist to generate passwords and manually used gpg to store my passwords, then evolved my script to combine the two steps I was doing manually.

Have a look at my script. It's all of 200 lines. Easy to audit, and I'm not doing any of my own crypto or random number generation.

https://pypi.python.org/pypi/xkcdpass/1.8.2

Nice implementation of xkcd passwords.

Or.. you can use the web with this one!

https://xkpasswd.net/

Bright idea! Using someone elses Computer To generate your password!

It's easier to use for the lay person than a from-source-compilation you execute as a command line binary.

Yes, it's easier, but it's completely and totally insecure.

Security is not terribly hard, but it is completely and totally unforgiving. If you slip up on security, you will suffer, or others will suffer because of you.

Don't slip up on security.

And set the encryption to use pkcs8 with a million iterations.

You can also store the key file on your phone and copy it to whatever computer you want to login to, carrying a phone is easier then an extra flash drive

1. Don't use untrusted hosts to access trusted hosts.

2. If you do, put Tails on a USB drive and use S/Key one-time passwords to access your hosts. Tails should protect you from most real-time stealing of your passwords, and S/Key should protect you from most hardware keylooggers (by the time the one-time password is exfiltrated, it's useless).

If you're accessing computers you care about from a computer you don't control, you don't really care about them. It's already game over: sufficiently-advanced software could easily permit you to log in, then execute any sequence of commands leading to the downfall of your servers.

If you want to be paranoid, I wouldn't type sensitive info into those machines (for any number of reasons)

I keep it on my phone.

Why?

wow. im not sure i believe this...

there is no need to send the password to the server to authenticate a password in this day and age. i thought ssh was one of the first protocols to not do this.

The problem is, ssh daemon doesn't know anything about user password. It uses existing libraries to supply login and password in clear form (like Linux PAM) and they check if it's valid. How this check is done, is abstracted too: it could be /etc/shadow file lookup, it could be LDAP request or really anything.

On the other side, it could be possible to create sshd implementation which will use its own user database. But it's probably not convenient.

->ssh daemon doesn't know anything about user password

And neither should it. auth system creates a one time usable "ticket" which is a one way function of the user password and a nonce. The server gives the nonce to the user, who creates his own ticket based on the nonce and his password, gives his ticket to the server, which then checks if the two tickets match, if they do -> authenticated. -> at no point is the actual user password transmitted.

Kerberos extends this further (allows authentication across multiple servers with a single login)

But as far as I know the ticketing system is standard ssh protocol.

Looking at the spec however: https://tools.ietf.org/html/rfc4252#page-10

It appears I am not correct.

might be SSHv2

The ssh auth protocol is extensible, the client and server negotiate which methods they support, so it is possible to implement new methods.

What system are you thinking of? Which works with existing crypt(3) based system used on Unix?

If you are willing to tell anyone who connects your salt, you could, in principle, run a balanced PAKE using the crypt output.

You could go one step further and have the server store an augmented PAKE authenticator derived from the crypt(3) output.

Here's half an answer: Kerberos.

Which SSH does support, btw.

As a cloud support engineer, if you break your networking, I don't want to type a 256-character SSH key into the console to recover your server. Please use certificate-based VPNs and use internal addresses to keep connections within your own networks.

there is absolutely no reason you would need to type an ssh key by hand.

even at the very lowest level of server recovery (bare metal bios or uefi), crash carts are obsolete. you can cut and paste everywhere now through ethernetworked or emulated serial means.

It'll take at least another decade to get rid of all equipment without IPMI or alternatives. No, I'm not kidding.

you're not getting what i'm saying. it doesn't matter how old the gear you're working on is. if you're typing in long strings by hand, you're not thinking hard enough about how to do your job.

Or you have to deal with real world constraints, which can - and do - involve having equipment where e.g. attaching external KVMs etc. is not always an option that is made available to you (cost constraints; space constraints).

Please tell me how to paste into a VMWare VM console. To my knowledge, this is not possible.

vmware is a commercial product, ask the vendor.

Reply on news.ycombinator.com