Hacker News Reader

Comment by fensipens | Hacker News Reader

This is about being able to connect keys to individuals and then searching The Stash for more links that then build a graph.

But it's just metadata, isn't it..

View on HN

If you use a key exclusively for github servers then there's no graph-building.

something like the following in ~/.ssh/config

Host *.github.com

IdentitiesOnly yes

IdentityFile ~/.ssh/hostboundkeys/github_ed25519

Here's what I do:

    # IdentityFile magic, should be placed at very end of file
    Host *
    IdentityFile ~/.ssh/keys/id_ecdsa_%r@%h
    IdentityFile ~/.ssh/keys/id_rsa_%r@%h
    IdentityFile ~/.ssh/keys/id_ecdsa_ANY@%h
    IdentityFile ~/.ssh/keys/id_rsa_ANY@%h
    IdentityFile ~/.ssh/keys/id_ecdsa_%r@ANY
    IdentityFile ~/.ssh/keys/id_rsa_%r@ANY
    IdentityFile ~/.ssh/keys/id_ecdsa_ANY@ANY
    IdentityFile ~/.ssh/keys/id_rsa_ANY@ANY

Will look for user@host, ANY@host, user@ANY, then ANY@ANY keys. You can add ed25519 to this.

This looks pretty neat -- however, do you use passphrases for your keys, and if so, how do you manage them? Only 2 obvious solutions spring immediately to mind - use the same (or none) pass for each key, or have a unique one per-key and some sort of separate password database with a master password.

At least, I can't imagine memorising enough unique passphrases for all the user/host combinations I currently have.

I'm hoping there's some clever built-in or easily added (like keychain/agent) way to secure individual keys on the filesystem without excess complexity when using them.

The IdentifyFile directives actually work with ssh-agent - it will try the keys listed there first, using them via the agent if they're loaded. I use the same passphrase on all keys and load them into my agent all at once (when loading, the last passphrase you entered will be tried to decrypt each key).

Normally, the problem with having many keys in the agent is that a server you're logging into will boot you after supplying too many keys it doesn't accept, but this fixes that.

This is the answer right here. Also it's wise to use different keys for different services, for the same reasons that you'd use different passwords.

When I share a password between two services, they get the plaintext password when I authenticate, so the first one can impersonate me in front of the second one. How does this apply to keys?

If you have one key, and use it for N services, compromising your key compromises N accounts. If you use one key per service, compromising a key only compromises one account.

If you have your N private keys all stored on the same device (such as side-by-side in your ~/.ssh/keys directory, as in ryan-c's example upthread), under what scenario would just one of those keys get compromised?

You only need one private key per device to be secure. The benefit of using separate keys per service is privacy - it prevents the various service providers from colluding to determine that you're a user of all the services (but if you're not careful you're probably leaking other information to them that would let them learn this anyways).

If you're not using passphrases on your keys, then yes they are locally wide open, much like a passwords.txt strategy for passwords. If you do passphrase them, the attacker now needs N passphrases. Perhaps you notice the keylogger before all passphrases get logged? There are probably more scenarios where N keys is strictly better than one, but that's the first that comes to mind.

I agree with the privacy aspect, it's that's the same point that the8472 made.

"perhaps you don't use password manager and you notice the keylogger halfway through" is a pretty unlikely scenario to motivate me to use a bunch of unique passphrases.

It's not "strictly better" when it hurts your ability to use and memorize strong passes.

Usability is part of security.

And unlike passwords the extra overhead of maintaining multiple keys is virtually frictionless.

Reply on news.ycombinator.com