Live data from Hacker News

A sane SSH(1) key management example

try.popho.be

11–20 of 69 posts

Re: A sane SSH(1) key management example

#11
post #7
post #2

Really like the approach here. In the past, I've typically managed my SSH keys by naming them as id_ like so, then tinkering with the ssh_config to make use of them. Never thought of using the token approach, though, definitely makes things simpler to work with.

The config file already does this, this is just a shortcut with %h and the file system structure. You literally start an entry with "Host " follwed by "User" and "IdentifyFile". There's even a bash autocomplete rule for it so you can tab through your servers "ssh ". It won't send all the keys to the server if you organize this way (which doesn't really matter anyway, since they are PUBLIC KEYS). It resolves to a pref…

> You literally start an entry with "Host " follwed by "User" and "IdentifyFile".

But that's so much pain.

> The config file already does this, this is just a shortcut with %h and the file system structure.

No.

    % ssh -F /dev/null -v whoami.filippo.io
    debug1: Trying private key: /home/moviuro/.ssh/id_rsa
    debug1: Trying private key: /home/moviuro/.ssh/id_ecdsa
    debug1: Trying private key: /home/moviuro/.ssh/id_ecdsa_sk
    debug1: Trying private key: /home/moviuro/.ssh/id_ed25519
    debug1: Trying private key: /home/moviuro/.ssh/id_ed25519_sk
    debug1: Trying private key: /home/moviuro/.ssh/id_xmss
    debug1: Trying private key: /home/moviuro/.ssh/id_dsa

Re: A sane SSH(1) key management example

#12
post #4

> Did you know that ssh sends all your public keys to any server it tries to authenticate to? Never really thought about it. Feels kind of "leaky", even if necessary.

It's definitely a convenience over security feature. My personal feeling is that the convenience is worth it in this case, and it's a sensible default.

Re: A sane SSH(1) key management example

#13
post #4

> Did you know that ssh sends all your public keys to any server it tries to authenticate to? Never really thought about it. Feels kind of "leaky", even if necessary.

Not a big deal at all considering that they're public keys, there's no security concern there. Feels weird, but it's like going into a building that requires a badge and showing proof that you actually own several keys, then the building guard telling you he needs X key to enter since that's the one they know, and it's authorized. All your public keys in your GitHub account are accessible through a link, just .keys>

> Not a big deal at all considering that they're public keys, there's no security concern there.

I might be pushing the analogy too far, but: all the URLs I have visited are public and are not identifying me personally, yet uploading them all together to a third party feels like a breach of privacy.

Re: A sane SSH(1) key management example

#14
post #11
post #7

Earlier quoted context omitted.

The config file already does this, this is just a shortcut with %h and the file system structure. You literally start an entry with "Host " follwed by "User" and "IdentifyFile". There's even a bash autocomplete rule for it so you can tab through your servers "ssh ". It won't send all the keys to the server if you organize this way (which doesn't really matter anyway, since they are PUBLIC KEYS). It resolves to a pref…

> You literally start an entry with "Host " follwed by "User" and "IdentifyFile". But that's so much pain. > The config file already does this, this is just a shortcut with %h and the file system structure. No. % ssh -F /dev/null -v whoami.filippo.io debug1: Trying private key: /home/moviuro/.ssh/id_rsa debug1: Trying private key: /home/moviuro/.ssh/id_ecdsa debug1: Trying private key: /home/moviuro/.ssh/id_ecdsa_sk…

Did you have an entry for "Host whoami.fillippo.io" in your config file?

Re: A sane SSH(1) key management example

#15
SSH public keys are called public keys because they're totally safe to distribute anywhere. That's rather the entire point of asymmetric cryptography.

So I guess I don't really understand the problem being solved here.

And yes, I would very much love to have a single key that worked for my house, car, safe deposit box, etc. One that isn't my smart phone, of course.

Re: A sane SSH(1) key management example

#16
My ~/.ssh/config has one line:

ForwardAgent yes

My public keys are in my dotfiles repo and my private keys were in hardware security keys/cards since 2016, unextractable.

I don't see any reason to do what this post is suggesting and in my opinion a post about SSH keys without advising to use security keys (which you also can use for 2FA) is a bit retrograde.

Re: A sane SSH(1) key management example

#18
post #3

> How would you look at someone using a single key for their car, house, safe, work place, and so on? This is a terrible analogy, and I don't see any other justification for this setup. An SSH "key" is also referred to as an "identity". Contrary to a car key, it is not tied to the car, but to the client's identity. It is more like a badge than a brass key. A car key has the limitation that your lock can only accept o…

It's a great analogy, for many people.

The distinction between treating SSH keys more like keys, or more like a badge, is heavily milieu dependent.

Re: A sane SSH(1) key management example

#20

>How would you look at someone using a single key for their car, house, safe, work place, and so on? One key to rule them all? Honestly, I would be jealous.

Sure, but as soon as you've got to leave the car key at the shop for the car inspection, you might rethink that approach.
Post reply on HN