Deal with Jenkins password encryption when stored in a SCM - encryption

I'm currently storing the Jenkins home directory in a Git repository.
The Jenkins configuration has been initialized on a machine A: security settings (authenticated LDAP), global settings, SCM crendentials, etc...
When this Jenkins home is cloned from the Git repository on a machine B, all passwords are encrypted. And unfortunately the Jenkins master that is running on machine B can't read these encrypted passwords.
Moreover, as soon as the configuration is saved, all passwords get re-encrypted, so it seems useless to edit the configuration files manually and put passwords in plain text.
Does anyone has any idea? Thanks!

Got it! Here is the result of my research.
My initial JENKINS_HOME/.gitignore file was as follows:
# Miscellaneous Jenkins litter
*.log
*.tmp
*.old
*.json
# Generated Jenkins state
/.owner
/queue.xml
/fingerprints/
/shelvedProjects/
/updates/
/logs/
# Credentials
/secrets/
secret.key
# Job state
builds/
workspace/
modules/
lastStable
lastSuccessful
nextBuildNumber
But, taken from http://xn--thibaud-dya.fr/jenkins_credentials.html, Jenkins uses a JENKINS_HOME/secrets/master.key to encrypt all passwords, whether in the global settings or in SCM crendentials.
This made me think that the same master.key file was used to decrypt passwords.
So I've tried to remove all credential-related entries from the .gitignore file, thus allowing to push them in my Git repo and then pull them on the machine B (another brand new Jenkins master) and... it works well! All passwords are stored encrypted and since all masters share the same master.key file, all passwords can be decrypted.
Hope it can help someone else!

Related

How to hide sensitive data from node.conf?

Can someone please give me an example for corporatePasswordStore that is mentioned here:
https://docs.corda.net/node-administration.html?fbclid=IwAR0gRwe5BtcWO0NymZVyE7_yMfthu2xxnU832vZHdbuv17S-wPXgb7iVZSs#id2
I've been doing a lot of research in the last few days on how to hide the plain passwords from node.conf; it's a new topic for me and this is what I came up with so far:
Create a priv/pub key with gpg2
Create a password store with pass (using the key that I generated earlier).
Store all the plain passwords from node.conf inside that password store.
Replace the plain passwords in node.conf with environment variables (e.g. keyStorePassword = ${KEY_PASS})
Create a script file (e.g. start_node.sh) that will do the following:
a. Set an environment variable to one of the passwords from the password store: export key_store_password=$(pass node.conf/keyStorePassword)
b. Start the node: java -jar corda.jar
c. Restart the gpg agent to clear the cached passwords, otherwise you can get any password from the store without passing the passphrase: gpgconf --reload gpg-agent
Pros:
Using the bash file start_node.sh allows to set many passwords as environment variables at once (e.g. keyStore, trustStore, db passwords, RPC user password)
Since we are running the bash file with bash start_node.sh and not source start_node.sh, the environment variable is not exposed to the parent process (i.e. you cannot read that environment variable value inside the terminal where you ran bash start_node.sh
History commands are not enabled by default inside bash scripts.
Cons:
You no longer can have a service that automatically starts on VM startup, because the start_node.sh script will ask for the passphrase for your gpg key that was used to encrypt the passwords inside the password store (i.e. it's an interactive script).
Am I over-complicating this? Do you have an easier approach? Is it even necessary to hide the plain passwords?
I'm using Corda open source so I can't use the Configuration Obfuscator (which is for Enterprise only): https://docs.corda.r3.com/tools-config-obfuscator.html#configuration-obfuscator (edited)
I wrote a detailed article here: https://blog.b9lab.com/enabling-corda-security-with-nodes-configuration-file-412ce6a4371c, which covers the following topics:
Enable SSL for database connection.
Enable SSL for RPC connection.
Enable SSL for Corda webserver.
Enable SSL for Corda standalone shell.
Hide plain text passwords.
Set permissions for RPC users.

How to get Travis CI to work with a SSH Key: currently gets stuck when accessing my private rep(wants the username)

I already followed the steps exactly specified at this link
However, I am still having the issue. My build will get stuck when accessing the private repo.
$ julia --check-bounds=yes -e 'Pkg.clone("https://github.com/xxxx/xxxx.git")'
INFO: Cloning xxxx from https://github.com/xxxx/xxxx.git
Username for 'https://github.com':
Done: Job Cancelled
Note: I manually cancel it after a few minutes of waiting. How can I get it to use the SSH key I have setup and bypass this username and password field?
Note: xxxx is used in place of the name of my project to make this post general. I have already checked out the links on Travis CI and they don't make it clear what needs to occur. Thank you!
Update: I tried to add a GitHub Token Pkg.clone("https://fake_git_hub_token#github.com/xxxx/xxxx.git") and it still prompts me to sign in with the username. I gave that token full Repo access. Also, note that I am using Travis CL Virtual Machine.
In the Travis CI docs they reference the following:
Assumptions:
The repository you are running the builds for is called “myorg/main” and depends on “myorg/lib1” and “myorg/lib2”.
You know the credentials for a user account that has at least read access to all three repositories.
To pull in dependencies with a password, you will have to use the user name and password in the Git HTTPS URL: https://ci-user:mypassword123#github.com/myorg/lib1.git.
SOLUTION:
just add TravisCIUsername:mypassword#github.com/organizer_of_the_repo/Dependancy.git
In my case, I am going to make a fake admin account to run the tests since someone will have to expose their password to use this setup. Note that you can set up 2-factor authentication on the admin account such that only one person can access it even if they know the password.
You need to add the SSH key to the Travis UI under an environmental variable for your desired repo. You also need to add the key to the .travis.yml file on that repo.
https://docs.travis-ci.com is the docs for Travis
SOLUTION: just add Travis_CI_Username:my_password#github.com/organizer_of_the_repo/Dependancy.git to the travis.yml. file.
If this is unclear, please comment and I will update, but this is how I got it to work for me(even tho I went through all the SSH key business).
In my case, I am going to make a fake admin account to run the tests since someone will have to expose their password to use this setup.
Note that you can set up 2-factor authentication on the admin account such that only one person can access it even if they know the password.

Eucalyptus 3.4.2 CentOS 6 demo root password

I installed cloud-in-a-box/fastrack of Eucalyptus and am able to create instance and log into it. But when trying sudo, sudo su - or login in as root I'm asked for a password. I'm not sure what the password might be. Does anyone know what the default password for the Image is?
I think this is how the image is designed. It uses the cloud-user account only and has no root access, nor does it allow sudo.
There are other starter images available that can be "installed" that have sudo as root enabled. In those cases you simply issue
sudo su -
and you become root.
To see what is easily available use:
eustore-describe-images
As a note, some of the other starter images have different accounts (not cloud-user), such as ec2-user. If you don't know which account to use simply try to ssh into the instance as root and it will usually get a message back telling you:
Please login as the user "ec2-user" rather than the user "root".
I am not sure if there is a password on the root account in that image. Regardless, the recommended way to log into instances is by creating an SSH key (euca-create-keypair KEYNAME >KEYNAME.pem), specifying it when running an instance (euca-run-instance -k KEYNAME), and then logging in using the key generated (ssh -i KEYNAME.pem root#INSTANCE-IP). You'll probably have to change the permissions on that .pem file before SSH will allows you to use it (chmod 0600 KEYNAME.pem). The instance obtains the public portion of the key from the cloud at boot time and adds it to the authorized_keys file.

Please give me some info about modify jftp code

The use case is when a user logged in, the remote directory should direct to his own home directory rather than the root directory.
For example, when Tom logged in, the target directory should be /class12/boy/Tom, and Marry logged in, the directory should be /class12/girl/Marry, rather than /class12.
I do not know which part do I need to modify, I downloaded the source code from http://j-ftp.sourceforge.net/.
Appreciate for your help.
jftp looks like an ftp client:
In short: JFtp is a graphical Java
network and file transfer client.
However, the behavior you desire can only be handled on the server side. EG, for SFTP (over SSH), you need to look into some kind of chroot or jail. For FTP, most daemons usually allow you to configure the paths your user can access, so you would edit the ftpd config file appropriately and restart the ftpd process.
If you do not have access to the server, then you will need to contact your server administrator / provider to make the necessary arrangements.

ASP.net permissions to root certificate store

Is it possible to give asp.net read permission to the certificate store?
If yes , how?
If no... do I need to set the permission manually per certificate file?
If yes where are these files physically on the HDD?
Generally you give permissions to A certificate. I use a method like this to find the custom made cert and grant permissions. If you are using a cert issued by a public entity like Verisign, Thawte, etc, this is probably unnecessary.
FindPrivateKey.exe My LocalMachine –n "CN=<certificate issuer>"
...will find certificates on the local machine in the personal store for a particular issuer.
Note: If FindPrivateKey is not on your local machine,
download the WCF samples, including the FindPrivateKey tool, at
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21459
FindPrivateKey returns the location of the private key for the certificate, similar to
"C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\Machinekeys\4d657b73466481beba7b0e1b5781db81_c225a308-d2ad-4e58-91a8-6e87f354b030".
Run the following command line to assign read only access permissions to the process identity of the ASP.NET/WCF Service
cacls.exe "C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\Machinekeys\4d657b73466481beba7b0e1b5781db81_c225a308-d2ad-4e58-91a8-6e87f354b030" /E /G "NT AUTHORITY\NETWORK SERVICE":R
NOTE: If you are running Microsoft Windows® XP, give the certificate permissions for the ASPNET identity instead of the NT Authority\Network Service identity, because the IIS process runs under the ASPNET account in Windows XP.
Certificates are viewable from the MMC snap in for Certificates. Open MMC, choose File --> Add/Remove Snap in, click the add button and choose certificates. From here you will need to choose the appropriate store (usually Computer Account - Local Computer for ASP.NET items) to manage and then you can view/admin the certs.
Please take a good hard look at the different command line options, and make sure that you have a clear understanding of what certificates are and how they work before granting any permissions.
The network service account that asp.net run under by default doesn't have access to the local machine personal certificates. Grant access by the following:
Repost from Sohnee # forums.asp.net
Step 1 - if you don't already have it
installed - get WinHttpCertCfg
Step 2 - if you already have the
certificate installed on the machine
and you just need to grant access to
Network Services:
WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s "IssuedToName" -a "NetworkService"
Don't really like answering my own questions, but one simple way to get rid of this error is just to give network service full access to the c:\drive, and propagate permissions down.
You'll shoot me down I know, telling me how bad this is - but it works.

Resources