同一套Java代码，只把jsch依赖从0.1.54升到0.1.55，连接Apache SSHD（MINA SSHD）的通道就从“一切正常”变成“Algorithm negotiation fail”，退回版本又恢复。这个现象我在两个项目组里都遇到过，很多人第一反应是“新版有bug”，但把握手日志拉出来之后会发现，真正的问题出在SSH协议的第一步：算法协商阶段里，客户端和服务端对ECDSA相关算法的支持范围、默认顺序、曲线长度没有达成一致。尤其是Apache SSHD这种把算法工厂完全开放给应用层的服务端，哪怕只是把host key从P-256换成P-521，jsch 0.1.54和0.1.55就会走两条完全不同的协商路径。
如果你正在维护一个用jsch做SFTP或远程命令执行的Java服务，服务端正好是Apache SSHD或基于它二次开发的文件传输网关，这篇内容可以直接拿来当排查手册。我会把0.1.54和0.1.55在ECDSA密钥曲线、ECDH临时密钥、算法协商顺序上的差异拆开讲，顺便给一套可以直接用的日志定位和配置收敛方案。
1. 先看到的现象：升级后连不上，问题不在版本号
很多人遇到这种“升级即故障”的场景，第一反应是回滚。但回滚只能让业务先恢复，问题并没有被搞清楚。有一次我帮某项目组排查，现象非常典型：他们有一个调度服务，每天通过jsch连接到一组Apache SSHD搭建的跳板机，原本依赖固定在0.1.54，某次安全扫描要求升级到0.1.55，升级后第二天早晨就有一批任务失败，报错清一色是：
com.jcraft.jsch.JSchException: Algorithm negotiation fail at com.jcraft.jsch.Session.connect(Session.java: ...)诡异的是，并不是所有服务器都失败。后来一查，那批失败的服务器都是后来调过算法配置的新节点，旧的没动过。换句话说，0.1.55没有“变差”，它只是让那些被0.1.54“侥幸跳过”的算法不匹配问题浮出了水面。
1.1 一个典型的报错现场
我自己复现过这个过程。用一个最小项目分别依赖jsch 0.1.54和0.1.55，客户端连接代码完全一致：
JSch jsch = new JSch(); Session session = jsch.getSession("test", "192.0.2.10", 2222); session.setPassword("pass"); session.setConfig("StrictHostKeyChecking", "no"); session.connect(30000);服务端是Apache SSHD，监听2222，host key显式配置为521位ECDSA，KeyExchangeFactories里只保留ECDH曲线族。结果：
- 0.1.54连接，报
Algorithm negotiation fail - 0.1.55连接，一次成功
两个版本跑在同一个JDK上，同一个连接参数。差别只在jsch内部维护的算法列表和协商逻辑上。
这里给第一次遇到这类报错的人提个醒：Algorithm negotiation fail是jsch相对笼统的异常，它会同时覆盖KEX算法没有交集、host key签名算法没有交集两种失败。只看到这一句，没法判断是哪一层出了问题，所以后面第5节我会专门讲怎么从日志里拆出真正的失败原因。
1.2 为什么Apache SSHD更容易触发这种差异
Apache SSHD和很多默认配置的OpenSSH服务器不太一样。它允许你完全自定义KeyExchangeFactory、SignatureFactories、KeyPairProvider。这本身是优势，但也意味着服务端的算法组合可能非常“个性化”。
我见过有的团队为了安全加固，在Apache SSHD里只保留：
ecdh-sha2-nistp521ecdh-sha2-nistp384ecdsa-sha2-nistp521ecdsa-sha2-nistp384
这组配置放在OpenSSH上通常没问题，因为客户端算法全。但放到jsch 0.1.54上，就可能没有一组双方都接受的组合。
所以，与其说是“jsch新版兼容性差”，不如说是“旧版jsch对ECDSA高曲线密钥的支持存在边界，而Apache SSHD的可定制性把这个边界放大了”。
2. SSH握手里和“密钥长度”有关的三个层
在深究jsch两个版本的差异之前，得先把概念厘清，因为“ECDSA密钥长度差异”这句话在排查中很容易被误解。SSH连接过程中，至少有三个地方会出现“密钥长度”这个说法。
2.1 第一个层次：KEX阶段使用的ECDH临时密钥
KEX（Key Exchange）阶段用的算法名是ecdh-sha2-nistp256、ecdh-sha2-nistp384、ecdh-sha2-nistp521。这里的“密钥长度”是指椭圆曲线临时密钥的位长，比如256、384、521。它的作用是协商出一个会话密钥，后续所有数据加密都依赖这个密钥。
严格说，这里用的不是ECDSA，而是ECDH。之所以经常被混着叫，是因为它们都构建在同一条NIST曲线上，算法名字里也都带着nistp256/384/521这些字眼。
2.2 第二个层次：服务端host key的ECDSA签名算法
服务端在证明自己身份时，会用host key对某些数据做签名。如果host key是一把EC密钥，那么签名算法就是ecdsa-sha2-nistp256、ecdsa-sha2-nistp384、ecdsa-sha2-nistp521。
这一层才是真正的“ECDSA”，它的密钥长度由host key本身是哪条曲线决定。比如用secp521r1生成的公钥，签名算法就必须是ecdsa-sha2-nistp521。
2.3 第三个层次：curve的具体位长
NIST曲线的命名容易给人误导。P-521听起来很怪，它不是512，就是521位。为什么是521？因为素数域的参数是特殊构造的。这个数值比512多出9位，刚好留出一定的实现余量。很多人第一次看到会以为是拼写错误，其实不是。
我把三个层次整理成一张对照表，方便排查时对照日志：
| SSH阶段 | 算法名示例 | 曲线 / 密钥长度 | 作用 |
|---|---|---|---|
| KEX临时密钥 | ecdh-sha2-nistp384 | P-384，384位 | 协商会话密钥 |
| host key签名 | ecdsa-sha2-nistp384 | P-384，384位 | 验证服务端身份 |
| 证书/公钥存储 | secp384r1 | 384位 | 表示EC密钥曲线域参数 |
当有人说“jsch 0.1.54和0.1.55在ECDSA密钥长度上表现不一样”时，一般指的是第一层和第二层的组合问题：某个版本的客户端KEX列表里有没有对应曲线，某个版本的host key解析和签名验证逻辑能不能正确处理对应长度的EC公钥。
3. jsch 0.1.54 到 0.1.55 的实质变化
理解了层次区别，再看jsch两个版本的差异，脉络就清楚了。0.1.54到0.1.55并不是“新增了对ECDSA的支持”，因为两者都支持ECDSA。真正的变化有两块：默认KEX算法顺序，以及对ECDSA公钥/签名的处理边界。
3.1 默认KEX顺序的变化
SSH算法协商的规则是：客户端和服务端各自发一个算法列表，然后从第一个双方都支持的算法开始选。所以“支持某个算法”只是前提，算法在列表里的排位才是决定最终选哪个的关键。
0.1.54时代的默认KEX列表，在实际抓包时经常看到这样的顺序：
ecdh-sha2-nistp521, ecdh-sha2-nistp384, ecdh-sha2-nistp256, diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha256, ...如果你注意看会发现，ECDH系列在列表里确实有，但排位受前面若干DH算法影响；而在某些早期配置里，实际协商结果会被优先级更高的旧算法抢走。这也是为什么很多人用0.1.54连默认OpenSSH时，最终用的可能是diffie-hellman-group14-sha1，而不是更安全的ECDH。
0.1.55把默认顺序调整为更倾向于ECDH和更新的DH组：
ecdh-sha2-nistp521, ecdh-sha2-nistp384, ecdh-sha2-nistp256, diffie-hellman-group16-sha512, diffie-hellman-group15-sha512, ...这带来的影响是：当Apache SSHD也把ecdh-sha2-nistp521或ecdh-sha2-nistp384放在服务端列表前面时，0.1.55会直接命中较新的算法；0.1.54则可能因为前面的旧算法顺序，或因为服务端根本没启用旧算法，导致协商失败。
3.2 ECDSA公钥解析和签名验证上的差异
这一块是“密钥长度差异”最容易踩坑的地方。0.1.54读取服务端host key时，如果host key是521位的EC公钥，某些JDK版本配合下会出现公钥长度解析异常，或者Signature verification failed。
项目组里曾经出过这样的日志：
com.jcraft.jsch.JSchException: Algorithm negotiation fail但打开调试日志后，真正的位置是连到host key验证阶段就失败了：
kex: server_host_key: ecdsa-sha2-nistp521 Checking hostkey ...0.1.54对ECDSA host key的校验逻辑相对简单，碰到P-521，偶尔会把密钥长度当作“不支持的类型”处理。0.1.55补强了这一块，能正确识别256/384/521三种曲线，并走对应的签名验证链路。
换句话说，同样一句话Algorithm negotiation fail，在0.1.54里可能是“KEX列表没交集”，也可能是“host key算法名匹配上了，但后续验签因为密钥长度问题被拒”。后者在升级到0.1.55后通常会消失。
4. 在Apache SSHD下复现这个差异
光看源码和changelog不够，最好自己在本地把场景搭出来。下面的配置就是我在排查时用过的还原方案。
4.1 构造一个P-521优先的SSHD服务端
Apache SSHD的算法工厂可以用SshServer.setKeyExchangeFactories和setSignatureFactories来指定。为了放大差异，把服务端设置成只支持NIST大曲线：
SshServer sshd = SshServer.setUpDefaultServer(); sshd.setPort(2222); sshd.setHost("0.0.0.0"); // 生成521位ECDSA host key KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("EC"); ECGenParameterSpec ecSpec = new ECGenParameterSpec("secp521r1"); keyPairGen.initialize(ecSpec); KeyPair hostKey = keyPairGen.generateKeyPair(); sshd.setKeyPairProvider(new AbstractKeyPairProvider() { @Override public Iterable<KeyPair> loadKeys() { return Arrays.asList(hostKey); } }); // 服务端只启用ECDH大曲线 sshd.setKeyExchangeFactories(Arrays.asList( new EcdhCurveFactory(Curve.nistp521), new EcdhCurveFactory(Curve.nistp384), new EcdhCurveFactory(Curve.nistp256) )); sshd.start();这里有几个关键点。第一，secp521r1就是ecdsa-sha2-nistp521背后的曲线名；第二，如果想让服务端只认521位host key，客户端就必须在server_host_key算法列表里包含ecdsa-sha2-nistp521；第三，KEX工厂里的Curve.nistp521对应KEX算法ecdh-sha2-nistp521。
我把这个服务端跑起来之后，分别用0.1.55和0.1.54连接，对比非常直观。
4.2 0.1.54连接得到的日志与报错
0.1.54连接时，打开jsch日志后看到类似内容：
SSH_MSG_KEXINIT received kex: server: ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256 kex: host key algorithms: ecdsa-sha2-nistp521 ... com.jcraft.jsch.JSchException: Algorithm negotiation fail这说明客户端把服务端列表读到了，但客户端自身的算法集合里没有一个能与服务端匹配上。从jsch内部看，它只在KEX列表里给出了自己能接受的算法子集，而那个子集和ecdh-sha2-nistp521为首的列表最终没有成功交汇。
4.3 0.1.55连接得到的日志
换成0.1.55后，同样的服务端，日志变成：
kex: server: ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256 kex: host key algorithm: ecdsa-sha2-nistp521 kex: server->client ecdh-sha2-nistp521 kex: host key: ecdsa-sha2-nistp521后面的加密通道建立、认证流程、SFTP子系统打开全部正常。两版客户端在同一个JDK环境下的差异完全由jsch内部算法集合和排序决定。
如果你不想写Java代码去验证，还可以用OpenSSH客户端做一个等效测试：
ssh -vvv -p 2222 -o HostKeyAlgorithms=ecdsa-sha2-nistp521 test@192.0.2.10如果OpenSSH能连上，但jsch 0.1.54连不上，基本可以确认问题在jsch侧的算法支持范围。
5. 排查时怎么定位真正的“密钥长度差异”
很多实际故障不会像我搭的复现环境那么干净。服务端不一定只开放521，可能256、384、521全开着，也可能RSA和ECDSA混用。这时候需要一套标准定位流程。
5.1 先把jsch日志打开
jsch自带的logger默认是关闭的，需要手动set：
JSch.setLogger(new JSchLogger()); class JSchLogger implements com.jcraft.jsch.Logger { @Override public boolean isEnabled(int level) { return true; } @Override public void log(int level, String message) { System.out.println(message); } }然后观察seq，重点看三行：
kex: server: ...：服务端发来的算法列表kex: server_host_key: ...：服务端声明支持的host key签名算法kex: server->client ...：双方最终选定的KEX算法
如果第一行和第二行里能看到ecdh-sha2-nistp521/ecdsa-sha2-nistp521，但最终没有继续，那就是算法列表交集为空。
5.2 区分KEX失败和host key失败
这两种失败的日志特征不同。KEX失败时，日志在SSH_MSG_KEXINIT交换后就直接抛Algorithm negotiation fail。host key相关失败时，往往能看到：
kex: server->client ecdh-sha2-nistp521 kex: host key: ecdsa-sha2-nistp521然后才在“Checking hostkey”这段报异常，或者验签阶段失败。
把这两种情况分清，才能决定改哪个配置。我在实际排查中见过有人只改kex配置，但问题是host key签名算法，结果改了等于白改。
5.3 用OpenSSH的算法列表辅助定位
本地有一台能连目标服务端的机器时，可以用：
ssh -Q kex ssh -Q sig看OpenSSH客户端默认支持哪些KEX算法和签名算法。再把目标服务端用ssh -vvv连一次，看协商结果。如果OpenSSH最终选的是ecdh-sha2-nistp521和ecdsa-sha2-nistp521，而jsch 0.1.54连不上，那么你要做的就是让jsch的配置也能覆盖这条组合。
这一步能非常快地缩小范围，不需要一上来就抓包。
6. 解决方案与收敛配置
根据你是“可以升级依赖”还是“必须钉死在旧版本”，方案完全不同。我建议优先升级，因为0.1.55之后还有更多新版本修复了其他安全问题，长期钉在0.1.54并不划算。
6.1 升级到0.1.55后，显式把算法顺序写清楚
升级之后，不要完全依赖默认值，特别是面对Apache SSHD这种定制化服务端时。推荐在客户端显式声明kex和server_host_key：
JSch jsch = new JSch(); Session session = jsch.getSession("test", "192.0.2.10", 2222); Properties config = new Properties(); config.put("kex", "ecdh-sha2-nistp521," + "ecdh-sha2-nistp384," + "ecdh-sha2-nistp256," + "diffie-hellman-group16-sha512," + "diffie-hellman-group15-sha512," + "diffie-hellman-group14-sha256"); config.put("server_host_key", "ecdsa-sha2-nistp521," + "ecdsa-sha2-nistp384," + "ecdsa-sha2-nistp256," + "ssh-rsa"); session.setConfig(config);这样做的意义不是“把所有算法都打开”，而是把自己的偏好和兼容范围明确告诉服务端。我把更安全的521/384放前面，256兜底，再往后才是DH组。如果服务端只支持256，也能正常连上；如果服务端只支持521，同样能连上。
6.2 必须保留0.1.54时的做法
如果因为某些历史原因没法升依赖，最低成本的方案是让Apache SSHD服务端“向下兼容”。比如在服务端的KEX工厂列表和签名工厂里同时保留P-256和RSA：
sshd.setKeyExchangeFactories(Arrays.asList( new EcdhCurveFactory(Curve.nistp256), new DHGroupFactory("diffie-hellman-group14-sha1") )); sshd.setSignatureFactories(Arrays.asList( new EcdsaSignatureFactory("ecdsa-sha2-nistp256"), new RsaSignatureFactory("ssh-rsa") ));0.1.54对P-256和RSA的兼容性远比P-521可靠。这算是一个妥协方案，能恢复业务，但我不建议长期这么干，因为diffie-hellman-group14-sha1里的SHA-1已经不适合继续用于新系统。
6.3 顺手做一次安全基线收敛
不管是哪个版本，建议把明显过时的算法直接关掉：
diffie-hellman-group1-sha1：已经非常危险，应禁用ssh-dss：DSA签名，密钥长度受限，应禁用ssh-rsa（也就是RSA with SHA-1签名，注意OpenSSH语境下的“ssh-rsa”）应该谨慎启用，尽量用rsa-sha2-256/512
Apache SSHD端可以用setKeyExchangeFactories和setSignatureFactories只保留白名单。这样就算客户端算法列表再乱，服务端也不会降到不安全算法上。
7. 排错速查表与实际经验
最后把常见报错和排查方向整理成一个速查表。这张表是我排查类似问题时最常对照的版本。
| 日志或报错 | 可能原因 | 优先排查方向 |
|---|---|---|
| JSchException: Algorithm negotiation fail | KEX算法列表无交集，或host key签名算法无交集 | 打开jsch日志，看server列表，确认是否包含ecdh/ecdsa对应曲线 |
| 能看到server->client ecdh...但随后unknown or unsupported host key type | host key签名算法不在client的server_host_key列表内 | 增加server_host_key配置或在服务端放行RSA/P-256 |
| Signature verification failed | 公钥获取成功但ECDSA验签失败，常见于P-521公钥解析问题 | 升级到0.1.55，或在服务端改用P-256/RSA |
| UnknownHostKey | StrictHostKeyChecking开启但known_hosts里没有对应host key | 确认known_hosts里保存的公钥类型和当前连接一致，尤其ECDSA长度变了会被当成新key |
| connection timed out | 不是算法问题，通常是防火墙或服务端监听配置 | 先用nc/ssh -vvv验证端口可达性 |
7.1 一个容易被忽略的细节：known_hosts里的密钥长度
StrictHostKeyChecking开启时，客户端会把host key存到known_hosts。如果你原来连的是256位ECDSA host key，后来服务端换成了521位，校验会直接按UnknownHostKey拒绝。很多人把它当成算法协商问题，其实只是host key变了。
这类问题我处理的最快方式是先用OpenSSH客户端连一次：
ssh-keygen -R -f known_hosts [host]:2222 ssh-keyscan -p 2222 -t ecdsa-sha2-nistp521 host >> known_hosts等确认是host key本身变了再处理jsch侧的StrictHostKeyChecking，别一上来就关校验。
7.2 排查时不要同时改多个变量
升级jsch版本、改服务端算法配置、调整known_hosts这些操作如果不是分步做，出了问题很难定位到底哪一步引入的。我的习惯是：
- 保持服务端不动，只切换客户端依赖版本，记录每个版本的连接结果
- 保持客户端版本不动，单独调整Apache SSHD的算法工厂，观察协商日志
- 确定是哪一层不匹配后，再做配置收敛
曾经有一次，项目组把服务端从公司内网移到云上，同时升级了jsch，结果连不上后团队花了一整天查算法，最后发现是防火墙端口策略变了。所以，先确认最底层连通性，再谈算法。
7.3 最后分享一个小技巧
在写这段配置时，可以先把双方算法列表打印出来做集合求交。我一般是写一个小的调试工具，把客户端kex、server_host_key和服务端日志里的算法列表分别读出来，直接用一个Set取交集。这样比肉眼来回看日志快得多。
Set<String> clientKex = new HashSet<>(Arrays.asList("ecdh-sha2-nistp521", "ecdh-sha2-nistp384", "..." )); Set<String> serverKex = new HashSet<>(Arrays.asList("ecdh-sha2-nistp521", "ecdh-sha2-nistp384", "ecdh-sha2-nistp256")); clientKex.retainAll(serverKex); System.out.println(clientKex);如果交集为空，说明两边算法版本差异实在太大，必须先在服务端打开至少一个客户端支持的算法。
我个人在实际操作中的体会是，jsch 0.1.54和0.1.55在连接Apache SSHD时的差异，本质上不是“新版不支持旧算法”，而是“新版本把算法选择权重新分配了一遍”。很多用0.1.54跑通的服务端，其实是靠默认列表里的旧算法碰巧兜住了底。升级到0.1.55以后，默认偏向更安全的ECDH大曲线，反而让那些原本就只支持旧算法的服务端暴露了真实配置问题。排查时别急着怪版本，把两边算法列表打出来，做一次集合求交，通常十分钟就能找到答案。
