SFTP Connection Failed for Public Key file

Question

Hi,

I am unable to connect Using SFTP from AIX server to AIX server getting the following exception.

====== UseSFTPWithServerValidationPublicKeyFile remote-host username password publickeyfile sourcefilepath destfilepath key(DSA or RSA)=======
INFO [com.edt.siai.services.sftp.test.UseSFTPWithServerValidationKeyFile] 9 Dec 2008 14:33:32.389 : Deleted local copy : false
INFO [com.edt.siai.services.sftp.test.UseSFTPWithServerValidationKeyFile] 9 Dec 2008 14:33:32.392 : Creating SFTP client
INFO [puretls] 9 Dec 2008 14:33:32.802 : PureTLS debug level=0
INFO [LicensePropertiesBase] 9 Dec 2008 14:33:32.927 : Licence expiry date: 31 Dec 9999
INFO [LicensePropertiesBase] 9 Dec 2008 14:33:32.927 : Production licence
INFO [com.edt.siai.services.sftp.test.UseSFTPWithServerValidationKeyFile] 9 Dec 2008 14:33:32.961 : Setting user-name and password
INFO [com.edt.siai.services.sftp.test.UseSFTPWithServerValidationKeyFile] 9 Dec 2008 14:33:32.970 : Loading server public-key from /home/edt/.ssh/id_rsa.pub
INFO [com.edt.siai.services.sftp.test.UseSFTPWithServerValidationKeyFile] 9 Dec 2008 14:33:32.995 : Connecting to server 123.cs.edt.com
INFO [SCPClient] 9 Dec 2008 14:33:32.995 : SCPClient settings validated.
INFO [TransportProtocolCommon] 9 Dec 2008 14:33:33.082 : Timeout=60000
INFO [TransportProtocolCommon] 9 Dec 2008 14:33:33.085 : Wait for state update timeout=60000
INFO [cryptix] 9 Dec 2008 14:33:33.112 : GLOBAL_TRACE=false
INFO [cryptix] 9 Dec 2008 14:33:33.112 : GLOBAL_DEBUG=false
INFO [cryptix] 9 Dec 2008 14:33:33.112 : GLOBAL_DEBUG_SLOW=false
INFO [TransportProtocolCommon] 9 Dec 2008 14:33:33.116 : Wait for state update timeout=60000
INFO [DhGroup1Sha1] 9 Dec 2008 14:33:33.118 : Starting client side key exchange.
WARN [SSHFTPValidator] 9 Dec 2008 14:33:33.214 : Host-key mismatch: allowed host-key, '2048: 3c 8c fc 93 61 74 da 6e c7 f1 93 ac 4 21 63 6c', does not match actual host-key, '1024: 23 b6 9 99 3b 48 71 f5 f a3 ee 4b 81 d5 b8 b9'.
ERROR [TransportProtocolOutputStream] 9 Dec 2008 14:33:33.216 : sendMessage() failed: Socket closed (state=5)
ERROR [TransportProtocolOutputStream] 9 Dec 2008 14:33:33.217 : sendMessage() failed: Socket closed (state=5)
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:810)
====== Successfully executed UseSFTPWithServerValidationPublicKeyFile =======

Answer 1

The DSA public key being sent back is the one the server is using. When you validate using that it works. Therefore the server is not picking up the DSA public key that you are supplying to it.

Typically, sshd_config has something like this:

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

For DSA, the server's private key goes in /etc/ssh/ssh_host_dsa_key and the public key in /etc/ssh/ssh_host_dsa_key.pub

So you need to ensure that you are placing the server's public & private DSA keys in the equivalent files listed above. Only one public or private key should be in each file.

Answer 2

Thanks for the reply. So I have to supply the /etc/ssh/ssh_host_dsa_key.pub file instead of /.ssh/id_dsa.pub of server to the program right.

The command line arguments for the above program is

remote-host username password publickeyfile sourcefile destfile key(DSA or RSA)

123.edt.com dummy 123 /.ssh/id_dsa.pub /home/test.txt home/temp/1_test.txt DSA (This is the one I have used)

123.edt.com dummy 123 /etc/ssh/ssh_host_dsa_key.pub /home/test.txt home/temp/1_test.txt DSA (Suggested by u).

let me know my understanding is correct or not.

Answer 3

It depends on the HostKey setting in sshd_config on the server - it might be slightly different for your server.

But you must supply the server's DSA public key to the client (the server has two - a DSA key and an RSA key, location specified in sshd_config).

NOTE - unless you are running the client on the server machine you may not even have access to the server's public keys, i.e. /etc/ssh/ssh_host_dsa_key.pub is of course on the server machine.

/.ssh/id_dsa.pub is almost certainly NOT the server's public DSA key.

You'll know when you find the right one because it should be identical to the one you downloaded via SSHFTPClient.getHostPublicKey(host).

Answer 4

You are correct. I have verified the keys in /etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_dsa_key those are matching with the keys I have downloaded using SSHFTPClient.getHostPublicKey.

But in my servers sshd_config file /etc/ssh/ssh_host_rsa_key is commented.

#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

That means which one my server is using. One more thing SSHFTPValidator.addKnownHost(java.lang.String hostName, java.lang.String publicKeyFile) will take server file path for public key file or local file path(written to the local directory using SSHFTPClient.getHostPublicKey).

Answer 5

The commented out HostKey settings are probably the defaults - you uncomment them to change to a path other than the default.

Normally you can't supply the server path to a client as they are on a different machine and won't have access to it.

The problem here is one of key distribution. The client needs the server key to validate the server is who it says it is. But the client needs to get hold of the key first.

You can either use SSHFTPClient.getHostPublicKey() or distribute the key to the client by some other means. For example, command line SSH clients connect to the server and prompt to ask if the public key should be saved.