Java 1.7 + JSCH: java.security.InvalidKeyException: Ключ слишком длинный для этого алгоритма

Я пытаюсь использовать JSCH, чтобы загрузить файл на удаленный SFTP. Каждый раз, когда я пытаюсь подключиться к акции внутри моего кода, я получаю исключение, которое выглядит примерно так:Java 1.7 + JSCH: java.security.InvalidKeyException: Ключ слишком длинный для этого алгоритма

com.jcraft.jsch.JSchException: Session.connect: java.security.InvalidKeyException: Key is too long for this algorithm 
    at com.jcraft.jsch.Session.connect(Session.java:558) ~[jsch-0.1.51.jar:na] 
    at com.jcraft.jsch.Session.connect(Session.java:183) ~[jsch-0.1.51.jar:na]

Я видел posts that describe this error при переходе на Java 8, но мы до сих пор на Java 7 , и я не знаю достаточно о поддержке криптографии Java, чтобы знать, если это имеет значение.

Некоторые люди предлагают установить JCE (Java Cryptography Extensions), чтобы решить эту проблему, поэтому я сделал снимок, но я все равно получаю такую же ошибку после копирования соответствующих файлов jar в каталог/libs/security и перезапуска приложения , Мы подтвердили, что JCE был установлен, выполнив this script и отметив, что исключение не было выбрано.

Я также попытался подключиться к удаленному ресурсу SFTP с терминала с помощью команды sftp в подробном режиме. Вот что я получил:

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 
debug1: Reading configuration data /etc/ssh_config 
debug1: /etc/ssh_config line 20: Applying options for * 
debug1: /etc/ssh_config line 102: Applying options for * 
debug2: ssh_connect: needpriv 0 
debug1: Connecting to XXXXXXXXXXXXX [XXXXXXXXXXXX] port XX. 
debug1: Connection established. 
debug3: Incorrect RSA1 identifier 
debug3: Could not load "/Users/XXXXX/.ssh/id_rsa" as a RSA1 public key 
debug1: identity file /Users/XXXXX/.ssh/id_rsa type 1 
debug1: identity file /Users/XXXXX/.ssh/id_rsa-cert type -1 
debug1: identity file /Users/XXXXX/.ssh/id_dsa type -1 
debug1: identity file /Users/XXXXX/.ssh/id_dsa-cert type -1 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_6.2 
debug1: Remote protocol version 2.0, remote software version 3.2.9 SSH Secure Shell 
debug1: no match: 3.2.9 SSH Secure Shell 
debug2: fd 3 setting O_NONBLOCK 
debug3: load_hostkeys: loading entries for host "XXXXXXXXXXXXX" from file "/Users/XXXXX/.ssh/known_hosts" 
debug3: load_hostkeys: loaded 0 keys 
debug1: SSH2_MSG_KEXINIT sent 
debug3: Received SSH2_MSG_IGNORE 
debug1: SSH2_MSG_KEXINIT received 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss 
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] 
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] 
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 
debug2: kex_parse_kexinit: none,[email protected],zlib 
debug2: kex_parse_kexinit: none,[email protected],zlib 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1 
debug2: kex_parse_kexinit: ssh-dss 
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour 
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour 
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96 
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96 
debug2: kex_parse_kexinit: none,zlib 
debug2: kex_parse_kexinit: none,zlib 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5 
debug1: kex: server->client aes128-cbc hmac-md5 none 
debug2: mac_setup: found hmac-md5 
debug1: kex: client->server aes128-cbc hmac-md5 none 
debug2: dh_gen_key: priv key bits set: 122/256 
debug2: bits set: 496/1024 
debug1: sending SSH2_MSG_KEXDH_INIT 
debug1: expecting SSH2_MSG_KEXDH_REPLY 
debug3: Received SSH2_MSG_IGNORE 
debug1: Server host key: DSA XXXXXXXXXXXXXXXXXXXXXXXX 
debug3: load_hostkeys: loading entries for host "XXXXXXXXXXXXX" from file "/Users/XXXXX/.ssh/known_hosts" 
debug3: load_hostkeys: loaded 0 keys 
debug3: load_hostkeys: loading entries for host "XXXXXXXXXXXX" from file "/Users/XXXXX/.ssh/known_hosts" 
debug3: load_hostkeys: loaded 0 keys 
    The authenticity of host 'XXXXXXXXXXXXX (XXXXXXXXXXXX)' can't be established. 
    DSA key fingerprint is XXXXXXXXXXXXXXXXXXXXXXXX. 
    Are you sure you want to continue connecting (yes/no)? yes 
    Warning: Permanently added 'XXXXXXXXXXXXX,XXXXXXXXXXXX' (DSA) to the list of known hosts. 
debug2: bits set: 516/1024 
debug1: ssh_dss_verify: signature correct 
debug2: kex_derive_keys 
debug2: set_newkeys: mode 1 
debug1: SSH2_MSG_NEWKEYS sent 
debug1: expecting SSH2_MSG_NEWKEYS 
debug3: Received SSH2_MSG_IGNORE 
debug2: set_newkeys: mode 0 
debug1: SSH2_MSG_NEWKEYS received 
debug1: Roaming not allowed by server 
debug1: SSH2_MSG_SERVICE_REQUEST sent 
debug3: Received SSH2_MSG_IGNORE 
debug2: service_accept: ssh-userauth 
debug1: SSH2_MSG_SERVICE_ACCEPT received 
debug2: key: /Users/XXXXX/.ssh/id_rsa (0x7f8e28500a10), 
debug2: key: /Users/XXXXX/.ssh/id_dsa (0x0), 
debug3: Received SSH2_MSG_IGNORE 
debug1: Authentications that can continue: publickey,password 
debug3: start over, passed a different list publickey,password 
debug3: preferred publickey,keyboard-interactive,password 
debug3: authmethod_lookup publickey 
debug3: remaining preferred: keyboard-interactive,password 
debug3: authmethod_is_enabled publickey 
debug1: Next authentication method: publickey 
debug1: Offering RSA public key: /Users/XXXXX/.ssh/id_rsa 
debug3: send_pubkey_test 
debug2: we sent a publickey packet, wait for reply 
debug3: Received SSH2_MSG_IGNORE 
debug1: Authentications that can continue: password 
debug3: start over, passed a different list password 
debug3: preferred publickey,keyboard-interactive,password 
debug3: authmethod_lookup password 
debug3: remaining preferred: ,keyboard-interactive,password 
debug3: authmethod_is_enabled password 
debug1: Next authentication method: password

Если я правильно читаю вывод (и не может быть) процесс квитирования остановился на использование aes128-cbc для обмена ключей и hmac-md5 для фактического шифрования сеанса. Согласно the JSCH documentation (минимальный, хотя это может быть), оба этих алгоритма поддерживаются.

Я могу подключиться к этой доле с помощью утилиты командной строки sftp и с FileZilla, поэтому проблема должна быть либо с АОХ, либо с моей конфигурацией Java, но я не понимаю, что именно.

версия Java:

java version "1.7.0_71" 
OpenJDK Runtime Environment 
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

JSch версия:

<dependency> 
    <groupId>com.jcraft</groupId> 
    <artifactId>jsch</artifactId> 
    <version>0.1.51</version> 
</dependency>

Заранее спасибо!

EDIT: Похоже, что a bug for this exact behaviour был подан против JDK, но был закрыт без разрешения. Существует также an email thread между разработчиками АОH и разработчиками JDK, которые обсуждают этот вопрос, но не имеют разрешения.

источник

2014-12-18 MusikPolice

Wow. Я пришла сюда, чтобы рекомендовать JCE, но похоже, что вы сделали домашнее задание (не то, что это должно было быть проблемой в любом случае, но все-таки). Вы можете попробовать с помощью Oracle Java (вместо OpenJDK) 7? Я не хочу быть расплывчатым, но мне не повезло с OpenJDK в прошлом. На данный момент я бы сказал, что Oracle Java стоит попробовать хотя бы. Возможно, вам придется установить JCE в него (я, по общему признанию, понимаю, что я могу помочь) –

Некоторые пояснения: (1) Вы не установили JCE, это уже в пакете Java. Вы установили «Неограниченную стратегию прочности», которая является * дополнением к * JCE. Это имеет значение только в том случае, если требуемое/согласованное симметричное шифрование составляет более 128 бит, что, по-видимому, не так. (2) Ваше sftp рукопожатие выбрало 'aes128-cbc' для * шифрования * и' hmac-md5' для * проверки целостности *; key-exchange - это Diffie-Hellman, аутентификация хоста - DSA, а аутентификация клиента - это пароль. ... –

... (3) Используемые группы DH и DSA выглядят как 1024 бит, что должно быть хорошо для Java 7. Но если отладочный вывод не является точным и надежным, это может помочь получить сеть отслеживать, в частности, попытку jsch с Wireshark или аналогично проверять и точно видеть, когда он терпит неудачу. Или, если вы можете протестировать Java 8, это расширит пределы для DH и DSA (хотя вы можете или не хотите 8 по другим причинам). –

Мы закончили замену АОH на SSHJ. Это зависит от криптографических библиотек BouncyCastle, а не от встроенных криптографических пакетов Java и может без проблем подключаться к нашему серверу.

источник

2015-01-16 20:31:21 MusikPolice

-1

Установка Java Cryptography Extension (JCE) Неограниченное Strength Юрисдикция политики Файлы click here to download

Заменить local_policy.jar и US_export_policy.jar с неограниченными файлов политики в следующем месте: Java \ jre7 \ Lib \ безопасность \

У меня была аналогичная проблема при шифровании данных с помощью ibm jre версии 1.5 и tomcat.

источник

2015-01-02 11:38:46

Пожалуйста, прочитайте исходное сообщение полностью. Мы попытались установить файлы политики юрисдикции без ограничений, и это не помогло – MusikPolice

На самом деле, bug for this behaviour, который был подан против JDK не было закрыт - решение закрыть его было вернулось, и это было фиксированных несколько дней спустя.Позднее он был поставлен обратно, поэтому обновление до Java SE 8u45 (или выше) решает проблему.

источник

2015-06-18 20:51:25

Вы можете заставить JSch использовать SHA256 вместо SHA1 с keysize > 1024 (который JSSE не позволяет больше), как это:

java.util.Properties configuration = new java.util.Properties(); 
configuration.put("kex", "diffie-hellman-group-exchange-sha256");   
configuration.put("StrictHostKeyChecking", "no"); 
session.setConfig(configuration);

источник

2016-07-28 09:33:59

Java 1.7 + JSCH: java.security.InvalidKeyException: Ключ слишком длинный для этого алгоритма

ответ

Смежные вопросы