SVNKit + Eclipse - Failed after Server Fingerprint changed

SVNKit
#1

I am trying to connect to a repo in Eclipse after the Fingerprint changed on the server, but it fails.

Where are the Fingerprints stored and can I update the manullay? Can I force SVNKit to accept the new FingerPrint somehow? I am using Windows 10.

org.apache.subversion.javahl.ClientException: svn: E210002: There was a problem while connecting to ******:22
Error getting status for resource ******** org.apache.subversion.javahl.ClientException: svn: E210002: There was a problem while connecting to *********:22
org.apache.subversion.javahl.ClientException: svn: E210002: There was a problem while connecting to *****:22
org.apache.subversion.javahl.ClientException: svn: E210002: There was a problem while connecting to ******:22

#2

Hello,
SVNKit uses ‘trilead’ library which is Java implementation of SSH and neither SVNKit nor trilead have a system property or any other option to ignore such errors. But you can fix the problem manually.

On UNIX system the fingerprints are stored in ~/.ssh/known_hosts file. I have little experience with Windows 10 but this answer says it’s in %USERPROFILE%\ssh or %USERPROFILE%\.ssh directory. If you want to edit the file manually, it’s enough to remove the line with the corresponding host. But’s better to use ssh-keygen -R <host> command (again, I’m not sure whether there’s a corresponding command for Windows due to little experience).

On UNIX system after deleting an outdated fingerprint it’s enough to run "ssh " to store the new figerprints (you will be asked about that). I’m sure there’s a similar command for Windows.

I hope this information helps.

#3

Unfortunately clearing that file did not work. It did effect the behaviour of JavaHL which asked about the new key.

#4

I think there might be something else going on. I tried adding the repository under a different alias and got this error message.

Key exchange was not finished, connection is closed.
Cannot negotiate, proposals do not match.
#5

In this case it looks like this problem.

SVNKit doesn’t support some options of sshd, as result they can’t negotiate on common algorithms. A work-around would be to reconfigure the SSH server to include algorithms supported by SVNKit.