Проблема с ключом SFTP? java.security.InvalidAlgorithmParameterException
Я пытаюсь использовать тестовое соединение клиента SFTP для подключения к MF, но получаю сообщение об ошибке:
Проверка псевдонима пользователя SFTP GLDFundingEngine_User не удалась. Подробности: Session.connect: java.security.InvalidAlgorithmParameterException: Основной размер должен быть кратен 64 и может находиться в диапазоне от 512 до 2048 (включительно)
Это встроенный клиент, поэтому у меня нет особого контроля над ним . Я протестировал оба ключа, и они должны быть хорошими:
ssh-keygen -lf intserv.rsa.pub
2048
ssh-keygen -lf GLDFundingEngine_XXXXXXXXXXXXXXXXXXXX_22_rsa.pub
1024
Есть ли еще что-то, на что указывает эта ошибка? Поиск обмена стеком просто указывает на разные библиотеки SSH, которые у меня нет возможности изменить.
Спасибо
Проблема точно не в вашем ключе; это , скорее всего, параметры сервера Диффи-Хеллмана - или, возможно, их ключ DSA, но не так много людей используют ключи DSA для SSH, особенно с тех пор, как OpenSSH недавно отказался от них. Возможно, стоит провести трассировку сети, чтобы точно увидеть, когда возникает ошибка: при начальном согласовании, например, group14; или DHGEXgroup и его параметры; или ответ DH (GEX), содержащий подпись DSA и эту подпись.
Если вы используете Sun / Oracle Java до версии 8, он не может обрабатывать размеры DH (или DSA) выше 1024, но размер DH 1024 теперь является считается уязвимым, поэтому многие серверы используют 2048. См. https://weakdh.org и http://www.keylength.org и / или множество вопросов, касающихся в основном безопасности.SX и crypto.SX о Logjam. В этом случае у вас есть два варианта: обновить до Java 8, где работает DH (и DSA) 2048; или если сервер поддерживает ECDH и библиотеку SSH, которую вы используете и не можете изменить, также поддерживает, но вы используете Java 6 (или ниже?), которая не поддерживает, добавьте поставщика из http: // www. bouncycastle.org , который действительно поддерживает ECDH, который обычно предпочтительнее классического DH и, таким образом, позволяет избежать проблемы.
Если вы используете IBM Java, как я дико предполагаю, исходя из возможности MF -> мэйнфрейм -> мэйнфрейм IBM -> магазин IBM, этот ответ не применяется напрямую. IBM Java использует криптопровайдеры IBM, которые отличаются от криптопровайдеров Sun / Oracle в Sun / Oracle Java. Однако, если вы проверите их документацию на предмет размеров параметров DH и, возможно, размеров параметров DSA, может быть что-то похожее.
Если это не DH, то обязательно посмотрите на трассировку сети, и если вы не можете понять это добавьте соответствующие части к вашему вопросу.
Перекрестное соединение
https://stackoverflow.com/questions/6851461/java-why-does-ssl-handshake-give-could-not-generate-dh-keypair -exception
https://stackoverflow.com/questions/10687200/java-7-and-could-not-generate-dh-keypair
https://stackoverflow.com/questions/21442547/java-ssl -dh-keypair-generation-prime-size-error
https://stackoverflow.com/questions/33088458/how-to-workaround-java-6-ssl-error