Algorithm negotiation fail on pull from remote

[agboom]

Hi, I'm trying to clone a password store repository using ssh public key authentication (from a hardened ssh server, meaning cryptos that are considered unsafe are not supported). However, upon pulling from the server, the app shows a dialog with a TransportException and the message "Algorithm negotiation fail":

I've tried both the latest version from the F-Droid store (1.3.2) and latest commit (b9e3967) built with Android Studio. Both yield the same error message. I've also upgraded JGit to 5.5.1, hoping that would solve it, but sadly it doesn't.

The stack trace below seems to suggest that the key exchange between client and server didn't succeed (that's what I conclude from receive_kexinit anyway). Could it be that Jsch does not support modern key exchange algorithms such as diffie-hellman-group14-sha256?

11-11 20:55:52.551  8306  9194 W System.err: org.eclipse.jgit.api.errors.TransportException: ssh://****: Algorithm negotiation fail
11-11 20:55:52.551  8306  9194 W System.err: 	at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:255)
11-11 20:55:52.551  8306  9194 W System.err: 	at org.eclipse.jgit.api.PullCommand.call(PullCommand.java:296)
11-11 20:55:52.551  8306  9194 W System.err: 	at com.zeapo.pwdstore.git.GitAsyncTask.doInBackground(GitAsyncTask.java:68)
11-11 20:55:52.551  8306  9194 W System.err: 	at com.zeapo.pwdstore.git.GitAsyncTask.doInBackground(GitAsyncTask.java:23)
11-11 20:55:52.551  8306  9194 W System.err: 	at android.os.AsyncTask$2.call(AsyncTask.java:333)
11-11 20:55:52.551  8306  9194 W System.err: 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
11-11 20:55:52.551  8306  9194 W System.err: 	at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)
11-11 20:55:52.551  8306  9194 W System.err: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
11-11 20:55:52.551  8306  9194 W System.err: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
11-11 20:55:52.551  8306  9194 W System.err: 	at java.lang.Thread.run(Thread.java:764)
11-11 20:55:52.552  8306  9194 W System.err: Caused by: org.eclipse.jgit.errors.TransportException: ssh://****: Algorithm negotiation fail
11-11 20:55:52.552  8306  9194 W System.err: 	at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:191)
11-11 20:55:52.552  8306  9194 W System.err: 	at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:140)
11-11 20:55:52.552  8306  9194 W System.err: 	at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:280)
11-11 20:55:52.552  8306  9194 W System.err: 	at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:170)
11-11 20:55:52.552  8306  9194 W System.err: 	at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:138)
11-11 20:55:52.552  8306  9194 W System.err: 	at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:124)
11-11 20:55:52.552  8306  9194 W System.err: 	at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1292)
11-11 20:55:52.552  8306  9194 W System.err: 	at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:244)
11-11 20:55:52.552  8306  9194 W System.err: 	... 9 more
11-11 20:55:52.552  8306  9194 W System.err: Caused by: com.jcraft.jsch.JSchException: Algorithm negotiation fail
11-11 20:55:52.552  8306  9194 W System.err: 	at com.jcraft.jsch.Session.receive_kexinit(Session.java:590)
11-11 20:55:52.552  8306  9194 W System.err: 	at com.jcraft.jsch.Session.connect(Session.java:320)
11-11 20:55:52.552  8306  9194 W System.err: 	at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:145)
11-11 20:55:52.552  8306  9194 W System.err: 	... 16 more

[msfjarvis]

The stack trace below seems to suggest that the key exchange between client and server didn't succeed (that's what I conclude from receive_kexinit anyway). Could it be that Jsch does not support modern key exchange algorithms such as diffie-hellman-group14-sha256?

It's the most probable cause.

[agboom]

According to this comparison matrix for SSH implementations Jsch does indeed lack the modern key exchange algorithms.
From a quick glance I see that SSHJ is more up-to-date in this respect, supporting up to diffie-hellman-group18-sha512. Other features, such as ciphers are also on par or better.

Would it be sensible to migrate to SSHJ?

[msfjarvis]

Yes I feel that'll probably be for the best. Will take a stab at it soon.

[msfjarvis]

SSHJ's support for generating SSH keys seems to be missing which is a blocker for us because Jsch does support it. Are you aware of any alternatives to assist us in that? I'd really prefer using a proven and tested implementation rather than try to roll my own for the app.

[agboom]

That's too bad, I overlooked that. Full disclosure: I don't have experience with Jsch or SSHJ, I only found them through some research online.

That said, do you have access to the Bouncycastle API? In that case would this example help? Or maybe this example also using Bouncycastle?

As a plan B, would it be acceptable to use OpenKeychain for SSH key management instead (as implemented in #486)?

[Floderik]

I ran into the same problem today. I got it working again by disabling the ED25519 SSH host key and going back to an RSA-based key. Not much of a security issue, but it would be nice to have more recent algorithms.

[msfjarvis]

That's a Jsch limitation that I can unfortunately do nothing about. If the ability to generate SSH keys will not be missed, I'll restart my efforts to migrate to SSHJ.

[msfjarvis]

After discussing with @Skrilltrax we both agree that it's in the project's best interests for us to avoid making any large changes to master and instead focus on making right choices from the get go on the v2 branch instead, so I'll not be attempting to migrate v1 to SSHJ. I'm currently looking into how best we can make use of SSHJ to create a feature-compatible replacement of Jsch out of it. I'm also investigating how to get around the need to disable StrictHostKeyChecking which enables MITM attack vectors as pointed out in #494.

[msfjarvis]

Closing this in favour of keeping discussion consolidated to #448