Never really thought about it. Feels kind of "leaky", even if necessary.
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 <github.com/<username>.keys>
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.
To prevent
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.
It all depends on your threat model, I guess.
One key to rule them all? Honestly, I would be jealous.
I guess a similar solution could be implemented for a mechanical shop key..
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.
> You may be tempted to use a wildcard like `Host *` to just apply [ForwardAgent yes] to all SSH connections. That's not really a good idea, as you'd be sharing your local SSH keys with every server you SSH into. They won't have direct access to the keys, but they will be able to use them as you while the connection is established.
[0] https://docs.github.com/en/developers/overview/using-ssh-age...
$ ssh whoami.filippo.io
You have SSH agent forwarding turned (universally?) on.
That is a VERY BAD idea. For example, right now this server
has access to your agent and can use your keys however it
likes as long as you are connected.
ANY SERVER YOU LOG IN TO AND ANYONE WITH ROOT ON
THOSE SERVERS CAN LOGIN AS YOU ANYWHERE.
Back in 2016 I was using https://github.com/philipWendland/IsoApplet which uses https://en.wikipedia.org/wiki/PKCS_11 standard, but modern way is much smoother as long as your OpenSSH server is up to date.
Never thought of using the token approach, though, definitely makes things simpler to work with.
You literally start an entry with "Host <hostname>" follwed by "User" and "IdentifyFile". There's even a bash autocomplete rule for it so you can tab through your servers "ssh <tab>". 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 preference: using a file or the OS filesystem to organize your keys.
Having a public key doesn't teach an observer your private key, and so they can't impersonate you, but it does allow the observer to distinguish you from others. If you would like to prevent observers from correlating identity this way (most famously if you use a public key for GitHub and also other things) you will want to explicitly forbid your SSH client from offering to prove identities other than the one you know will be used.
The setting in OpenSSH (which you can enable for individual Hosts) is IdentitiesOnly yes
Your proposed configuration will choose to try the file named, but it will not tell the remote server that you don't have any other identities, for that you need IdentitiesOnly. The default is no, although I guess it's possible you have overridden that to "Yes" previously and then forgotten.
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_dsaThe "ssh(1)" means "read about ssh in man page section 1".
Section 1 is for general commands.
https://en.wikipedia.org/wiki/Man_page
Pages are traditionally referred to using the notation "name(section)": for example, ftp(1). The section refers to different ways the topic might be referenced.
1 General commands
2 System calls
3 Library functions
4 Special files such as devices /dev
5 File formats and conventions
6 Games and screensavers
7 Miscellaneous
8 System administration commands and daemonsIt can also use Smart Cards (Yubikeys are called out by name in the readme).
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.
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.
The comparison drawn here is bad because you would look at the person funny because "How the hell is someone able to replace every lock so that this works?"
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:
* you copy it to a host/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
> As an added benefit now, if one of your ssh keys ever leaks, there’s only one place to remove it from ~/.ssh/authorized_keys (where the login@hostname comment is still present).
Do you do this for every machine you own? Sounds like a real pain. Maybe only because of my setup with passwords and keepassxc.
If you fear leaking your key maybe a fido2 device and/or password would be a better solution. Don'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't, but I don'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't invalidate them in a central location.
One key (well, I mean, I'd want copies of it) for everything would be excellent.
Terrible analogy because I'd look at them like "damn, they've got it figured out!"
[EDIT] Thinking further, the only way this falls apart is if I want to give someone else a key to just one thing, but that's a non-issue with ssh, so the analogy is still comically backwards. "But what if someone gets ahold of one key! Same key for everything, that's access to all your stuff!" well shit man, that's about the same as getting one of them if they're all different, in most cases—where do you think I keep my extra keys? And the couple I carry, so are likely to get in someone else's hands by accident or whatever, are the "give you the kingdom" type anyway. Get my car key, you can get in my house (garage door opener). Get any house key, you can probably get in my car, plus the rest of my keys (e.g. safe) are in there because I don't carry them around all the time.
Yeah, letting someone borrow a key is the only time this might be inconvenient, and again, that's not a factor with SSH.
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 one key, and can't be easily updated to accept/refuse keys. You also can't remotely give somebody access (you have to hand them the key) and you can't prevent someone with the key from making a copy without returning it.
An SSH key pair has none of those limitations so it'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.
The distinction between treating SSH keys more like keys, or more like a badge, is heavily milieu dependent.
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.
But, again, once someone (persistently) compromises my main laptop, it's game over anyway.