12 ms·

- Use Ed25519 keys. They are now supported in pretty much every server out there (all recent OpenSSH versions, GitHub, GitLab, etc). RSA 2048 keys are unbreakab

by Ayesh 7y ago

- Use Ed25519 keys. They are now supported in pretty much every server out there (all recent OpenSSH versions, GitHub, GitLab, etc). RSA 2048 keys are unbreakable for the foreseeable future, and using 4096 bit keys are just being paranoid with no gain. You can fit 4x Ed25519 keys in a tweet. - 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.

mason55 7y ago
> They are now supported in pretty much every server out there 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.
ddevault 7y ago
>Setup and use ssh-agent. They make the life so easy. My #1 ssh usability tip: put this into ~/.ssh/config: AddKeysToAgent yes It'll automatically add keys to your agent the first time you use them during a session, so you don't need a separate step for adding keys every time you log in.
- res0nat0r 7y ago
  I've not noticed this option before, so will this replace keychain? I install this on every new laptop I use so I essentially only have to enter my ssh-agent password for the key once per reboot, and every bash shell hooks into it automatically. https://www.funtoo.org/Keychain https://www.funtoo.org/Keychain
- Lammy 7y ago
  Be careful; there are plenty of ways ssh-agent can bite you too. Here are a few: http://rabexc.org/posts/pitfalls-of-ssh-agents http://rabexc.org/posts/pitfalls-of-ssh-agents
  - ddevault 7y ago
    This article can be boiled down to one common sense idea and one less obvious idea: 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.
    - dx87 7y ago
      It's still good info, I don't think it's obvious to most people. I was doing a pentest for a Fortune 500 company, and a key component of us compromising their entire network was a bastion host that controlled access to sensitive parts of their network. Turns out whoever controlled the machine made the rookie mistake of running a cron job as root that ran a non root-owned script, which enabled us to elevate and copy the ssh keys of a lot of IT staff.
      - ddevault 7y ago
        Good insight. You should definitely be careful with forwarding.
        jlgaddis 7y ago
        Yes, be careful when using ForwardAgent and, more importantly, avoid using it altogether unless you absolutely need to! 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!
        manuel_w 7y ago
        Sometimes I log into a machine and would like to ssh-clone a git repository there using the private key I've got on my local machine. Is there a way around forwarding my ssh-agent in this case?
- inetknght 7y ago
  > It'll automatically add keys to your agent the first time you use them during a session 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.
  - krferriter 7y ago
    I don't understand what `IdentitiesOnly` does. If I have `IdentityFile`s defined for hosts in ssh_config, doesn't that already accomplish what this does? Can you explain what situation `IdentitiesOnly` covers that is different from `IdentityFile`?
    - webvictim 7y ago
      Author here. If you specify an IdentityFile then that’ll be tried first (as an explicit identity) but if that doesn’t work then by default, ssh-agent identities will be tried sequentially afterwards. IdentitiesOnly suppresses that behaviour.
  - shawnz 7y ago
    > If you have multiple keys in your agent, you _really_ should manually configure what key to present using `-i` or `IdentityFile`. 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.
    - kadoban 7y ago
      There's no way that's true. I just checked and I have that option set on many of my ssh aliases, and ssh-agent functions exactly as expected. 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.
- keeperofdakeys 7y ago
  I'd recommend you try "AddKeysToAgent confirm", then you'll get a prompt to approve the key usage each time its used. (Can be annoying for usage with automation like ansible). Having a forwarded agent was how matrix recently got hacked, confirmation is a decent work around if you need to forward your agent.
ggregoire 7y ago
> Use Ed25519 keys. They are now supported pretty much everywhere I discovered this week that AWS doesn't support Ed25519 keys for EC2 and IAM users. https://forums.aws.amazon.com/thread.jspa?threadID=250753 https://forums.aws.amazon.com/thread.jspa?threadID=250753
- deleted 7y ago
  [deleted]
- deathanatos 7y ago
  And Azure doesn't support it while instantiating a VM. Which boggles my mind since AFAICT all they have to do with the key material I hand them is to copy it into authorized_keys, not inspect it and tell me my valid key is invalid.
  - nextweek2 7y ago
    And Azure DevOps Repo's.
ryanisnan 7y ago
> using 4096 bit keys are just being paranoid with no gain But at virtually no additional cost. I don't see your argument?
- Ayesh 7y ago
  > But at virtually no additional cost. 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.2
  - xref 7y ago
    I think op is saying, at the cost of an undetectable fraction of a second rounding error when you SSH somewhere, so what?
    - kevin_thibedeau 7y ago
      It isn't practical on low end IoT devices which are now more than ever having to move toward encrypted communications. I work on a ~160Mhz product that typically takes 5+ minutes to generate a 2048-bit RSA key but can craft a 256-bit ECC key in 1 sec. There are no hardware resources that can speed this up. Stronger RSA is a dead end. It also chews up a non-trivial fraction of available RAM.
      - xref 7y ago
        That’s for generation, not validation. And nobody is saying you have to use RSA.
      - shandor 7y ago
        If I may ask, what SSH implementation are you using? One of the libssh's? It's always a pain when one has to forego OpenSSH because it just won't run on the low-end devices...
lvh 7y ago
Sure, use Ed25519 keys, but their cryptographic strength and convenience are only some of the reasons: they also enforce the new style OpenSSH key format (which should be the default in current releases of OpenSSH, after we released that ranty blog post that one time :-))
jlgaddis 7y ago
> Use Ed25519 keys. > ... > 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!
- kitotik 7y ago
  Assuming OpenSSH >=8.2 wouldn’t FIDO/U2F be the best convenience/security balance? It seems to work great with all the yubikeys I’ve tested with.
  - jlgaddis 7y ago
    If you're using OpenSSH >= 8.2, Ed25519 support isn't really much of a concern. The vast majority of ("enterprise") Linux systems -- and, likewise, much of the "legacy" software in use today -- likely won't be running >= 8.2 for at least a few more years.
- cookiengineer 7y ago
  > I think I'm up to nine, at last count, and the three newest ones haven't even been opened! 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?
newman314 7y ago
I wish it was common for my world. 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
dochtman 7y ago
Pretty sure Azure still doesn't support Ed25519 keys in any form. https://developercommunity.visualstudio.com/idea/462263/cant-use-ed25519-ssh-key.html https://developercommunity.visualstudio.com/idea/462263/cant... https://feedback.azure.com/forums/223579-azure-portal/suggestions/17448928-add-support-for-ssh-ed25519-keys-on-the-portal https://feedback.azure.com/forums/223579-azure-portal/sugges...
devonkim 7y ago
Not an OS but I have to note that it's not supported in some older versions of Jenkins and wasn't officially fixed until fairly recently https://issues.jenkins.io/browse/JENKINS-30319 https://issues.jenkins.io/browse/JENKINS-30319
pdeuchler 7y ago
> RSA 2048 keys are unbreakable for the foreseeable future, and using 4096 bit keys are just being paranoid with no gain 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.

by Ayesh 7y ago

mason55 7y ago

> They are now supported in pretty much every server out there 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.

ddevault 7y ago

>Setup and use ssh-agent. They make the life so easy. My #1 ssh usability tip: put this into ~/.ssh/config: AddKeysToAgent yes It'll automatically add keys to your agent the first time you use them during a session, so you don't need a separate step for adding keys every time you log in.

res0nat0r 7y ago
I've not noticed this option before, so will this replace keychain? I install this on every new laptop I use so I essentially only have to enter my ssh-agent password for the key once per reboot, and every bash shell hooks into it automatically. https://www.funtoo.org/Keychain https://www.funtoo.org/Keychain
Lammy 7y ago
Be careful; there are plenty of ways ssh-agent can bite you too. Here are a few: http://rabexc.org/posts/pitfalls-of-ssh-agents http://rabexc.org/posts/pitfalls-of-ssh-agents
- ddevault 7y ago
  This article can be boiled down to one common sense idea and one less obvious idea: 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.
  - dx87 7y ago
    It's still good info, I don't think it's obvious to most people. I was doing a pentest for a Fortune 500 company, and a key component of us compromising their entire network was a bastion host that controlled access to sensitive parts of their network. Turns out whoever controlled the machine made the rookie mistake of running a cron job as root that ran a non root-owned script, which enabled us to elevate and copy the ssh keys of a lot of IT staff.
    - ddevault 7y ago
      Good insight. You should definitely be careful with forwarding.
      - jlgaddis 7y ago
        Yes, be careful when using ForwardAgent and, more importantly, avoid using it altogether unless you absolutely need to! 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!
        manuel_w 7y ago
        Sometimes I log into a machine and would like to ssh-clone a git repository there using the private key I've got on my local machine. Is there a way around forwarding my ssh-agent in this case?
inetknght 7y ago
> It'll automatically add keys to your agent the first time you use them during a session 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.
- krferriter 7y ago
  I don't understand what `IdentitiesOnly` does. If I have `IdentityFile`s defined for hosts in ssh_config, doesn't that already accomplish what this does? Can you explain what situation `IdentitiesOnly` covers that is different from `IdentityFile`?
  - webvictim 7y ago
    Author here. If you specify an IdentityFile then that’ll be tried first (as an explicit identity) but if that doesn’t work then by default, ssh-agent identities will be tried sequentially afterwards. IdentitiesOnly suppresses that behaviour.
- shawnz 7y ago
  > If you have multiple keys in your agent, you _really_ should manually configure what key to present using `-i` or `IdentityFile`. 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.
  - kadoban 7y ago
    There's no way that's true. I just checked and I have that option set on many of my ssh aliases, and ssh-agent functions exactly as expected. 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.
keeperofdakeys 7y ago
I'd recommend you try "AddKeysToAgent confirm", then you'll get a prompt to approve the key usage each time its used. (Can be annoying for usage with automation like ansible). Having a forwarded agent was how matrix recently got hacked, confirmation is a decent work around if you need to forward your agent.

ggregoire 7y ago

> Use Ed25519 keys. They are now supported pretty much everywhere I discovered this week that AWS doesn't support Ed25519 keys for EC2 and IAM users. https://forums.aws.amazon.com/thread.jspa?threadID=250753 https://forums.aws.amazon.com/thread.jspa?threadID=250753

deleted 7y ago
[deleted]
deathanatos 7y ago
And Azure doesn't support it while instantiating a VM. Which boggles my mind since AFAICT all they have to do with the key material I hand them is to copy it into authorized_keys, not inspect it and tell me my valid key is invalid.
- nextweek2 7y ago
  And Azure DevOps Repo's.

ryanisnan 7y ago

> using 4096 bit keys are just being paranoid with no gain But at virtually no additional cost. I don't see your argument?

Ayesh 7y ago
> But at virtually no additional cost. 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.2
- xref 7y ago
  I think op is saying, at the cost of an undetectable fraction of a second rounding error when you SSH somewhere, so what?
  - kevin_thibedeau 7y ago
    It isn't practical on low end IoT devices which are now more than ever having to move toward encrypted communications. I work on a ~160Mhz product that typically takes 5+ minutes to generate a 2048-bit RSA key but can craft a 256-bit ECC key in 1 sec. There are no hardware resources that can speed this up. Stronger RSA is a dead end. It also chews up a non-trivial fraction of available RAM.
    - xref 7y ago
      That’s for generation, not validation. And nobody is saying you have to use RSA.
    - shandor 7y ago
      If I may ask, what SSH implementation are you using? One of the libssh's? It's always a pain when one has to forego OpenSSH because it just won't run on the low-end devices...

lvh 7y ago

Sure, use Ed25519 keys, but their cryptographic strength and convenience are only some of the reasons: they also enforce the new style OpenSSH key format (which should be the default in current releases of OpenSSH, after we released that ranty blog post that one time :-))

jlgaddis 7y ago

> Use Ed25519 keys. > ... > 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!

kitotik 7y ago
Assuming OpenSSH >=8.2 wouldn’t FIDO/U2F be the best convenience/security balance? It seems to work great with all the yubikeys I’ve tested with.
- jlgaddis 7y ago
  If you're using OpenSSH >= 8.2, Ed25519 support isn't really much of a concern. The vast majority of ("enterprise") Linux systems -- and, likewise, much of the "legacy" software in use today -- likely won't be running >= 8.2 for at least a few more years.
cookiengineer 7y ago
> I think I'm up to nine, at last count, and the three newest ones haven't even been opened! 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?

newman314 7y ago

I wish it was common for my world. 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

dochtman 7y ago

Pretty sure Azure still doesn't support Ed25519 keys in any form. https://developercommunity.visualstudio.com/idea/462263/cant-use-ed25519-ssh-key.html https://developercommunity.visualstudio.com/idea/462263/cant... https://feedback.azure.com/forums/223579-azure-portal/suggestions/17448928-add-support-for-ssh-ed25519-keys-on-the-portal https://feedback.azure.com/forums/223579-azure-portal/sugges...

devonkim 7y ago

Not an OS but I have to note that it's not supported in some older versions of Jenkins and wasn't officially fixed until fairly recently https://issues.jenkins.io/browse/JENKINS-30319 https://issues.jenkins.io/browse/JENKINS-30319

pdeuchler 7y ago

> RSA 2048 keys are unbreakable for the foreseeable future, and using 4096 bit keys are just being paranoid with no gain 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.