Запрос относительно com.jcraft.jsch.JSchException: UnknownHostKey: x.y.com. Отпечаток ключа DSA - "ac: ew: ...."

Question

Я получаю ошибку ниже при попытке подключиться к одному из серверов Windows из кластера AWS.

Причина: com.jcraft.jsch.JSchException: UnknownHostKey: x.y.com. Отпечаток ключа DSA - "ac: ew: .....

Примечание: Я сгенерировал ключи RSA с помощью PuTTYgen, но каждый раз, когда он пытается подключиться, он вызывает проблему с отпечатком 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

Answer 1

Я сгенерировал ключи RSA с помощью PuTTYgen, но каждый раз, когда он пытается подключиться, возникает проблема с отпечатком DSA.

Кажется, вы считаете, что ключ хоста как-то связан с парой ключей, которую вы используете для аутентификации & ndash; Это не. Это совершенно не связано. Ключи хоста - это ключи сервера, они являются фиксированными и одинаковыми для всех пользователей сервера, генерируются при установке сервера.

Подробнее см. Мою статью Понимание пар ключей SSH .

Я полагаю, что как только вы поймете это и вернетесь ко всем существующим вопросам, связанным с UnknownHostKey, теперь они станут более понятными для вас:

• Как разрешить Java UnknownHostKey при использовании библиотеки SFTP JSch?
• com.jcraft.jsch.JSchException: UnknownHostKey

---

Наконец, я попробовал следующий подход, основанный на одном из постов. Получите сеанс в первый раз с StrictHostKeyChecking как no. После этого сохраните результат в файле известных хостов на сервере AWS, чтобы в следующий раз, когда он попытается подключиться к серверу Windows, он знал, что подключается к нужному серверу.

Это работает, но я думаю, что теряю всю причину не настроить session.setConfig("StrictHostKeyChecking", "no") и, возможно, оно работает. Как правильно достичь этого?

Это не идеальное решение, но оно приемлемо.

Для идеального решения найдите отпечаток локально на вашем сервере Windows SSH и настройте свой код Java AWS, чтобы он ожидался заранее.

---

Наконец, StrictHostKeyChecking, accept-new - более безопасная и рекомендуемая операция для производственных сред вместо no?

no не является безопасным. accept-new так же хорошо, как ваше решение. Но JSch все равно не поддерживает accept-new.

(это не сложно реализовать)