Java 1.7 + JSCH：java.security.InvalidKeyException：此算法的键太长 [英] Java 1.7 + JSCH: java.security.InvalidKeyException: Key is too long for this algorithm

问题描述

我正在尝试使用 JSCH 将文件上传到远程 SFTP 分享。每次我尝试从我的代码中连接到共享时，我都会得到一个如下所示的异常：

  com。 jcraft.jsch.JSchException：Session.connect：java.security.InvalidKeyException：com.jcraft.jsch.Session.connect（Session.java:558）〜[jsch-0.1。此算法的密钥太长了
。 51.jar：na] 
 com.jcraft.jsch.Session.connect（Session.java:183）〜[jsch-0.1.51.jar：na] 
  

我见过描述此错误的帖子，但我们仍然使用Java 7，而且我对Java的加密支持知之甚少，不知道这是否重要。 / p>

有人建议安装JCE（Java Cryptography Extensions）来解决这个问题，所以我试了一下，但是在将相应的jar文件复制到/ libs / security目录并重新启动申请。我们确认通过执行此脚本安装JCE并注意到该异常没有抛出。

我还尝试使用详细信息中的 sftp 命令从终端连接到远程SFTP共享模式。这是我得到的：

  OpenSSH_6.2p2，OSSLShim 0.9.8r 2011年12月8日
 debug1：读取配置数据/ etc / ssh_config 
 debug1：/ etc / ssh_config第20行：应用* 
的选项debug1：/ etc / ssh_config第102行：应用* 
的选项debug2：ssh_connect：needpriv 0 
 debug1：连接到XXXXXXXXXXXXX [XXXXXXXXXXXX]端口XX。 
 debug1：已建立连接。 
 debug3：不正确的RSA1标识符
 debug3：无法加载/Users/XXXXX/.ssh/id_rsa作为RSA1公钥
 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：为协议2.0启用兼容模式
 debug1：本地版本字符串SSH-2.0-OpenSSH_6.2 
 debug1 ：远程协议版本2.0，远程软件版本3.2.9 SSH安全Shell 
 debug1：不匹配：3.2.9 SSH安全Shell 
 debug2：fd 3设置O_NONBLOCK 
 debug3：load_hostkeys：加载条目主机XXXXXXXXXXXXX来自文件/Users/XXXXX/.ssh/known_hosts
 debug3：load_hostkeys：loaded 0 keys 
 debug1：SSH2_MSG_KEXINIT发送
 debug3：收到SSH2_MSG_IGNORE 
 debug1 ：SSH2_MSG_KEXINIT收到
 debug2：kex_parse_kexinit：diffie-hellman-group-exchange-sha256，diffie-hellman-gro up-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，河豚-CBC，CAST128-CBC，AES192-CBC，AES256-CBC，ARCFOUR， [e-mail] 
 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。玉米，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，HMA C-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：发送SSH2_MSG_K EXDH_INIT 
 debug1：期待SSH2_MSG_KEXDH_REPLY 
 debug3：收到SSH2_MSG_IGNORE 
 debug1：服务器主机密钥：DSA XXXXXXXXXXXXXXXXXXXXXXXX 
 debug3：load_hostkeys：从文件/ Users /加载主机XXXXXXXXXXXXX的条目XXXXX / .ssh / known_hosts
 debug3：load_hostkeys：loaded 0 keys 
 debug3：load_hostkeys：从文件/Users/XXXXX/.ssh/known_hosts加载主机XXXXXXXXXXXX的条目
 debug3：load_hostkeys：loaded 0 keys 
无法建立主机'XXXXXXXXXXXXX（XXXXXXXXXXXX）'的真实性。 
 DSA密钥指纹是XXXXXXXXXXXXXXXXXXXXXXXX。 
您确定要继续连接（是/否）？是
警告：永久性地将XXXXXXXXXXXXX，XXXXXXXXXXXX（DSA）添加到已知主机列表中。 
 debug2：位设置：516/1024 
 debug1：ssh_dss_verify：签名正确
 debug2：kex_derive_keys 
 debug2：set_newkeys：mode 1 
 debug1：SSH2_MSG_NEWKEYS发送
 debug1：期待SSH2_MSG_NEWKEYS 
 debug3：收到SSH2_MSG_IGNORE 
 debug2：set_newkeys：mode 0 
 debug1：SSH2_MSG_NEWKEYS收到
 debug1：服务器不允许漫游
 debug1：发送SSH2_MSG_SERVICE_REQUEST 
 debug3：收到SSH2_MSG_IGNORE 
 debug2：service_accept：ssh-userauth 
 debug1：SSH2_MSG_SERVICE_ACCEPT收到
 debug2：key：/Users/XXXXX/.ssh/id_rsa(0x7f8e28500a10),bb $ b debug2：key：/Users/XXXXX/.ssh/id_dsa(0x0), 
 debug3：收到SSH2_MSG_IGNORE 
 debug1：可以继续的身份验证：publickey，password 
 debug3：重新开始，传递了一个不同的列表publickey，密码
 debug3：首选的公钥，键盘交互式，密码
 debug3：authmethod_lookup publickey 
 debug3：剩余首选：键盘交互式，密码
 debug 3：authmethod_is_enabled publickey 
 debug1：下一个身份验证方法：publickey 
 debug1：提供RSA公钥：/Users/XXXXX/.ssh/id_rsa 
 debug3：send_pubkey_test 
 debug2：我们发送了一个publickey数据包，等待回复
 debug3：收到SSH2_MSG_IGNORE 
 debug1：可以继续的身份验证：密码
 debug3：重新开始，传递一个不同的列表密码
 debug3：preferred publickey，键盘交互式，密码
 debug3：authmethod_lookup密码
 debug3：剩余首选：，键盘交互式，密码
 debug3：authmethod_is_enabled密码
 debug1：下一个身份验证方法：密码
  

如果我正确读取输出（我可能不是），则握手过程使用 aes128-cbc 用于密钥交换，$ code> hmac-md5 用于实际会话加密。根据 JSCH文档（尽管可能很小），支持这两种算法。

我可以使用 sftp 命令行实用程序和FileZilla连接到此共享，因此问题必须无论是使用JSCH还是使用我的Java配置，但我无法弄清楚它是什么。

Java版本：

  java版本1.7.0_71
 OpenJDK运行时环境
 OpenJDK 64位服务器VM（内置24.65-b04，混合模式）
  

JSCH版本：

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

提前致谢！

编辑：看起来像这个确切行为的错误是针对JDK提出的，但是没有解决方案就被关闭了。维护人员之间还有电子邮件主题 JSCH和讨论该问题的JDK开发人员，但没有解决方案。

解决方案

我们最终将JSCH交换为 SSHJ 。它取决于 BouncyCastle 加密库而不是Java的内置加密包，并且能够连接到我们的服务器没有问题。

I'm trying to use JSCH to upload a file to a remote SFTP share. Every time I attempt to connect to the share from within my code, I get an exception that looks something like this:

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]

I've seen posts that describe this error when upgrading to Java 8, but we're still on Java 7, and I don't know enough about Java's cryptography support to know if that matters.

Some people suggest installing JCE (Java Cryptography Extensions) to solve this problem, so I gave it a shot, but I still get the same error after copying the appropriate jar files into the /libs/security directory and restarting the application. We confirmed that JCE was installed by executing this script and noting that the exception was not thrown.

I also tried connecting to the remote SFTP share from the terminal using the sftp command in verbose mode. Here's what I got:

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: [e-mail],[e-mail],[e-mail],[e-mail],ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[e-mail],[e-mail],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[e-mail]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[e-mail],[e-mail],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[e-mail]
debug2: kex_parse_kexinit: [e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],hmac-md5,hmac-sha1,[e-mail],[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],hmac-md5,hmac-sha1,[e-mail],[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[e-mail],zlib
debug2: kex_parse_kexinit: none,[e-mail],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

If I'm reading the output correctly (and I may not be) the handshake process settled on using aes128-cbc for key exchange and hmac-md5 for the actual session encryption. According to the JSCH documentation (minimal though it may be), both of these algorithms are supported.

I can connect to this share with both the sftp command-line utility and with FileZilla, so the problem has to either be with JSCH or with my Java configuration, but I'm at a loss to figure out what's what.

Java version:

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

JSCH version:

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

Thanks in advance!

EDIT: It looks like a bug for this exact behaviour was filed against the JDK, but was closed with no resolution. There's also an email thread between the maintainers of JSCH and the JDK developers that discusses the issue, but has no resolution.

解决方案

We ended up swapping JSCH out for SSHJ. It depends on the BouncyCastle crypto libraries rather than on Java's built-in crypto packages, and is capable of connecting to our server with no problems.

这篇关于Java 1.7 + JSCH：java.security.InvalidKeyException：此算法的键太长的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！