Java 1.7+；JSCH:java.security.InvalidKeyException:此算法的密钥太长_Java_Java 7_Sftp_Jsch_Jce

Java 1.7+；JSCH:java.security.InvalidKeyException:此算法的密钥太长

java

Java 1.7+；JSCH:java.security.InvalidKeyException:此算法的密钥太长,java,java-7,sftp,jsch,jce,Java,Java 7,Sftp,Jsch,Jce,我正在尝试使用将文件上载到远程共享。每次尝试从代码中连接到共享时，都会出现如下异常： 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

我正在尝试使用将文件上载到远程共享。每次尝试从代码中连接到共享时，都会出现如下异常：

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]

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

我在升级到Java8时看到过，但我们仍然使用Java7，我对Java的加密支持了解不够，不知道这是否重要

有人建议安装JCE（Java Cryptography Extensions）来解决这个问题，所以我尝试了一下，但在将适当的jar文件复制到/libs/security目录并重新启动应用程序后，仍然会遇到同样的错误。我们确认JCE是通过执行并注意到没有抛出异常来安装的

我还尝试在详细模式下使用

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: ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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

进行实际会话加密。根据（尽管可能最小），这两种算法都受支持

我可以通过

sftp

命令行实用程序和FileZilla连接到这个共享，因此问题要么出在JSCH上，要么出在我的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>


com.jcraft
对JDK提起诉讼，但没有解决方案。JSCH的维护人员和JDK开发人员之间也讨论了这个问题，但没有解决方案。
安装Java加密扩展（JCE）无限强度权限策略文件
在以下位置用不受限制的策略文件替换local_policy.jar和US_export_policy.jar：
Java\jre7\lib\security\
在使用ibm jre 1.5版和tomcat对数据进行加密时，我遇到了类似的问题。
我们最终将JSCH换成了。它依赖于加密库，而不是Java的内置加密包，并且能够毫无问题地连接到我们的服务器。
事实上，针对JDK提交的文件没有关闭-关闭它的决定被恢复，几天后得到了修复。它后来被后端口，因此升级到（或更高版本）也解决了这个问题。
您可以强制JSCH使用SHA256而不是SHA1，并使用keysize>1024
（JSSE不再允许这样做）：
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]

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

哇！我突然来到这里推荐JCE，但看起来你已经完成了你的家庭作业（无论如何，这不是问题所在，但都是一样的）。你有没有可能用OracleJava（而不是OpenJDK）7来试试？我不想含糊其辞，但我过去在OpenJDK方面运气不好。在这一点上，我想说Oracle Java至少值得一试。您可能需要在其中安装JCE（我承认我在这里抓住了救命稻草，只是希望我能提供帮助）一些澄清：（1）您没有安装JCE，这已经在Java包中了。您安装了“无限强度策略”，它是JCE的一个插件。只有当所需/协商的对称加密超过128位时，这才有区别，而您的情况似乎不是这样。（2） 您的sftp握手选择aes128 cbc
进行加密，选择hmac-md5
进行完整性检查；密钥交换是Diffie Hellman，主机身份验证是DSA，客户端身份验证似乎是密码。。。。。。（3） 使用的DH和DSA组似乎是1024位，这对于Java7应该是可以的。但是，如果调试输出不准确、不可靠，那么获取网络跟踪（尤其是使用Wireshark或类似工具进行jsch尝试的网络跟踪）可能会有所帮助，以确保并准确地看到它失败的时间。或者，如果您可以使用Java 8进行测试，这将扩展DH和DSA的限制（尽管出于其他原因，您可能需要8，也可能不需要8）。感谢@dave_thompson_085的澄清。你能告诉我哪一步抱怨钥匙太长吗？我链接的另一篇文章似乎表明目标服务器使用的DSA密钥长度大于1024位。这个密钥长度是Java不支持的，还是我可以做一些配置来允许它？进一步检查，我有一部分是错的。Java7将DH和DSA的生成限制为1024，但这与您的情况不同，ssh握手不会生成DSA（只使用它）。您确定没有运行j8或（不知何故）j8提供程序吗？AFAICT此异常消息在j7中根本不存在。我忘记的是，SSH仍然使用DSA>1024的SHA1，而不是更匹配的SHA224和SHA256，而且Java8似乎决定阻止这种组合。您现在指向的bug报告和电子邮件明确了这一点，我同意甲骨文似乎拒绝改变。。。请完整阅读原文。我们尝试安装无限强度管辖权策略文件，但没有帮助“JSSE不再允许”指的是什么？你能提供参考资料吗？