enterprisedt.com Forum Index CompleteFTP
RegisterSearchFAQMemberlistUsergroupsLog in
Reply to topic Page 1 of 1
Configure preferred algorithm
Author Message
Reply with quote
Post Configure preferred algorithm 
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?

View user's profile Send private message
Reply with quote
Post Re: Configure preferred algorithm 
SSHFTPClient.disableAllAlgorithms(SSHFTPAlgorithm.KEY_PAIR);
SSHFTPClient.setAlgorithmEnabled(SSHFTPAlgorithm.KEY_RSA, true);

this will enable RSA keys only.

View user's profile Send private message Visit poster's website
Reply with quote
Post  
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?

View user's profile Send private message
Reply with quote
Post  
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.

View user's profile Send private message Visit poster's website
Reply with quote
Post  
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?

View user's profile Send private message
Reply with quote
Post  
Please, if it works fine for 3.1.0 just upgrade to the latest version.

View user's profile Send private message Visit poster's website
Reply with quote
Post  
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/viewtopic.php?p=9041&highlight=#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.

View user's profile Send private message
Reply with quote
Post  
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.

View user's profile Send private message Visit poster's website
Reply with quote
Post  
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.

View user's profile Send private message
Reply with quote
Post  
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.

View user's profile Send private message Visit poster's website
Display posts from previous:
Reply to topic Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum