Using SVNKit with Apache sshd

SonarQube Server / Community Build
1

As suggested here and other places I’m trying to use Apache sshd in order to have a dialog with a recent sshd server, but it seems to ignore the parameter:

% gradlew sonar -Dsonar.token=sqp_… -Dsvnkit.ssh.client=apache
Analyzing only language associated files, make sure to run the analysis inside a git repository to make use of inclusions specified via "sonar.text.inclusions"
[stderr] Mar 10, 2025 4:22:38 PM org.tmatesoft.svn.core.internal.io.svn.ssh.SessionPoolFactory create
[stderr] WARNING: Using the obsolete trilead ssh client implementation, consider switching to apache by using -Dsvnkit.ssh.client=apache

(omissis)

	... 26 common frames omitted
Caused by: java.io.IOException: Key exchange was not finished, connection is closed.
	at com.trilead.ssh2.transport.KexManager.getOrWaitForConnectionInfo(KexManager.java:92)
	at com.trilead.ssh2.transport.TransportManager.getConnectionInfo(TransportManager.java:231)
	at com.trilead.ssh2.Connection.connect(Connection.java:769)
	... 31 common frames omitted
Caused by: java.io.IOException: Cannot negotiate, proposals do not match.
	at com.trilead.ssh2.transport.KexManager.handleMessage(KexManager.java:413)
	at com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:765)
	at com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:480)
	at java.base/java.lang.Thread.run(Thread.java:840)

I’m running Community Build v24.12.0.100206 on FreeBSD, but I guess this is still happening only in Gradle Scanner and serve rwasn’t even contacted yet, yes?

In build.gradle I’m using id 'org.sonarqube' version '6.0.1.5171'.

2

Hi,

Welcome to the community!

I believe so.

And I believe this is coming directly from SVN rather than from the scanner:

What SVN client do you have installed locally?

The docs may help here.

 
Ann

3

Hi! That sentence comes certainly from SVNKit Java implementation (“trilead” and “apache sshd” are Java libraries), it doesn’t come from the native svn client; in any case, I’m using this binary:

% svn --version
svn, version 1.14.5 (r1922182)

This is a more full stack trace (I removed a bit too much in my OP):

java.lang.IllegalStateException: Error when executing blame for file src/com/(…)
	at org.sonar.scm.svn.SvnBlameCommand.blame(SvnBlameCommand.java:93)
	at org.sonar.scm.svn.SvnBlameCommand.blame(SvnBlameCommand.java:60)
	at org.sonar.scanner.scm.ScmPublisher.publish(ScmPublisher.java:87)
Caused by: org.tmatesoft.svn.core.SVNException: svn: E210002: There was a problem while connecting to (…).andxor.it:22
	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:70)
	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
	at org.tmatesoft.svn.core.internal.io.svn.SVNSSHConnector.open(SVNSSHConnector.java:135)
Caused by: java.io.IOException: There was a problem while connecting to (…).andxor.it:22
	at com.trilead.ssh2.Connection.connect(Connection.java:817)
	at org.tmatesoft.svn.core.internal.io.svn.ssh.trilead.SshHost.openConnection(SshHost.java:237)
	at org.tmatesoft.svn.core.internal.io.svn.ssh.trilead.SshHost.openSession(SshHost.java:165)
Caused by: java.io.IOException: Key exchange was not finished, connection is closed.
	at com.trilead.ssh2.transport.KexManager.getOrWaitForConnectionInfo(KexManager.java:92)
	at com.trilead.ssh2.transport.TransportManager.getConnectionInfo(TransportManager.java:231)
	at com.trilead.ssh2.Connection.connect(Connection.java:769)
Caused by: java.io.IOException: Cannot negotiate, proposals do not match.
	at com.trilead.ssh2.transport.KexManager.handleMessage(KexManager.java:413)
	at com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:765)
	at com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:480)
	at java.base/java.lang.Thread.run(Thread.java:840)
5

Hi,

Thanks for the full stacktrace. It looks like this is not a new problem. There are workarounds in the tmatesoft support forum.

 
HTH,
Ann

6

Thank you! Unfortunately that work-around suggests to change sshd configuration on the server side to allow obsolete protocols, which I can’t at the moment.

I was trying to use the newer “Apache sshd” implementation as suggested by Colin here, but the -D parameter seems to be lost between Gradle command line and SVNKit invocation, as if it was executed in a separate JVM or removed explicitly from system properties in some intermediate step.

7

Hi,

Yeah… that’s not an analysis parameter, so it’s not going to be recognized, used or passed forward by any of the scanners.

Since you’re already using the latest client, I’m going to flag this for the team.

 
Ann

1 Like
9

Oh, okay, I see: it actually invokes a new JVM (running on sonar-scanner-engine-shaded) and pass-thru of system properties is only supported on the ones named sonar.*, so explicit support should be added in Sonar in order to pass the svnkit.ssh.client proprerty down.

11

Hi,

I guess this is a JVM System property on the SVNKit side. So the proper way to pass it to the forked JVM is by setting:

  • -Dsonar.scanner.javaOpts="-Dsvnkit.ssh.client=apache"
  • or using the equivalent env variable SONAR_SCANNER_JAVA_OPTS to -Dsvnkit.ssh.client=apache

This is assuming you are using a recent version of the Scanner for Gradle.

1 Like