After being unable to clone a private github repo inside a TeamCity command line build step, even when making sure the ssh-agent was running with the correct key, I found this answer: Team City Git "Host key verification failed"
How to do what this answer suggests? How do I run my TeamCity job under a different account than "System"?
If you are running TeamCity agents as a Service on Windows, then go to Server Manager -> Configuration -> Services. Find your TeamCity agent there, right click to see Properties, and go to Log On tab, where you can change default Local System account to anything you want:
Related
I have been trying to connenct a private Git repo to my Jenkins server which runs on a Windows. I have installed the GitHub plugin and I can get it working when the repo is public, but when I switch to private repo it gets stuck on the
> git.exe fetch --tags --progress https://github.com/-Username-/-repoName-.git +refs/heads/*:refs/remotes/origin/*
Does anyone know how to fix this?
I had the same problem! I fixed it by changing the service of Jenkins from local system to local user. Beware that the service doesn't always start well. I would recommend changing it from automatic to automatic delayed. This will give your PC the time to login and then start this service.
You can find services in Windows icon > Typing Services & opening it > Press J to instantly go to the Jenkins service and the rest is self explaineble.
We have an in-house TFS 2013 update 4 on Windows Server 2008 R2 Standard (TFS server), with Git version 2.5.0.windows.1.
Our TFS build process uses InvokeProcess activity to call Git from a batch file.
These are the calls to git we make from the batch file (in two lines for debugging purposes):
call git submodule init
call git submodule update
It is the second line that is giving me a problem, as shown below:
When I run the same batch file on the server manually (even from non-admin cmd.exe), all executes as expected, i.e. I am not prompted for any usernames or passwords.
We are currently using wincred as our credentials helper, having tried:
winstore,
git-credential-store,
adding generic windows credentials via Credentials Manager (tried both git:http://xxxxxx:8080 and just http://xxxxxx:8080).
setting credentials in .gitconfig globally and per repo.
Interestingly, Microsoft.TeamFoundation.Build.Activities.Git.GitPull has no problems cloning the superproject, but if I was to prompt Git to clone and pull via a batch file, I am getting the same "fatal: could not read Password" error.
Unfortunately, we do not have an option of upgrading to TFS 2015, where loading submodules is apparently a matter of ticking a check-box. Including username and password as part of the command in plain text is not an option either.
What do I need to try/do to allow Git to read the required Password using wincred?
All thoughts and suggestions will be much appreciated...
The main problem was the fact that our TFS Build service was running under NETWORK SERVICE account, as opposed to the account which I was entering passwords for.
Steps that I took towards the solution (as alternative to using TFS Admin Console):
On TFS Server, go into Services (services.msc), and locate "Visual Studio Team Foundation Build Service Host 2013" service among "Services (local)".
Right-click on the service, and on "General" tab click "Stop"
On "Log On" tab, select "This account" and enter the details of the account you validated with wincred (it is assumed that this account exists under "Project Collection Build Service Accounts" and has all the required rights for your repos).
Take note of the email address as it is displayed after "Check names" has been clicked.
Click "Apply"
Back on the "General" tab, click "Start".
Do the same for "Visual Studio Team Foundation Background Job Agent" service (I did that for consistency with the build service).
A few more points worth checking:
In your user account directory on TFS Server, ensure that the email address you saw after "Check names" in step 4 matches the email address used in the 'email' field under [user] in .gitconfig.
Ensure you get prompted for credentials at some point by wincred (I did that by running "git config credential.helper store" first, then running "git config credential.helper wincred" (if you want to do "git config --global credential.helper store", followed by "git config --global credential.helper wincred", then you'll need to run your cmd.exe with elevated permissions).
In my case the correctly saved credentials looked like this (in Credential Manager, under "Generic Credentials") - notice the absence of a username:
Hope this helps somebody with the same issue!
I need some help here, It's been a week I'm with this problem, can't figure out what's going on. I'm not able to clone a git repo from a slave node (Jenkins). I added the ssh key, host and slave (I've already tried generating a single key and one for each virtual and host)).
On Jenkins:
url:git#github.com: < repo>
Credentials: Here I tried with username/password, username with ssh file, username with ssh key directly, and -none-.
It doesn't seems like there is an authentication problem since I can clone the repo manually from console (both, slave and host). I can also connect with
ssh -T git#github.com
so the ssh key is fine, but when I build, this appear on console:
Building remotely on IE10Win7 in workspace C:\Users\IEUser\Desktop\<
folder >
Wiping out workspace first.
Cloning the remote Git repository
Cloning repository git#github.com:< repo>.git
git init C:\Users\IEUser\Desktop\< folder> # timeout=10
ERROR: Error cloning remote repo 'origin'
ERROR: Error cloning remote repo 'origin'
Performing Post build task...
Does anyone have an idea? Hope someone can give me a clue, Thanks!
I fixed this problem by setting the slave node tool path, selecting git and setting its value to
C:\Program Files (x86)\Git\bin\git.exe
Location: Configure Node - Tool Locations
I recently updated several jenkins plugins and had this problem after the updates. Rolling back the git plugin didn't help, but I did a few other things to get it working. I listed all three here, but it was probably (2) that fixed the problem. Apparently the git executable was reset to default. So, configuring the git executable within the specific project was probably all that was needed. However the other items might come in handy too.
(1) The default git on a jenkins linux install geenrally points to /usr/lib... You need to specify a separate GitForWindows that points to the windows version:
Manage Jenkins
Configure System
Under Git - Git Installations
Add Git -> Git
Give it a name to be referenced in projects
(mine is WindowsGit)
Set Path to Git Executable
(mine is "C:\Program Files (x86)\Git\bin\git.exe")
(for recent git the path is "C:\Program Files\Git\bin\git.exe")
(2) Configure git on the specific project:
Select the project
Select Configure
Under Source Code Management - Git
Select Git Executable as configured in 1)
Set credentials or add new (ssh keys, etc)
(3) Updating the jenkins slave service to run as a specific user:
Go to Windows Services on the slave -- StartMenu, type "services"
Select the Jenkins Slave service in the list on the right
Right-click and select "Properties" of the Jenkins Slave service
Select the "Log On" tab
Update the username and password used in manual tests
Domain login can be specificied with <DOMAIN>\<USERNAME>
Local logins just use <USERNAME>
OK to save and exit
Right-click again and select "Restart" to make the changes active.
I found a decent workaround in my case. The git clone command always inherits its process owner, which may make a difference, even if the two owners of Jenkins (SYSTEM) and cmd (USER) seem to have the same rights on your system. All other configurations were identical (keys, knownhosts, Git client version).
So as far as I can see, calling git clone from cmd will succeed because it calls the remote as USER, whereas git clone called from Jenkins may be rejected because it calls the remote as SYSTEM. In Services, where you would typically start Jenkins through the GUI, you can configure the service to run as a different user (right click on service --> Properties --> Log On). I had to put it like USER#DOMAIN, e.g. Jenkins#company.local or so. I'm not sure about how a cmd parameter would look, but I'd expect there to be one.
Also, I don't quite know what difference this workaround makes in the end, because on my Jenkins, SYSTEM and USER are configured to have the same rights across the system and they are of course both recognized as "Jenkins" by remote. Still, it does the trick for me. Deeper insights welcome.
I was facing similar problem and found that I need to add git to my PATH environment variable for a Windows based slave. I think that #dhj suggestion 2 might work as well in this case.
I found this workaround on Jenkins Jira.
In my case, I started getting this exact error after updating Git on some of my build machines (via Chocolatey, using the "git.install" package) from 1.9.4 to 2.5.0. The old 1.9.4 install was a 32-bit package but the new one is a 64-bit one, so the default install location switched from C:\Program Files (x86)\Git to C:\Program Files\Git. I had the 64-bit path configured on the Jenkins master (since it had the newer Git version), but some slaves still had the older 32-bit version installed, so the slaves were attempting to use an incorrect path. I could have overridden the Git path for individual slaves but the cleaner solution for me was simply to upgrade all the slaves to the newer 64-bit version.
I tried most of the above:
Specify git location.
Set service user.
Run as Administrator.
None of it worked. Eventually decided to uninstall git64 and install git32... changed the git path to the new location (in x86 Program Files). And everything worked.
I ran into this issue recently.
We had some items in our PATH EV which we had added when trying to connect Winium and Selenium to our Jenkins instance.
We removed these items, but still Jenkins seemed to be holding on to the values. After a bit of troubleshooting: restarting Jenkins; restarting the Jenkins server; setting the EVs at the node level; etc., we restarted the Jenkins JNLP service on the Windows slave.
And they lived happily ever after.
I also got the same error and fixed by adding a git path in the "Manage Jenkins -> Global Tool Configuration".
In my env, The windows Jenkins master run a job on the ubuntu slave machine, the master machine has used the default git ('C:\Program Files\Git\git.exe') path and the slave machine has used the git ('/usr/bin/git') path, therefore, I configured slave git path into the master configuration '/usr/bin/git' and its start working for me
I am setting up Jenkins on a Win 2008 server machine and am having some trouble configuring Jenkins to connect to GitHub. I get the following error:
Command "git.exe fetch -t git#github.com:USER/REPO.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: Permission denied (publickey).
fatal: The remote end hung up unexpectedly
ERROR: Could not fetch from any repository
FATAL: Could not fetch from any repository
hudson.plugins.git.GitException: Could not fetch from any repository
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:950)
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:908)
at hudson.FilePath.act(FilePath.java:758)
at hudson.FilePath.act(FilePath.java:740)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:908)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1184)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:537)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:425)
at hudson.model.Run.run(Run.java:1376)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:175)
Things I Have Checked
The Jenkins service is running under my username.
I changed my SSH key so it no longer has a password.
I have verified my SSH key is valid by executing the same command as Jenkins using msysgit.
Verified all my paths are correct.
Jenkins Configuration Settings
Jenkins 1.418
GitHub plugin 0.5
Git plugin 1.1.9
msysgit Works but CMD Prompt Does Not
When I navigate to a valid repo and execute the command from the DOS prompt, it also fails.
Do you have any idea what I may be missing?
Thanks for your help.
As I commented, specifying the HOME environment variable is key, when using ssh protocol.
Since Windows doesn't have a HOME, you need to define it explicitly, to whatever directory you want.
However, Vestnik comments:
I've specified to override HOME on the windows slave node to point it to C:\jenkins.
I've put correct id_rsa under the C:\jenkins\.ssh but still have this issue.
My slave agent running as service under SYSTEM account.
Similar issue: "Problem with Hudson + Git + Gitosis on windows"
Similar resolution: "Problem with Hudson + Git + Gitosis on windows"
Two advices:
you need to make your slave display 'set' in order to check if HOME is defined when used with the SYSTEM account.
If it is not, that may mean you need to add that variable to the "system environment variables", not the "user environment variables".
Don't forget to have both id_rsa and id_rsa.pub in the %HOME%\.ssh directory: you need both public and private ssh keys. (as mentioned in "git clone with ssh issue")
If you have a parametrized build, you also can define HOME that way and check if your slave picks up the right value for HOME:
There are two plugins in jenkins related to ssh that can be used: Publish Over SSH and Jenkins SSH plugin.
The first plugin gives the availability to set a global ssh key and the second plugin gives the availability to set various ssh keys.
Next you need to install two more plugins that will be used in the project configuration GitHub Plugin and Jenkins Git Plugin.
The GitHub plugin will be used to set the GitHub project.
The Jenkins Git plugin will be used to set the "URL of repository" and other things like a branch etc.
All the plugins are available from the tab available in the Jenkins Plugin Manager.
Copied from my blog post, on the topic:
Jenkins configuration:
The Jenkins SSH plugin give the availability to set private key per host, the second plugin do the job for a global host.
If Jenkins SSH plugin is used, then in SSH remote hosts write the host, user, passphrase and the path to the private key.
If Publish Over SSH is used, then in SSH setting write the passphrase and paste the private key or write the path to it.
The project configuration is:
GitHub Project https://github.com/GitUser/iOS-project/
*Source Code Management
-> Git
-> -> Repositories
-> -> -> URL of repository: git#github.com:GitUser/iOS-project.git
-- It is up to you configure a branch or take the default one --
*Build Triggers
-> Poll SCM -- Seted --
-> Schedule: * * * * *
*Build
-> Executed Shell
-> -> Command: xcodebuild -target iOS-project -configuration AdHoc -sdk iphoneos5.0 clean
-> -> Command: agvtool new-version -all $BUILD_NUMBER
-> -> Command: xcodebuild -target iOS-project -configuration AdHoc -sdk iphoneos5.0
-> -> Command: xcrun -sdk iphoneos5.0 PackageApplication -v $WORKSPACE/build/AdHoc-iphoneos/iOS-project.app -o $WORKSPACE/build/AdHoc-iphoneos/iOS-project-$BUILD_NUMBER.ipa PROVISIONING_PROFILE="<provisioning profile>"
-> -> Command: curl http://testflightapp.com/api/builds.json -F file=#$WORKSPACE/build/AdHoc-iphoneos/iCushion-1.0-$BUILD_NUMBER.ipa -F api_token=<api_token> -F team_token=<team_token> -F notes="This is an autodeploy build from Jenkins!" -F notify=True -F distribution_lists="<distributedlist 1>, <distributedlist 2>"
It appears the git plugin now provides a way to point Jenkins to the home directory.
Click the credential add button.
Point Jenkins to your private key.
Select the newly-added credentials from the list.
In my environment (Jenkins 64-bit with Java 32-bit, running in a Windows Server 2016 64-bit), the solution was put the key in the C:\Windows\SysWOW64\config\systemprofile\.ssh folder. According to the Git Plugin documentation:
By default, the Jenkins Windows installer sets up Jenkins to run as a service on Windows, which runs as the “Local System account”, NOT your user account. Since the “Local System account” does not have SSH keys or known_hosts set up, “git clone” will hang during the build. It's possible to keep Jenkins running as the “Local System account” and clone repositories via SSH by making sure that the “Local System account” is set up with a properly configured .ssh directory (i.e. id_rsa, id_rsa.pub, AND known_hosts)
Before anybody shoots me down for this - I have already checked every appropriate thread and still not found a solution to my problem.
I have Hudson with git plugin installed on windows server (not my choice) and Hudson runs as a service. Git/bin is on the path. However I cannot clone the repository. Here is a shortened display of the console output:
Started by user anonymous
Checkout:workspace / C:\.hudson\jobs\sdf\workspace - hudson.remoting.LocalChannel#65394b
Last Built Revision: Revision 74200b32314231a5efdadd87bf36b42ec145c720 (origin/master)
Checkout:workspace / C:\.hudson\jobs\sdf\workspace - hudson.remoting.LocalChannel#65394b
Fetching changes from the remote Git repository
Fetching upstream changes from ssh://git.mccannlondon.co.uk/git/mccann_admin
[workspace] $ "C:\Program Files\Git\bin\git.exe" fetch -t ssh://git.mccannlondon.co.uk/git/mccann_admin +refs/heads/*:refs/remotes/origin/*
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 f1:48:2a:0a:d9:18:cf:2e:f2:8c:b3:25:7f:34:d5:34
Connection abandoned.
fatal: The remote end hung up unexpectedly
ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway
So it seems I need to authenticate the host however I'm not sure why hudson is starting the job as user anonymous when I have set the Administrator as owner of the hudson service.
Does anyone know:
a) how to change hudson's run user? or
b) connect to the remove computer with the same user account as hudson uses as to allow hudson to fetch?
If this has been posted before apologies but I spent a good few hours searching around and couldn't find anything.
Thanks
Lewis
This may be related to the question Git, Can’t clone repo on windows
The problem is that MSysGit starts PLink in the background, i.e. the terminal is not actually connected to the input of PLink. That means that you simply can't type anything into PLink.
You simply have to connect to the server once using PLink or PuTTY, answer Yes and from then on, you won't be asked again.
The tutorial from cletus can be helpful as well.
A good description of the issue can be found in this blog entry
the problem is that Hudson is a service and runs under the user "Local Service Account".
The next step is to add the trace manually the cache (a file) because I know you can do in Linux.
Wrong again, Windows does not have this cache as a file but uses the registry.
Searching in the register found an entry for my user (who had previously accessed the repository and added to the cache footprint) where the trace was stored and copied to HKEY_USERS so that users can access it.
The entry goes like this:
Key Name: HKEY_USERS\.DEFAULT\Software\SimonTatham\PuTTY\SshHostKeys
Class Name: NO CLASS
Last Write Time: 23.01.2009 - 18:35
Value 0
Name: dss#22:bla_bla.com
Type: REG_SZ
Data: 0xb477b...
From the command line, you can easily add the key as follows:
reg add HKEY_USERS\.DEFAULT\Software\SimonTatham\PuTTY\SshHostKeys /v dss#22:bla_bla.com /d 0xb477b...
Now Hudson, run as a service, go happily and smoothly to the repository where the code.
The 'started by anonymous' is telling you which Hudson user started the job. If you haven't created any Hudson users, then everything is started by 'anonymous'
It is not related to which OS user is executing the process.
You asked how to change the user that Hudson runs as: you need to edit the service (Control Panel->Administrative Tools->Services, double click the Hudson service and change the "Log On" to "This account").
Once the account is setup I make sure that the git server is in MINGW's (Git Bash's) ~hudson/.ssh/known_hosts, and that there's a ~hudson/.ssh/identity file in place. The only warning I have is that if you have cygwin installed on the box you need to make sure that %CYGWIN% is empty, otherwise you'll see key permission errors in the Hudson logs. My recommendation is that you simply set the CYGWIN environment variable to empty in Hudson.
I meet the same problem and after check git plugin, http://wiki.hudson-ci.org/display/HUDSON/Git+Plugin
It is stated to change the git path to /usr/bin/git in Global setting and config the git username
And it fixes my problem
Hope it works for you as well, by the way, I use ubuntu, but it should be the same