Why does the Jenkins SVN plugin give error E170001 when connecting to my VisualSVN server?
In the user's Subversion folder (%APPDATA%\Subversion
for Windows, ~/.subversion
for Linux/Mac OS x) add
http-auth-types=Basic
to the global section of the servers
file. Note that the case is different between Basic
and basic
.
For me, VisualSVN reports the following list of authentication options that it supports:
Negotiate
NTLM
Basic realm="VisualSVN Server"
When the Jenkins Subversion plugin uses http-auth-types
to order this list, it does a case-sensitive comparison. So Basic
is different from basic
and the server's Basic
option remains at the bottom of the list. Negotiate
gets used instead and apparently the SVN plugin cannot deal with that.
Check https://issues.jenkins-ci.org/browse/JENKINS-26158
Seems last comment contains workaround.
Though I try it with Jenkins 1.617 + Subversion plugin 2.5 + VisualSVN Server 3.2.2 and all works correctly.
I had the same problem, but it was difficult to discover the reason of this. Jenkins (v2.107) only said:
org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: Negotiate authentication failed: 'No valid credentials provided'
...
I've double check all credential and all was correct. Moreover standalone svn works great - for example:
svn info --username xxx --password xxx --no-auth-cache --non-interactive --trust-server-cert https://server.xxx.corp/svn/REPO
So how to find bug/problem?
Hint: Jenkins uses SVNKit.
So we can download SVNKit
(https://svnkit.com/) and use jsvn
tool from this distribution:
svnkit-1.9.3/bin/jsvn info --username xxx --password xxx --no-auth-cache --non-interactive --trust-server-cert https://server.xxx.corp/svn/REPO
Initially I obtain similar error:
svn: E170001: Negotiate authentication failed: 'No valid credentials provided'
But inside directory svnkit-1.9.3/conf
is logging.properties.disabled
file. When I removed .disabled
suffix then jsvn
put all logs to svnkit-1.9.3/bin/svnkit.0
.
This shows all problems. For me:
HTTP/1.1 407 Proxy Authentication Required (...)
Great, it wasn't problem with credential to SVN but credential to Company Proxy. In your case the problem can be different, but this method may help find the source of problem.
Additional info:
Jenkins provide settings to proxy server. But SVN uses completely different external configuration from:
C:\Users\<user>\AppData\Roaming\Subversion\servers
To configure proxy I must provide to above file:
http-proxy-host = super.proxy.company.com
http-proxy-port = 80
http-proxy-username = defaultusername or DOMAIN\defaultusername
http-proxy-password = defaultpassword
But this also doesn't work as well as I expect - some tools (maven, svn...) have problems with connecting to Internet via some Proxy servers. Alternative is to provide local proxy using CNTLM
tool (http://cntlm.sourceforge.net/). Cntlm is fully configured with company proxy URL, port and my domain account login and password (hashed not plain text). SVN uses directly only Cntlm local proxy (without need to provide any username nor passwords).
http-proxy-host = mylocal.host.url.at.domain.com
http-proxy-port = 8089
# with neither username nor password
Schema:
SVN <---(anonymous)--> CNTLM Proxy <---(login, password)---> Company Proxy <----> Internet
SVNKit <---(anonymous)----^
any other tools (Jenkins, maven, ...) can also use CNTLM
This works great for me.