A sane SSH(1) key management example

&gt; How would you look at someone using a single key for their car, house, safe, work place, and so on?<p>This is a terrible analogy, and I don&#x27;t see any other justification for this setup.<p>An SSH &quot;key&quot; is also referred to as an &quot;identity&quot;. Contrary to a car key, it is not tied to the car, but to the client&#x27;s identity. It is more like a badge than a brass key.<p>A car key has the limitation that your lock can only accept one key, and can&#x27;t be easily updated to accept&#x2F;refuse keys. You also can&#x27;t remotely give somebody access (you have to hand them the key) and you can&#x27;t prevent someone with the key from making a copy without returning it.<p>An SSH key pair has none of those limitations so it&#x27;s really not clear why anyone might want to manage them like car keys. If anything, the root password is more like a car key than a key pair is.

SSH public keys are called public keys because they&#x27;re totally safe to distribute anywhere. That&#x27;s rather the entire point of asymmetric cryptography.<p>So I guess I don&#x27;t really understand the problem being solved here.<p>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&#x27;t my smart phone, of course.

My googling skills are failing me. Can anyone help explain what the &quot;(1)&quot; after SSH means? I guess I always thought it was a footnote marker or something (mainly I just ignored it when I saw it) but I&#x27;d love to know what it means.

On Macs, Secretive [0] is great. It creates keys in the secret enclave, from where they can&#x27;t be read, only used for signing requests. TouchID authorisation is optional but it&#x27;s so quick and easy that I keep it on for all keys.<p>It can also use Smart Cards (Yubikeys are called out by name in the readme).<p>A forwarded agent will have the same level of security, meaning that if the forwarded agent needs to use a key in Secretive, it will have to be authorised locally - and even if TouchID is disabled, you are notified if a key is used.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;maxgoedjen&#x2F;secretive&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;maxgoedjen&#x2F;secretive&#x2F;</a>

&gt; It’s common knowledge that you shouldn’t put all your eggs in the same basket, but most of the time on IRC or on reddit (or the Internet at large, really), I see people using one single ssh key for all uses. How would you look at someone using a single key for their car, house, safe, work place, and so on?<p>a bit envious tbh. I would be so annoyed if we would get a key fob for every door at work instead of one key fob that can be reprogrammed.<p>The comparison drawn here is bad because you would look at the person funny because &quot;How the hell is someone able to replace every lock so that this works?&quot;<p>At work we have a script that pulls all our gitlab keys and adds them to the authorized_keys section if you should have access to a server. In what scenario is leaking your identity over ssh really a problem? If I want to connect to a server normally I either own or administrate the server. Next use case is a leaked private key.... How the hell do you leak your private key? There are 3 scenarios I can think of:<p><pre><code> * you copy it to a host&#x2F;usb drive and someone else has access to it * a new attack is found to generate a private key to your public key * someone gets access to your machine and steals it </code></pre> 1) you shouldn&#x27;t do 2) leaves all your keys vulnerable 3) every key on the machine needs to be replaced<p>&gt; As an added benefit now, if one of your ssh keys ever leaks, there’s only one place to remove it from ~&#x2F;.ssh&#x2F;authorized_keys (where the login@hostname comment is still present).<p>Do you do this for every machine you own? Sounds like a real pain. Maybe only because of my setup with passwords and keepassxc.<p>If you fear leaking your key maybe a fido2 device and&#x2F;or password would be a better solution. Don&#x27;t get me wrong I too have more than one ssh key, but this seems overly excessive. Since this solutions looks rather clean it maybe isn&#x27;t, but I don&#x27;t see many advantages here. But it is a nice setup nonetheless. I could reasonably easy implement something like this on top of my existing setup, but right now it seems only to add more administrative work. Especially since I really like the idea of an asymmetric key that opens my doors. The only downside for ssh keys is that you can&#x27;t invalidate them in a central location.

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

Yeah, I use different keys for different purposes&#x2F;projects but not for each and every server. Sounds inconvenient.<p>Plus how would only one of my ssh keys leak when I store them all in the same place? If I was worried about my keys leaking, I would rather do the YubiKey voodoo and keep my keys there.<p>But, again, once someone (persistently) compromises my main laptop, it&#x27;s game over anyway.

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

Really like the approach here. In the past, I&#x27;ve typically managed my SSH keys by naming them as id_&lt;purpose&gt; like so, then tinkering with the ssh_config to make use of them.<p>Never thought of using the token approach, though, definitely makes things simpler to work with.

My ~&#x2F;.ssh&#x2F;config has one line:<p>ForwardAgent yes<p>My public keys are in my dotfiles repo and my private keys were in hardware security keys&#x2F;cards since 2016, unextractable.<p>I don&#x27;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.