Configure preferred algorithm

Question

Following problem:

DEBUG 2009-11-23 15:58:17,282 TransportProtocolCommon [Transport protocol 1] - Verifying host *****,*****
DEBUG 2009-11-23 15:58:17,282 TransportProtocolCommon [Transport protocol 1] - Preferred algorithm null
DEBUG 2009-11-23 15:58:17,282 TransportProtocolCommon [Transport protocol 1] - Determine Algorithm
DEBUG 2009-11-23 15:58:17,282 TransportProtocolCommon [Transport protocol 1] - Client Algorithms: [ssh-dss, ssh-rsa]
DEBUG 2009-11-23 15:58:17,283 TransportProtocolCommon [Transport protocol 1] - Server Algorithms: [ssh-dss, ssh-rsa]
DEBUG 2009-11-23 15:58:17,283 TransportProtocolCommon [Transport protocol 1] - Returning ssh-dss
DEBUG 2009-11-23 15:58:17,283 TransportProtocolCommon [Transport protocol 1] - Selected algorithm ssh-dss
DEBUG 2009-11-23 15:58:17,290 SshDssPublicKey [Transport protocol 1] - Signature length=55
DEBUG 2009-11-23 15:58:17,290 SshDssPublicKey [Transport protocol 1] - Header is ssh-dss
DEBUG 2009-11-23 15:58:17,291 SshDssPublicKey [Transport protocol 1] - Verifying host key signature
DEBUG 2009-11-23 15:58:17,292 SshDssPublicKey [Transport protocol 1] - Signature length is 40
DEBUG 2009-11-23 15:58:17,302 SshDssPublicKey [Transport protocol 1] - Signature: 805B67111C242D25A
DEBUG 2009-11-23 15:58:17,302 SshDssPublicKey [Transport protocol 1] - Encoded: 302D021500805B6716F55C38F0F7F5620088892A11C242D25A
DEBUG 2009-11-23 15:58:17,360 AbstractKnownHostsKeyVerification [Transport protocol 1] - Verifying *****,***** host key
DEBUG 2009-11-23 15:58:17,360 AbstractKnownHostsKeyVerification [Transport protocol 1] - Fingerprint: 1024: ac a2 71 ef
DEBUG 2009-11-23 15:58:17,360 SSHFTPValidator [Transport protocol 1] - Denied *****,*****: Unknown host.
DEBUG 2009-11-23 15:58:17,361 SSHFTPValidator [Transport protocol 1] - Denied *****,*****: Unknown host.
DEBUG 2009-11-23 15:58:17,361 AbstractKnownHostsKeyVerification [Transport protocol 1] - getAllowedKey(names=*****,*****,algorithm=ssh-dss)
...
com.enterprisedt.net.j2ssh.transport.kex.KeyExchangeException: The host signature is invalid or the host key was not accepted!
at com.enterprisedt.net.j2ssh.transport.TransportProtocolClient.performKeyExchange(Unknown Source)
at com.enterprisedt.net.j2ssh.transport.TransportProtocolCommon.beginKeyExchange(Unknown Source)
at com.enterprisedt.net.j2ssh.transport.TransportProtocolCommon.A(Unknown Source)
at com.enterprisedt.net.j2ssh.transport.TransportProtocolCommon.startBinaryPacketProtocol(Unknown Source)
at com.enterprisedt.net.j2ssh.transport.TransportProtocolCommon.run(Unknown Source)
at java.lang.Thread.run(Thread.java:788)

In the known host is a corresponding key with ssh-rsa installed, but the process failed, since the client tried to load a key with ssh-dss algorithm.
Is it possible to configure in the version of pro 1.5.5 which algorithm is preferred or netter the client should try all algorithms supported both by itself and the server?

Answer 1

SSHFTPClient.disableAllAlgorithms(SSHFTPAlgorithm.KEY_PAIR);
SSHFTPClient.setAlgorithmEnabled(SSHFTPAlgorithm.KEY_RSA, true);

this will enable RSA keys only.

Answer 2

We have server which use dss and other rsa. Would the setting disable dss? Will it still work with dss?
What is the different to the latest version of edtFTPj which work without having to explicitly set this property?

Answer 3

SSHFTPClient.disableAllAlgorithms(SSHFTPAlgorithm.KEY_PAIR);
SSHFTPClient.setAlgorithmEnabled(SSHFTPAlgorithm.KEY_RSA, true);
SSHFTPClient.setAlgorithmEnabled(SSHFTPAlgorithm.KEY_DSA, true);

Try the above - it should change the order so that RSA is preferred, but DSA is still supported. I haven't tried this but I think it should be ok.

Answer 4

We have also server keys in SSH-DSS algorithm. I am afraid, that the changes will effect that the dss algorithm will less preferred and thus faces the problem again.
The other thing is we also have keys in SSH-RSA algorithm, which works. I am not sure what makes this work, maybe the server did not return the DSA algorithm on some points, so that the DSA key is not selected. But strange is, that this works with the version 3.1.0 without having to explicitly set the preferred algorithm. What is the difference which may have changed between version 1.5.5 and 3.1.0 regarding ssh keys selection?

Answer 5

Please, if it works fine for 3.1.0 just upgrade to the latest version.

Answer 6

I wouldnt mind to upgrade to the latest version too if it is so easy to do. Since release of 3.0.3 (http://www.enterprisedt.com/forums/view ... ight=#9041), the backward compatibility has not been provided anymore, and I have to change my code to use this version, which mean, i have to release a new build, to provide a patch, etc and this just for a legacy version, which my customers use, whereas I could tell them: "Oh please, it works with our latest version, please do an upgrade". For many circumstances, they can not so easily do an upgrade of a whole system (ftp is only one of our functionality) on a production system.

If you could provide me a release, which provides the latest functionality and guarantee the backward compatibility, I would use it for sure.

Answer 7

I understand that upgrading to the latest version is not always possible. However it is not very practical for us to maintain branches on much earlier releases. I'm sorry about that.

Anyway, I've thought about it some more and the simplest solution would be just to add the correct keys to the known_hosts file.

Answer 8

I do also understand, that on some circumstance, upgrading can be such a pain. We are still looking a workaround for this. If we use the latest version, it will force us to deliver a patch for our system.

About adding the correct key, that was my first solution, but the customer replied that openssh works great with the supplied rsa key, so that our system should also be in the position to do this. And besides they dont have any dss key from the partner they are connecting.

Answer 9

Perhaps the best thing to do is to email us the log file from both 3.1.x and 1.5.x so we can see why it works for one & not the other. I think it just must be the order of the algorithms. Have you tried using:

SSHFTPClient.disableAllAlgorithms(SSHFTPAlgorithm.KEY_PAIR);
SSHFTPClient.setAlgorithmEnabled(SSHFTPAlgorithm.KEY_RSA, true);
SSHFTPClient.setAlgorithmEnabled(SSHFTPAlgorithm.KEY_DSA, true);

How it works is that the client sends the algorithms in a preferred order e.g. "ssh-rsa,ssh-dsa", and the server selects the first one the client supports as well as itself. But of course the client also needs the correct key for the chosen algorithm in the known_hosts file.

If machine A has an RSA key in known_hosts and B has a DSA key in known_hosts, and both servers support both key types, then "ssh-rsa,ssh-dsa" will work for A but not B, and "ssh-dsa,ssh-rsa" will work for B and not A.