- Setup and use ssh-agent. They make the life so easy.
- You can use Yubikey and pretty much every other solution out there with with OpenSSH now.
> ...
> You can use Yubikey and pretty much every other solution out there with with OpenSSH now.
Unfortunately, you can't use Ed25519 keys unless you have the latest/newest model(s) of Yubikey and that Yubikey came with at least a specific firmware version (5.2.3, IIRC). Even if that weren't so, there's still loads of popular / widely-used software that isn't even close to supporting Ed25519 (yet) but has supported RSA for years and years (and will continue to for the foreseeable future).
I'd like to be able to "upgrade" to an Ed25519 key but I can't come up with any real reason to expand my collection of Yubikeys any further (I think I'm up to nine, at last count, and the three newest ones haven't even been opened!). I don't plan on purchasing another Yubikey until four or five of the ones I already have decide to call it quits, so I won't be using an Ed25519 key anytime in the next couple of years, at least.
Even if I could start using an Ed25519 key with my Yubikeys today, I'd likely still have to keep an RSA key around for the "legacy" stuff, in which case I might as well just save myself the trouble and stick with RSA for a while longer.
A private RSA (2048+) key on a Yubikey is still much "better", IMO, than a private Ed25519 key sitting on one's hard drive.
In an ideal world we could all just switch everything over to Ed25519 at about the same time and then retire RSA shortly afterwards. It's gonna be a long time before everyone has ditched RSA keys and moved to Ed25519, though -- RSA isn't going anywhere anytime soon!
I should look into setting it up with more things at home.
I am a bit confused. Aren't yubikeys able to store multiple keys on them? Why do you have to use so many? Why not instead e.g. a LUKS encrypted usb flashdrive?
Well, I started out with a Symantec VIP Yubikey many, many years ago. Then, MtGox sent me one for 2FA after some compromise there. Later, I bought a "full-featured" Yubikey for use with GPG and SSH on my desktop / workstation. After that, I got two Nanos so that I could leave one, permanently, in each of a pair of laptops. Shortly after that, I decided I should have a spare -- you know, just in case.
At some point, I received another pair of Nanos as free replacements due to one of the issues that Yubico had (weak RNG or something, I think?). Those two and the "spare" are the ones that are still unopened in the package.
Finally, (I'm not really sure why but) I bought a pair of the "GitHub" U2F-only Yubikeys when there was some special deal going on. Now that I think about it, I don't think I've ever even used them either.
The only ones that I really use are the ones that I leave in my workstation and my primary laptop (primarily used for SSH but, to a lesser extent, for signing git commits and unlocking KeePassXC databases as well).
> Why not instead e.g. a LUKS encrypted usb flashdrive?
Oh, I've got probably a dozen or so of those also!
It seems to work great with all the yubikeys I’ve tested with.
I discovered this week that AWS doesn't support Ed25519 keys for EC2 and IAM users.
My #1 ssh usability tip: put this into ~/.ssh/config:
AddKeysToAgent yes
If you have more than one private key in your agent, then SSH will try each one sequentially. That can lead to mistakenly getting banned by monitoring software for what can appear indistinguishable to be an authentication attack. Not to mention the wrongness of presenting "any and all keys" to any host you connect to.
If you have multiple keys in your agent, you _really_ should manually configure what key to present using `-i` or `IdentityFile`. But you should also use `IdentitiesOnly` too.
If you specify -i or IdentityFile, the agent isn't used at all. You will have to type the keyfile password even if the key is in the agent, therefore making the agent useless.
This "feature" has been a big annoyance for me, since I like to use different keys per machine.
Maybe it depends on version or something? I've had the same config for years though over several very different OSes and presumably versions of everything.
I thought so as well, so the reply to this message surprised. I looked into it, and the following is the case on my Debian 18.04 machine running KDE:
With specifying the key through `IdentityFile` I can happily connect without a running ssh-agent. So it's true, that it can do without using the ssh-agent. But if the key has a password, it will prompt for it everytime it's used. I wouldn't phrase it "the agent isn't used at all", though, because for when ssh-agent is running, and it contains the key+password, it seems to happily use that agent, as it doesn't prompt for the password anymore.
Side note: If my understanding is correct, `IdentifyFile` lessens the need for consulting the ssh-agent as stated above, but, except from consulting it for the key password, the agent might be consulted for one more reason as well: Iterating over keys if using the specified one proved unfruitful. For this to stop, you'd have to specify `IdentitiesOnly yes` as well. But this I didn't test, so it's based on theoretical understanding only.
Edit: Oh, the last part was already explained in some other thread which branched of from this. So this post didn't actually provide some new insights, it seems.
Having a forwarded agent was how matrix recently got hacked, confirmation is a decent work around if you need to forward your agent.
1. Don't put secret information on a machine where someone you don't trust has root.
2. Don't use agent forwarding unless you know you can trust the machine on the other end.
Since agent forwarding is not enabled by default, both of these seem pretty obvious to me.
Most "use cases" I've come across could have been solved "better" by simply using ProxyCommand instead. That was apparently too hard, though, so use of agent forwarding continued.
Since the introduction of ProxyJump a while back, however, it's now even easier to avoid using agent forwarding in most -- but not all -- cases.
So yes, be careful when using agent forwarding but, more importantly, as much as possible, just avoid using it entirely unless you absolutely must!
This gets said a lot, but doesn't forcing a prompt every time the forwarded key gets used mitigate this? SSH is not like surfing on the web with traffic flowing everywhere all the time. If you did not just now run any commands that are expected to invoke SSH, you probably don't want to answer yes to that prompt.
On both ends. Agent hijacking can happen on client or server, with an attacker present. And is there any machine you can 'trust' ? That's a big ask, and I think the modern 'zero trust' is fundamentally averse to the concept.
This is only true if you consider pure brute force as the only way to "break" RSA 2048. While as of right now there is no hard evidence there has been plenty of hearsay that some of the 5 Eyes have had tools for years that can drastically reduce the brute force complexity needed for RSA 2048 keys.
There is also really no such thing as being "paranoid with no gain" when it comes to computational security, since digital assets can be stored indefinitely and compromised in the future with more advanced computational power or techniques. On the contrary, given the computational power of your average laptop/server these days there's really no reason to _not_ use 4096 keys, unless you are operating on FAANG scale.
Sadly whatever library Spring Integration uses does not support them yet, as I found out the hard way. I just tried to search for it and couldn't find the reference but just dealt with it a month or two ago.
https://developercommunity.visualstudio.com/idea/462263/cant...
https://feedback.azure.com/forums/223579-azure-portal/sugges...
I've been looking at MFT solutions recently (think fancy SFTP servers for file exchange) and the level of support is just plain bad. Out of roughly 20 products, I think there are maybe 2 that had ed25519 support.
Similarly with Java products that need to use SFTP to transfer files (think SuccessFactors, Dell Boomi etc.) These typically use JSCH which has not been updated for years.
facepalm
But at virtually no additional cost. I don't see your argument?
Bigger RSA keys are expensive to compute:
$: openssl speed rsa
sign verify sign/s verify/s
rsa 512 bits 0.000075s 0.000006s 13249.7 179054.0
rsa 1024 bits 0.000136s 0.000011s 7363.7 90816.2
rsa 2048 bits 0.000920s 0.000028s 1086.8 35897.8
rsa 3072 bits 0.002575s 0.000053s 388.4 18845.6
rsa 4096 bits 0.005716s 0.000093s 174.9 10777.2
rsa 7680 bits 0.054218s 0.000304s 18.4 3287.0
rsa 15360 bits 0.283036s 0.001182s 3.5 846.2But that argument shouldn't be applied for all use cases, such as personal key management, or keys that are used for days/weeks/months at a time.
I tried switching from a 2048-bit to a 4096-bit key to control a modestly sized VPS (~4GB RAM, 2CPU) and scp file transfer speeds plummeted.
I have a symmetric 1GB FTTH connection and I'm used to everything being pretty quick. Using a longer key was like a return to dial-up speed. If you don't plan to transfer large files or directories you can safely ignore it, but I bet your patience will run out pretty quickly if you do.
(Unless you are saying you somehow convinced SSH to use a symmetric cipher with a 2-4k key size...?)