Comment by georgehotelling | Hacker News Reader

Comment by georgehotelling | Hacker News Reader

georgehotelling

> Use unique SSH keys for each service (sharing a SSH key on your GitHub/Gitlab account, network router and AWS/Azure instance is a very stupid idea); use ssh-keygen -t rsa -b 4096 to generate a 4096 bit RSA SSH key.

I tried this. Turns out to be a bad idea. SSH will walk through each private key and attempt to authenticate with it in order. That means a lot of bad login attempts which in turn leads to getting locked out. SSH public keys are public for a reason.

What attack is this even preventing - that someone will be able to reverse ssh public keys and get the private? A better approach is to generate a unique key per client so that if you lose access to a device you can remove only its public key.

> Also, you should download the source code, compile it (using a Linux machine) and always look over the source code for rogue functions

So I becoming an Underhanded C Contest judge is the price of admission to using the internet? Can anyone really be expected to do that? Can we blame anyone who gets owned because they didn't?

The solution to that is to use the IdentityFile directive in your ~/.ssh/config with username / hostname expansion. I use:

    Host *
        # Disable SSHv1
        RSAAuthentication no

        # Only use a key explicitely provided by an IdentityFile directive
        IdentitiesOnly yes

        # %h expands to the hostname, and %u to the username
        IdentityFile ~/.ssh/%h/%u.key

This ensures that at most one key is used, and prevents me from having to modify my config every time I generate a key for a new host.

Awesome, I did not realize you could use filename templates for SSH keys. Thanks!

The point remains, there isn't much benefit to using a different key per host. What attack vector is this extra effort protecting you from?

I think you're supposed to configure SSH to use the right key without trying them all in your ~/.ssh/config

> What attack is this even preventing

I think the thought is the security practice of compartmentalization. If you lose the private key you use for GitHub, Amazon, DigitalOcean, your home servers, etc... you've effectively given root away.

Now if my laptop is compromised, it doesn't matter if I have one key or ten, I've lost them all. But if there's something heartbleed-esque that allows individual private keys to be stolen when pushing commits to GitHub, I've at least isolated damage to my GitHub account.

But the private key is (of course) never sent to GitHub, so it's hard for me to imagine what kind of vuln this would help with. I can think of a few, but they're odd:

1. Some sort of remote memory leak that leaks the current private key, I guess.

2. Some sort of relay attack where you can impersonate the legit host.

In both of these cases, it seems like at a minimum you would need to, on the client, set up an ssh config that limits each identity to each host so as to prevent the client from trying each key in sequence (and thus potentially exposing it). That's a huge hassle!

So I guess tl;dr: I can think of a few cases where this might be useful, but if you're always SSH'ing from the same laptop, this step can probably be pretty far down your list of things to do.

> What attack is this even preventing - that someone will be able to reverse ssh public keys and get the private? A better approach is to generate a unique key per client so that if you lose access to a device you can remove only its public key.

I don't think this is about security. Just about privacy.

Some people don't like that they can be identified by their public key. eg (I think) github allows public viewing of a specific users public key, and that allows other services you use with your public key to know your github account etc.

It's not a mainstream privacy concern, but there are some privacy oriented people that worry about it.

Why not use 'ssh -i key_file user@domain'?

Should only use the specified key file then, AFAIK, without doing the cycling you mentioned.

Reply on news.ycombinator.com