All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
VPS providers, PLEASE support ssh-ed25519 keys along with ssh-rsa ones in your VPS control panel
Dear VPS providers,
If you provide a custom control panel for your customers that allows them to automatically add SSH keys, please make sure that you support not only ssh-rsa but also ssh-ed25519.
For RSA keys, attack succeeds by factoring the modulus. Integer factorization is a long-studied problem; with the best known algorithm, breaking a 2048-bit RSA key (i.e., a RSA public key whose modulus is a 2048-bit integer) requires about 2^110 or so elementary operations.
For EdDSA keys, the public key is a point P on an elliptic curve, such that P = xG where x is the private key (a 256-bit integer) and G is a conventional curve point. The best known algorithm for recovering x from P and G requires about 2^128 elementary operations, i.e. more than for a 2048-bit RSA key. In general, to break a n-bit elliptic curve public key, the effort is 2n/2.
Breaking either key is way beyond that which is feasible with existing or foreseeable technology. But in an "academic" viewpoint, the EdDSA key is somewhat stronger than the RSA key; also, elliptic curves give you more security per bit (technically, we say that integer factorization is a sub-exponential problem).
Even Vultr supports ED25519:
I have to mention at this point that SSH-RSA works on Debian 5 and CentOS 5 (most likely even lower, but not tested), but SSH-ED25519 only works on Debian 8 and CentOS 7 and upwards (unless you backport libssh). Amazon Web Services used this statement as an explanation why they are not supporting SSH-ED25519 yet, but they probably would come up with a similar bullshit explanation when I go ask them why they didn't start rolling out IPv6 to EC2 way earlier already.
I recently noticed that a lot of other VPS providers don't support SSH-ED25519 pubkeys, while they do go into ~/.ssh/authorized_keys like SSH-RSA pubkeys do as well:
One of which is Amazon Web Services, one of the largest VPS providers as we all know, right? RIGHT?!
Anyway, another VPS provider that I noticed only supports SSH-RSA was DevCapsule. While they did initially only support SSH-RSA, I told them that ssh-ed25519 is also a thing and they promptly implemented that into their system (I still need to try it out though) unlike Amazon who still only supports SSH-RSA.
So far I've seen a lot of VPS providers do that kind of thing to their customers, haven't made a list though. But please, if you are a VPS provider reading this and having your own, custom VPS control panel that allows customers to automatically deploy SSH pubkeys to their VPS instances, make sure to allow them to use ED25519 as well.
Comments
This is a problem. It forces if/else scenarios that upset customers. Customers rule the industry. If you want change don't appeal to the providers, appeal to the customers.
I wouldn't worry about that. I worry about that around 20% of my customers say "What SSH key? Where is my password???"
"along with ssh-rsa ones" in the title implies that this is only for VPS providers who already offer SSH-RSA keys to be automatically deployed to servers. There is obviously no point in implementing this entire thing afterwards, but it makes me cringe when I see a VPS provider offering automatic deployment of SSH keys only supporting SSH-RSA.
If someone figures out how to break the RSA keys we use now, we're in much worse trouble than having some silly VPS's busted into.
I think we only support RSA but now I cannot recall. I use RSA right now, but I'm also still using Cent6 and Ubuntu 14 primarily.
It's always a tough call. There's always an absolute "This is the best thing to do for security" and a "This is the best thing to do to please your customers in a simple manner." Reconciling the two can just be so difficult. You're no stranger to that, obviously, preaching to the choir here
hm? There were reverse cases already, mostly by bad RNG - This can happen at any time again and while ED25519 is not 100% secure against it there are security advantages. The US NIST also manipulated around in RSA while ED25519 was external developed.
Further RSA can be cracked nearly immediately once there is any meaningful quantum computer able to run Shor's algorithm, ed25519 is not "quantum safe" entirely but needs a different setup.
Ubuntu 14 does ed25519.
a) which algorithms are supported depends on the ssl/ssh version (and not on the OS)
b) What's the problem anyway? Enter whatever the panel offers, say, RSA, then
and be done and have ed25519. Just enter the desired key into your local config and ssh will use that ECC key from then on.
@William
Not really. A quantum computer capable to run Shore and similar will crack both RSA and ECC. The algorithms, while being different, have very similar underlaying number-theoretical properties. Both would be broken.
Still ECC has some advantages. One you mentioned is that some ECC algorithms are not nist tainted. Another one is that ECC has higher algorithmic complexity.
But still, RSA is not shitty or useless. It's about in the same ballpark as ECC and for both size is of the essence.
Plus there is a practical aspect where ECC clearly wins: key size. That is a very desirable property for many reasons, one of them being that it's more lightweight and cheaper to transmit ECC keys which also will always fit into a single packet incl. HMAC and header.
I never said different, however there are proven higher resource needs to reverse ed25519. Also does NOT disprove that multiple RSA variants have been proven backdoored or weakened which drastically reduces the complexity needed for a full Shor (no e....) run, different RNG usage also worked around issues there in past papers.
Backdoored? What's to backdoor with multiplication?
Probably you mean RSA key generation which really often has quite some weak points, in particular weak random generation.
The real killer with RSA, however, is the fact that its design relies on prime modules while actually every wide spread software is based on probable primes. This translates to a) many, many worthless keys out there (no matter the size) and b) an immense advantage for a very powerful adversary (like nsa).
But, for the sake of fairness, we also have plenty reason to consider quite some ECC curves to be tainted ("backdoored"). ED25519, however, is considered high quality.
Poll not found.
I don't understand where you're seeing a usability problem?
As far as I can tell, that if/else scenario would only improve the customer experience, by allowing them to do something they were not previously able to do. Hell, it'd even give them a useful hint if they tried to select a distro that doesn't support the key they already have - previously, they'd only find out after installation, and have to reinstall!
Keys are generated by the customer themselves, so what types of keys you support in a panel would have absolutely no effect on what types of keys the customer has.
User has ED25519 key, distro does not support it: User wastes valuable support time complaining how "the panel did accept his key but he could not connect"
No, it wouldn't? That's a matter of spending 30 minutes adding a list of "ed22519-supporting distro" flags to your panel code, and it just wouldn't even accept them for distros that don't support it.
I understand the request, my question is this:
How do you get to the point of understanding what you wrote and still give 2 craps about putting your key in a web UI which is probably vastly less secure in terms of than anything you have described so far?
I don't really see how it would be. It's a public key, it's not supposed to be secret.
New Poll: How long until @AnthonySmith 's coronary bypass? Will it be blamed completely on his involvement in LES/LET?!
Sorry, I was not clear, I was not so much referring to the security mechanism of adding a public key, I was more referring to the fact that your VPS is accessible via a publicly accessible php based (probably) web UI that you probably access with a username and password to begin with.
in short, it seems a bit of a silly thing to worry about, like adding a vault door to your house but keeping glass windows.
I dunno, was just adding perspective.
No chance, crisps/potato chips are the 100:1 favorite
I'm not sure why, but for some reason I feel insulted that you needed to explain what crisps are to me. Have I just been on LET long enough that I'm becoming feral from everyone pissing on everyone else's leg?
It was not for your benefit, more for the North American/English as a second language audience
omnomnom
I'm a yank, too.
Oh, I don't know if its the profile picture or what but I assumed you were South African.
I am so going to call down the JUJU on you..
duiwel!
That is why I just use keyboard interactive passwords on non-standard ports.
Depends on implementation. Most panels will only allow you to specify SSH keys during deployment, and do not allow any privileged access once it's running. So generally, the worst thing somebody can do is using up your snapshot space or killing off your VMs.
Thats pretty bad
or boot in single user/rescue.
Sure, it's still bad, but it's a different class of problem than what SSH keys primarily protect you against - namely, privileged access to your system (and the information contained therein). This is why it makes sense to want support for stronger SSH keys in a web-based panel - it will still improve your security insofar privileged access is concerned.
As for booting in single user mode, FDE will help with that.
Well fair enough, just seems like a vault door and glass windows situation to me which is why I was curious as to why.