尝试从AWS群集连接到其中一个Windows服务器时，我遇到了以下错误。
引起：com.jcraft.jsch.JSchException：UnknownHostKey：x.y.com。 DSA密钥指纹是“ac：ew：.....
注意：我使用PuTTYgen生成了RSA密钥，但每次尝试连接时都会出现DSA指纹问题。我提到了多个SO链接但无法获得正确的解决方案。
最后，我根据其中一篇文章尝试了以下方法。第一次使用StrictHostKeyChecking作为no。完成后，将结果保存到AWS服务器上的已知主机文件，以便下次尝试连接到Windows服务器时，它知道它正在连接到正确的服务器。
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())
这有效，但我认为我失去了没有设置session.setConfig("StrictHostKeyChecking", "no")的全部原因，可能它正在运作。实现这一目标的正确方法是什么？
第二点，我不确定如何强制服务器只询问RSA密钥而不是DSA？
最后，StrictHostKeyChecking，accept-new是一个更安全和推荐的生产环境操作，而不是no？
这些是我看到的JSch日志。
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
我使用PuTTYgen生成了RSA密钥，但每次尝试连接时都会出现DSA指纹问题。
您似乎认为主机密钥与您用于身份验证的密钥对有关 - 它没有。那些完全不相关。主机密钥是服务器的密钥，它们是固定的，对于安装服务器时生成的服务器的所有用户都是相同的。
有关详细信息，请参阅我的文章Understanding SSH key pairs。
我相信，一旦你意识到这一点并回到有关UnknownHostKey的所有现有问题，他们现在对你更有意义：
最后，我根据其中一篇文章尝试了以下方法。第一次使用
StrictHostKeyChecking作为no。完成后，将结果保存到AWS服务器上的已知主机文件，以便下次尝试连接到Windows服务器时，它知道它正在连接到正确的服务器。这有效，但我认为我失去了没有设置
session.setConfig("StrictHostKeyChecking", "no")的全部原因，可能它正在运作。实现这一目标的正确方法是什么？
这不是一个完美的解决方案，但它是可以接受的。
要获得完美的解决方案，请在Windows SSH服务器上本地查找指纹，并配置您的AWS Java代码以提前预期。
最后，
StrictHostKeyChecking，accept-new是一个更安全和推荐的生产环境操作，而不是no？
no根本不安全。 accept-new和你上面的解决方案一样好。但无论如何，JSch不支持accept-new。
（实现它并不困难）