Thanks Konstantin and All, I did try 3 things :
1) changed git path to full path under the git plugin in jenkins. didn't help. 2) I tried to ssh manually from the master (and from the slave which actually runs the jobs, in fact), it worked with no password asked, so I guess the ssh configuration is correct. 3) I also tried to clone manually (using the ssh URL) from the repository server, running as the user who runs jenkins - worked fine. I ran out of ideas.....:-( did I miss something here ? On Wed, Feb 13, 2013 at 3:28 PM, Konstantin Khomoutov < flatw...@users.sourceforge.net> wrote: > On Wed, 13 Feb 2013 01:36:52 -0800 (PST) > Gabby Romano <omerik...@gmail.com> wrote: > > > I hope it's the right place for this kind of issues, but since I > > didn't find a solution elsewhere, I thought to give it a try. > > I am trying to switch to an ssh URL instead of HTTP based one in the > > git plugin under Jenkins. whenever I am doing this and trying to run > > a git hook which does polling, I am getting this error: > > > > Fetching changes from the remote Git repositories > > Fetching upstream changes from ssh://git@<repo URL> > > ERROR: Problem fetching from origin / origin - could be unavailable. > > Continuing anywayhudson.plugins.git.GitException > > < > http://stacktrace.jenkins-ci.org/search?query=hudson.plugins.git.GitException > >: > > Command "/usr/bin/git fetch -t ssh://git@<repo URL> > > +refs/heads/*:refs/remotes/origin/*" returned status code 128: > > stdout: stderr: Host key verification failed. fatal: The remote end > > hung up unexpectedly > > > > at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:897) > > at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:858) > > at hudson.plugins.git.GitAPI.fetch(GitAPI.java:200) > > at hudson.plugins.git.GitAPI.fetch(GitAPI.java:1105) > > at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:813) > > at hudson.plugins.git.GitSCM.access$100(GitSCM.java:72) > > at hudson.plugins.git.GitSCM$1.invoke(GitSCM.java:744) > > at hudson.plugins.git.GitSCM$1.invoke(GitSCM.java:731) > > at hudson.FilePath$FileCallableWrapper.call > > (FilePath.java:2236) at hudson.remoting.UserRequest.perform > > (UserRequest.java:118) at hudson.remoting.UserRequest.perform > > (UserRequest.java:48) at hudson.remoting.Request$2.run > > (Request.java:326) at hudson.remoting.InterceptingExecutorService > > $1.call(InterceptingExecutorService.java:72) at > > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at > > java.util.concurrent.FutureTask.run(FutureTask.java:166) at > > java.util.concurrent.ThreadPoolExecutor.runWorker > > (ThreadPoolExecutor.java:1110) at > > java.util.concurrent.ThreadPoolExecutor$Worker.run > > (ThreadPoolExecutor.java:603) at java.lang.Thread.run > > (Thread.java:722) Polling for changes in Done. Took 0.25 sec Changes > > found > > > > > > I tried increasing the MaxStartups attribute in sshd_config but it > > didn't help.git version used is 22.214.171.124. > > > > any idea what could be the cause of this ? > > The "Host key verification failed." message from an SSH client usually > means that the SSH key on the server has changed. The security of > the SSH protocol rests in trusting the server's key -- that's why SSH > clients insist on verifying and accepting the server's key (showing you > its fingerprint) when you connect to a server for the first time. > Then the accepted key is typically cached, and next time you connect > to that same server (using the same hostname!) your SSH client checks > to see the fingerprint of the key presented by the server matches the > cached one for that server, and if the server's key suddenly changes, > the SSH client assumes a possibility of the MitM attack and refuses to > proceed. > > I'm not quite sure what you're doing in your particular case (I mean, > on which side the SSH client is failing, and the matter is further > complicated by the fact some Java program is involved in the process > (I recall Hudson is something like a CI server, right?)). > But I think I gave you some clue for further research. > > For OpenSSH, you usually use `ssh-keygen -R <hostname>` to remove the > cached entry for the server <hostname>. > For PuTTY, it's a matter of deleting an appropriate entry from > HKCU\Software\SimonTatham\PuTTY\SshHostKeys > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.