Feature #5536
open
Ability to disable server-side SSH key generation
Added by Catalin Salgau about 5 years ago.
Updated about 5 years ago.
Description
Generating a private/public SSH key pair may be user-friendly, but shipping this from the server can pose security concerns.
Please add a way to disable key generation and/or provide client client-side key generation(Web Crypto APIs are available in most modern browsers)
Thanks
Hi,
What would be the reason to disable it?
In case an end-client doesn't trust he should generate his own set of keys.
RhodeCode is meant to be used in behind-the-firewall installations where users have total control over the server, and things that come from it should be trusted.
In the same way server generates some random passwords or access tokens.
Hi,
My reasoning for this request boils down to
- some consider private keys should never be outside of the owner's direct control. Offering server-side generation undermines policies/hardware token efficiency. Leaving this to a user's trust isn't always the preferable option.
- as it stands, key generation parameters are hard-coded in RhodeCode. Enforcing other parameters cannot be done without changing deployed source code. Keyword enforcing.
I would also add that
- from a key generation perspective, since RhodeCode is deployed as a prebuilt package with bundled dependencies, directly updating to account for weaknesses is not feasible in case of security concerns (pycrypto has been unmaintained for 5+ years. there is at least one CVE-registered weakness against the project since then)
- in case of compromise, all keys generated on the server would have to be considered leaked and must be invalidated, something complicated by key reuse by users (which should be safe for PKI systems)
I would also counter your last statement. Random tokens are not one-way functions. There is a much clearer understanding of password leakage/reuse (compared to that of keys).
- Priority changed from Normal to Low
- Target version set to v4.17
I agree with your statement about the end users should generate their own keys. The reality is that lots of users aren't fully aware of how to generate SSH keys and most importantly how to generate them securely.
This is why we expose an option to generate it on the server side, it's a handy feature to means to help users, and we try to follow best at the time practices to generate the keys in a secure fashion.
Those keys are meant to protect communication with the server they are generated on, if the server gets compromised it's basically game over and the key generation doesn't matter if someone compromised the server which those keys meant to protect communication with.
Finally to say: I think we should add a .ini flag to block the generation of keys as an enforcement mechanism, but it wouldn't be a priority feature to add for us.
We'll happily take that contribution as all of this is a part of the CE codebase.
- Status changed from New to Resolved
Thanks for your contribution, it's now a part of 4.16 release.
Some note on pycrypto, we updated sshpubkeys library to the latest version which doesn't use pycrypto anymore!
+1 on security :)
closing this ticket now.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by