Is adding private key to Jenkins credential list a security breach?

[John Cho]

Hi,

I am reading thru how to set up slaves on Jenkins using ssh keys.   Read thru about three articles on how to do that.   According to them, the setup is based upon using the slave as a ssh server with public and private keys and it adds the slave's private key to the Jenkins master's credential instead of the slave's public key.  Private key should never be shared.   Any thought on this practice?   Or, am I missing any?   Thanks in advance.

[thomas....@teamaol.com]

It's a matter how it is organized ...

If administrators only (a limited number of persons) have access to the manage section in Jenkins then it's probably a first step.

Also an option might be to use Vault.

[Stephen Connolly]

So when you add a private key for use to connect to agents, that private key will be in the System store. The System store maintains two scopes: SYSTEM (which is only available for "system" tasks and not available to build jobs) and GLOBAL (which is available for both "system" tasks and build jobs)

A secured Jenkins server will not permit build jobs to run on the master's JVM, only on agents. Thus no build job will ever have access to the master's filesystem.

Next, if the key is important to you, you should be storing the key protected with a passphrase. The passphrase in Jenkins is encrypted so that should add an extra layer of security (as somebody need to grab the master key for Secret as well as your SSH private key)... 

There are some issues that people have found in plugins when using SSH private keys that are protected by a passphrase (these are in general due to the plugins using those credentials on agents incorrectly... doing bold things like bringing classes that are intended to be instantiated only on the master JVM over to the agent JVM and trying to instantiate those classes there... unsurprisingly such things do not work... but the poor innocent credentials plugin gets the blame... I am pushing to make the root cause more visible in JENKINS-38370 to JENKINS-38373) some people suggest that one should not use passphrase protected private keys in Jenkins because of the bad coding issues in plugins... I disagree... 

at least for the use case of a private key being used to *launch* a build agent... such private keys... if you value their security... should be encrypted with a passphrase and stored with SYSTEM scope in the System store, if you ensure that the master has 0 executors then that will make the key as secure as can be. Rotate the key on a semi-regular basis for extra security.

On 18 September 2016 at 18:57, John Cho <202...@gmail.com> wrote:

Hi,

I am reading thru how to set up slaves on Jenkins using ssh keys.   Read thru about three articles on how to do that.   According to them, the setup is based upon using the slave as a ssh server with public and private keys and it adds the slave's private key to the Jenkins master's credential instead of the slave's public key.  Private key should never be shared.   Any thought on this practice?   Or, am I missing any?   Thanks in advance.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/3fcfb4ae-0e96-4efb-8c36-f9a75e76e65f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Lasevich]

You got it backwards, master connects to Slave using standard SSH Pub/Private key auth. So, since the master is connecting to slave, you are not putting Slave's private keys on Master, you are putting Master's public key on Slave. While this looks like same thing physically, logically it explains why private key belongs to Master. Of course for extra convenience, you can use different keypairs for different slaves - but that is optional.

-M