Feature #5536: Ability to disable server-side SSH key generation - RhodeCode CE/EE - RhodeCode - issues

Actions

Copy link

Feature #5536

open

Ability to disable server-side SSH key generation

Added by Catalin Salgau almost 6 years ago. Updated over 5 years ago.

Status:

Resolved

Priority:

Low

Assignee:

Category:

Target version:

v4.17

Start date:

11.02.2019

Due date:

% Done:

Estimated time:

Sorting:

Commit Number:

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

Actions

Copy link

Updated by Marcin Kuzminski [CTO] almost 6 years ago

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.

Actions

Copy link

Updated by Catalin Salgau almost 6 years ago

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).

Actions

Copy link

Updated by Marcin Kuzminski [CTO] almost 6 years ago

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.

Actions

Copy link