Query regarding com.jcraft.jsch.JSchException: UnknownHostKey: x.y.com. DSA key fingerprint is “ac:ew:…”

Question

I am getting below error while trying to connect to one of the windows server from AWS cluster.

Caused by: com.jcraft.jsch.JSchException: UnknownHostKey: x.y.com. DSA key fingerprint is "ac:ew:.....

Note: I generated the RSA keys using PuTTYgen, but every time it tries to connect it gives issue with DSA fingerprint. I referred multiple SO links but unable to get the right solution.

Finally I tried below approach based on one of the posts. Get the session first time with StrictHostKeyChecking as no. Once done, save the result to known hosts file on the AWS server so that next time it tries to connect to Windows server it knows it is connecting to the right server.

session.setConfig("StrictHostKeyChecking", "no")
session.setConfig("PreferredAuthentications", "publickey,password")
session.connect(5000)
LOG.info("session connected...." + session.isConnected())
val arrayHostKey = jsch.getHostKeyRepository().getHostKey
  for (i <- 0 to arrayHostKey.size - 1) {
      println(arrayHostKey(i).getHost)
      println(arrayHostKey(i).getKey)
      println(arrayHostKey(i).getType)
      if (arrayHostKey(i).getHost.equalsIgnoreCase(host))
         session.setConfig("server_host_type", arrayHostKey(i).getType)
LOG.info("sftp session connected without using proxy..." + session.isConnected())

This works, but I think I am losing the entire reason for not setting up session.setConfig("StrictHostKeyChecking", "no") and may be it is working. What is the right way to achieve this?

Second point that I am not sure is how to force the server to ask for RSA keys only instead of DSA?

Lastly, is StrictHostKeyChecking, accept-new a more secure and recommended operation for production environments instead of no?

These are the JSch logs I am seeing.

SSH_MSG_KEXINIT sent
SSH_MSG_KEXINIT received
kex: server: diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
kex: server: ssh-dss
kex: client: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
kex: server->client aes128-ctr hmac-md5 none
kex: client->server aes128-ctr hmac-md5 none
SSH_MSG_KEXDH_INIT sent
expecting SSH_MSG_KEXDH_REPLY
ssh_dss_verify: signature true
Disconnecting from x.y.com port 22

Answer 1

I generated the RSA keys using PuTTYgen, but every time it tries to connect it gives issue with DSA fingerprint.

It seems that you believe that the host key has something to do with key pair that you use for authentication – It does not. Those are completely unrelated. Host keys are keys of the server, they are fixed, the same for all users of the server, generated when the server is installed.

For details, see my article Understanding SSH key pairs.

I believe that once you realize this and go back to all the existing questions about UnknownHostKey, they will now make more sense to you:

• How to resolve Java UnknownHostKey, while using JSch SFTP library?
• com.jcraft.jsch.JSchException: UnknownHostKey

---

Finally I tried below approach based on one of the posts. Get the session first time with StrictHostKeyChecking as no. Once done, save the result to known hosts file on the AWS server so that next time it tries to connect to Windows server it knows it is connecting to the right server.

This works, but I think I am losing the entire reason for not setting up session.setConfig("StrictHostKeyChecking", "no") and may be it is working. What is the right way to achieve this?

It's not a perfect solution, but it's acceptable.

For a perfect solution, find out the fingerprint locally on your Windows SSH server and configure your AWS Java code to expect it upfront.

---

Lastly, is StrictHostKeyChecking, accept-new a more secure and recommended operation for production environments instead of no?

no is not secure at all. accept-new is as good as your above solution. But JSch does not support accept-new anyway.

(it's not difficult to implement it)