We are installing jenkins on the rental server and trying to build a development environment using virtual machines.
However, when you log in to the virtual machine with ssh from jenkins and git pull
to github, the job hardens.
Development laptops
Debian GNU/LINUX 8.0
Guest virtual machines in laptops
VMs:VirtualBox 4.3.30
OS:CentOS 6.6
mem —512MB
HDD: 8.0GB
Host only adapter for host communication ->eth1192.168.56.10
NAT (for Internet use)
working users:vagrant
jenkins server (rental VPS, fixed IP, root privileges)
OS:CentOS 6.6
mem: 1GB
HDD: 50GB
working users:jenkins
Supplementary
The host PC and guest virtual machines do not have static IP, so the connection to the jenkins server is tunneling using ssh forward.This tunnel has successfully secured communication.
The Jenkins server and github have been configured to work together and have been able to confirm their cooperation (when pushed to github, jenkins jobs can be invoked).
Successfully logged in to the guest virtual machine from the jenkins server through the ssh plug-in in jenkins.
The github key registers the jenkins server and guest virtual machines separately and has a private key.
I want to code and develop on the host laptop and automatically pull from the github via jenkins when I push to the github.
In the build environment, insert the ssh plug-in and select Run Shell on Remote Host.Guest virtual machines can be logged in as vagrant@localhost:10022
using a private key (with pty enabled)
Configured Shell Script
cd/var/www/html/hoge
git pull
For the build environment, insert the ssh plug-in and select Run Shell on Remote Host.Guest virtual machines can be logged in as vagrant@localhost:10022
using a private key (with pty enabled)
Configured Shell Script
cd/var/www/html/hoge
git pull
When I originally started the job in this state, the play job failed because the private key passphrase to enter the github was not included.
~(some omitted)
~~
cd/var/www/html/force
git pull
Permission denied (publickey).
fatal —The remote end hang up unexpectedly
SSH exit-status: 1
Finished—FAILURE
So I started ssh-agent on the guest virtual machine, registered the key passphrase with ssh-add in advance, and started the job again, but it didn't play, but the job hardened. (The round and round mark keeps moving)
Enter the guest virtual machine directly from the development laptop or from the jenkins server (after logging in to the jenkins server as a jenkins user from the development laptop with ssh) with SSH and git pull
will succeed.
In my understanding
Development Laptop ->github ->jenkins Server ->Guest Virtual Machine ->github
and so on, eventually logging in to github using the guest virtual machine's private key.
I think the problem this time is probably about how to insert the key passphrase, but I have little experience and have not been able to solve it.
I'm sure some of you may think that this configuration is strange, but personally, I will need to build a development environment using ssh forward in the future, so I would like to tell you how to solve it now.
Thank you for your cooperation.
I searched on the web and found that I could enter a passphrase with the command expect.
I immediately created a shell script with expect, and the passphrase was successful and pull succeeded.
#!/usr/bin/expect
expect-c"
set timeout5
spawn git pull
expect\"Enter passphrase for key'/home/vagrant/.ssh/id_rsa':\"
send\"Passphrase\n\"
interact
"
As a result, the job was successful, but expect requires a passphrase in the shell script and does not seem to be in a very favorable condition.
If possible, I would like to do it in a way that makes sense for security.
Thank you for your continued support.
github ssh jenkins
It depends on the security policy, but my personal opinion is that passphrase is not necessary except for the following:
Also, ssh-agent is a factor in lowering the security level, so it's good or bad.
When you run the ssh-agent, it moves in the background and waits for connections from the ssh client.
Environment variables are required to utilize ssh-agent from the ssh client.
Booting without arguments displays the command to set the environment variable.
$ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-xNQEONNXVGC6/agent.8228;export SSH_AUTH_SOCK;
SSH_AGENT_PID = 8716; export SSH_AGENT_PID;
echo Agent pid 8716;
If there are arguments, start the argument program to set the environment variable automatically.
$ssh-agent bash
$ ← Nothing is displayed, but a new bash is started.
$ echo$SSH_AUTH_SOCK
/tmp/ssh-xNQEONNXVGC6/agent.8228←Environment variable set automatically
$ echo$SSH_AGENT_PID
8716 ← Environment variable set automatically
When the ssh-agent exits the shell from which it started, the ssh-agent stops and the environment variables are discarded.
$exit←ssh-agent terminates launched bash
exit
$ ← Returned to original shell
If you want to use eval as an alternative method, let the current shell read the command that ssh-agent outputs.The difference from 引with arguments との is that environment variables are set on the current shell.
$eval`ssh-agent`
Agent pid8716 ← ssh-agent process ID displayed
$ echo$SSH_AUTH_SOCK
/tmp/ssh-xNQEONNXVGC6/agent.8228←Environment variable set automatically
$ echo$SSH_AGENT_PID
8716 ← Environment variable set automatically
Specify the -k
option to stop the ssh-agent.
$eval`ssh-agent-k`
Agent pid 8716killed
The ssh-add-l
result says Could not open a connection to your authentication agent
, so you can see that you are not able to connect to the ssh-agent.This may be because the above environment variables are not enabled in Jenkins jobs.
Try setting the environment variables for SSH_AUTH_SOCK
and SSH_AGENT_PID
in Jenkins jobs.However, I have to change these environment variables every time I restart the ssh-agent process, so I think it would be better to write them in some configuration file instead of hard coding.
In addition, users who run Jenkins jobs must have access to socket files created by ssh-gent.Try setting up access rights as appropriate.
$ssh-agent>/hoge/foo/bar/agent.conf ←Leave in the configuration file
$ event`cat/hoge/foo/bar/agent.conf`← Read the configuration file and set the environment variable
$ ssh-add....←Add key
The following example grants permissions for the group:
$sudo chgrp jenkins$SSH_AUTH_SOCK←Change the group of socket files to jenkins
$ chmodg+rw$SSH_AUTH_SOCK← Allow read/write for groups in socket files
$eval`cat/hoge/foo/bar/agent.conf`←Read the configuration file and set the environment variables
$ git pull
© 2024 OneMinuteCode. All rights reserved.