最近在做一个老系统的安全整改，里面有个模块用 jsch 做远程执行和文件传输，依赖一直停在 0.1.55。这版本说实话很多年没大更新了，最直观的问题是连新的目标机器时协商不上 rsa-sha2-512 和 curve25519-sha256，算法对不上直接连接失败。于是把 jsch 升到 0.2.x 系列就成了绕不开的事。本来以为只是换一行 maven 坐标，结果dependency:tree一拉发现情况没这么简单——bcprov-jdk 相关的依赖结构完全变了，版本坐标换了、可选依赖可能变成实际引用、还冒出了 bcprov-jdk18on 这种新命名体系。这篇文章就把这次升级过程中对 bcprov-jdk 依赖的分析、冲突处理和验证方法完整记录下来。
1. 升级前先搞清楚：0.2.x 的依赖结构长什么样
1.1 从 0.1.55 到 0.2.x，坐标和依赖的四个变化
如果你之前用的是com.jcraft:jsch:0.1.55，升级到 0.2.x 时第一个要适应的就是坐标源变了。0.2.x 系列基本都在com.github.mwiede这个坐标下发布，groupId 从com.jcraft变成了com.github.mwiede，artifactId 仍然叫jsch。这意味着你需要在 pom 里替换整体依赖坐标，而不是只改版本号。当然，代码层面import com.jcraft.jsch.*的名字没有变，这点不用担心。
第二个变化是 Bouncy Castle 的位置变了。在 0.1.55 里，Bouncy Castle 是一个可选依赖，只有在用到特定功能时才需要手动引入；到了 0.2.x，开始把 bcprov 作为重要依赖引入，用于支持一批新算法。如果你的构建工具在解析时选到了不合适或缺失的版本，运行期就会遇到各种类加载异常。
第三个变化是算法支持列表大换血。0.2.x 加入了对新的密钥交换算法、新的主机密钥类型和新加密算法的支持，比如curve25519-sha256、ssh-ed25519、rsa-sha2-512，以及chacha20-poly1305这样的加密算法。这些新算法里相当一部分需要 Bouncy Castle 的底层密码学实现才能真正跑起来。
第四个变化是 JDK 版本的要求。旧版本在 Java 8 上还算平稳，0.2.x 大部分版本仍然支持 Java 8，但它依赖的 bcprov 版本要求你注意 JDK 8 与 JDK 11/17 的差异。尤其在新版 Bouncy Castle 里，命名空间都换成了jdk18on，如果你的项目运行在 Java 8 上，也要选用对应兼容的版本。
1.2 bcprov 在这些变化里到底扮演什么角色
要理解为什么要重点分析 bcprov-jdk，得先搞清楚 SSH 实现里加解密和密钥交换的机制。jsch 本身不是把所有密码学算法都自己实现一遍，而是复用 Java 平台的 JCE 体系，也就是通过java.security.Provider注册密码学实现。默认情况下，Oracle JDK 自带SunJCE、SunRsaSign这些 provider，能支持基本的 AES、RSA、SHA 系列。
但问题在于，JDK 自带的 JCE 对新算法的跟进很慢。比如curve25519-sha256这类基于椭圆曲线的高性能密钥交换算法，在 Java 8 的老版本 JCE 里根本找不到；rsa-sha2-512也需要较新的 JDK 版本才能原生支持。这时候 Bouncy Castle 的价值就体现出来了——它是一个纯 Java 实现的开源密码学库，把大量 JDK 不提供或提供不完整的算法都补齐了，而且支持注册成 JCE provider。
jsch 0.2.x 通过一个KeyPair相关的初始化逻辑，在检测到 Bouncy Castle 存在时注册它作为额外 provider，从而打开更多算法通道。如果没有 bcprov，jsch 仍然能跑，但能协商的算法范围会被打回原形，很多新特性等于白升级。这也解释了为什么 0.2.x 的依赖分析必须单独处理 bcprov——它不是可有可无的装饰品，而是决定 SSH 功能上限的关键依赖。
1.3 用 dependency:tree 建立升级前后的依赖基线
升级前先做一件事：把当前依赖树完整拉一遍，留一个基线。命令很简单：
mvn dependency:tree -Dincludes=org.bouncycastle:*在升级前，这个命令大概率只输出一行或者什么都没有，因为旧版本里 Bouncy Castle 是可选的，没被其他库间接引进来就没有。升级后你再跑一遍，会看到类似这样的输出：
+- com.github.mwiede:jsch:0.2.24 +- com.jcraft:jzlib:1.1.3 +- org.bouncycastle:bcprov-jdk18on:1.78这个过程需要记录的实际输出当然以你项目当时的解析结果为准，但重点是观察三点：是否多出了 bcprov 依赖、是哪个前缀的 bcprov、版本是多少。把这份 baseline 存下来，后面所有冲突处理都以此为依据。如果你用的是 Gradle，对应的命令是：
./gradlew dependencies --configuration runtimeClasspath它会输出整个 runtime 依赖图，用--dependency bcprov参数可以过滤只看 bcprov 相关分支。
2. 依赖冲突的高发地带：bcprov 版本与坐标命名
2.1 bcprov-jdk15on 与 bcprov-jdk18on 怎么共存
Bouncy Castle 的 jar 命名一直比较折腾。老的体系里主推bcprov-jdk15on，意思是面向 JDK 1.5 及以上版本。到 1.7x 之后，主推的命名变成了bcprov-jdk18on，面向 JDK 1.8 及以上版本，并且很多新算法、新修复只会进jdk18on。于是你的工程里很可能出现两种依赖：某个老 SDK 间接引了bcprov-jdk15on:1.68，jsch 0.2.x 又要求bcprov-jdk18on:1.78。
这里有一个容易误判的点：这两个 jar 在 Maven 眼里是不同 artifact，可以同时被解析出来，都出现在 classpath 上。但它们的 Java 类全限定名高度重叠，本质上就是同一套类的不同构建版本。两个都进 classpath 后，类加载器会根据 classpath 顺序决定加载哪一个，这就造成了不可预期的结果——表面上看依赖树没有冲突标记，实际上运行行为极不稳定。
我的建议是不要让它们共存。最理想的处理是把整个项目的 bcprov 统一到 jdk18on 体系，因为新版本还在持续修复漏洞，老版本的安全问题和算法缺失都更严重。如果某个老组件强依赖 jdk15on 版本并且升级成本极高，那么你要检查它实际用到的类在 jdk18on 中是否存在对应实现，再决定是否可以通过排除依赖来收敛。
2.2 Maven 最近依赖优先规则下的"意外降级"
Maven 的依赖仲裁规则是"最近依赖优先"：如果同一个 artifact 出现多个版本，路径离当前项目最近的那个版本胜出。这个规则在 jsch 升级场景里制造了最常见的坑——你项目里早已通过传递依赖引入了一个老版本的 bcprov，jsch 0.2.x 也带了一个新版本，Maven 选择了离你更近的那个老版本。
举个例子。假设你的项目直接依赖了某个加密组件，它传递依赖bcprov-jdk15on:1.66；同时你显式依赖了 jsch 0.2.24，它声明需要bcprov-jdk18on:1.78。因为那条老版本路径距离你的项目更近，Maven 会把最终解析结果定到老版本上。运行时，jsch 内部调用新版 bcprov API 的时候就会抛NoSuchMethodError，或者干脆NoClassDefFoundError。
排查这个问题不要只盯着 jsch 本身，要看整个依赖树。一个比较实用的检查思路：把所有引入 bcprov 的路径打出来，确认最终生效的是哪一个版本。命令是：
mvn dependency:tree -Dverbose -Dincludes=org.bouncycastle-Dverbose会显示依赖仲裁的细节和省略的重复节点，方便你追踪每条路径。不要嫌输出长，这种问题不看完整树基本没法定位。
2.3 要不要排除 jsch 自带的 bcprov
有人会想：我直接排除 jsch 依赖里的 bcprov，是不是就干净了？这个要分情况，不能一刀切。
如果你完全不使用 Ed25519、bcrypt 加密私钥、chacha20-poly1305这些依赖 BC 的特性，而且你的 JDK 版本也比较新，可以支持 rsa-sha2-512 等常见算法，那么排除 bcprov 确实能缩小依赖体积，jsch 会退回使用 JDK 自带 JCE provider。注意一点：排除后要明确知道自己做了什么，否则后续排查问题会绕远路。
如果你需要完整的 SSH 新算法能力，就不要排除，而是给项目统一引入一个合适的 bcprov 版本。排除再手动引一条实际上是在制造两个不同名的 bcprov 并存局面，比一开始就不排除更容易出问题。我在实际处理中倾向于不排除，而是用 dependencyManagement 把版本锁死，让所有 bcprov 引用最终都收敛到同一个版本上。
还有一点想提醒：永远不要在直觉上认为"排除依赖=解决问题"。"排除"只是把某一个传递引入剪掉，如果别的路径仍然引同一个库，它照样会存在。你真正要做的是"控制最终生效的版本"。
3. 实操：升级 jsch 0.2.x 并锁紧 bcprov 版本的完整过程
3.1 修改坐标并确认传递依赖
这次升级的第一步，是把 pom 里的 jsch 依赖替换成新坐标。以 Maven 为例，改完后大致是这样：
<dependency> <groupId>com.github.mwiede</groupId> <artifactId>jsch</artifactId> <version>0.2.24</version> </dependency>改完先不要直接跑业务代码，先编译一遍确认没有 API 层面的编译错误。0.2.x 对大多数公开 API 是兼容的，但因为算法配置和默认行为有调整，编译大概率能过，运行期行为却可能和 0.1.55 有差异。所以在编译之后，我建议再做一次依赖树的快速核查：
mvn dependency:tree -Dincludes=com.github.mwiede,org.bouncycastle这一步的重点是看 jsch 最终引用的 bcprov 版本是什么。很多时候你以为自己在用 1.78，实际上某个其他依赖把版本拉回了 1.66。看清楚再进下一步。
3.2 统一 bcprov 版本的三种策略
当依赖树里出现多个版本的 bcprov 时，我的处理优先级是这样的：
策略 A：直接在dependencyManagement里锁死一个版本。这是最推荐的做法。在pom.xml的<dependencyManagement>段加上：
<dependencyManagement> <dependencies> <dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcprov-jdk18on</artifactId> <version>1.78</version> </dependency> </dependencies> </dependencyManagement>这样整个项目所有引入 bcprov 的组件都会尝试解析到这个版本，Maven 仲裁时也会优先使用这个受控版本。注意，dependencyManagement只是控制版本，如果依赖树里同时存在jdk15on和jdk18on两种 artifact，还得靠排除来解决。
策略 B：把冲突的传递依赖逐一排除，保留 jsch 自带的 bcprov。适合项目里 bcprov 来源少、可以精准控制的情况。排除写法：
<dependency> <groupId>com.some.group</groupId> <artifactId>some-sdk</artifactId> <version>1.0</version> <exclusions> <exclusion> <groupId>org.bouncycastle</groupId> <artifactId>bcprov-jdk15on</artifactId> </exclusion> </exclusions> </dependency>排除完后再跑依赖树，确认最终只剩一个 bcprov。
策略 C：同时保留 jdk15on 和 jdk18on 并做好隔离。这个策略我一般不推荐，除非某个老组件强制依赖 15on 且无法改动。即使真要这样做，也要明确测试核心业务路径，特别是涉及加密、证书、密钥解析的部分，确保 classpath 顺序没有把错误的实现加载进来。实际操作中这种共存状态出过太多诡异问题，能避免就避免。
3.3 用启动日志验证算法与 Provider
依赖树干净了，不代表运行期就正确。我这次升级踩得最深的一个坑就是：依赖树显示版本正确，但因为没有实际触发 SSH 连接，根本没发现 provider 没有注册成功。所以改完依赖后，我强烈建议做一个显式验证。
可以在应用启动阶段打印当前注册的 security provider：
import java.security.Security; public class ProviderCheck { public static void main(String[] args) { for (java.security.Provider p : Security.getProviders()) { System.out.println("Provider: " + p.getName() + ", version: " + p.getVersion()); } } }如果 Bouncy Castle 成功注册，你会看到类似Provider: BC, version: 1.78的输出。如果没有 BC，说明 jsch 的初始化逻辑没有触发或者 classpath 里的 bcprov 有问题。
另一个验证方式是把 jsch 的日志打开，观察 SSH 协商过程中实际使用的算法。在设置 session 配置时增加日志相关配置，或直接在代码里打开：
JSch.setLogger(new com.jcraft.jsch.Logger() { public boolean isEnabled(int level) { return true; } public void log(int level, String message) { System.out.println("JSch: " + message); } });然后再创建一个 session 去连接测试服务器。日志里会显示类似kex: server: curve25519-sha256这样的输出，看到它就意味着算法协商已经走到 BC 支持的路径上，升级才算真正生效。
4. 升级中真实踩过的坑与排查思路
4.1 NoClassDefFoundError：类存在但版本不对
升级后最容易见到的错误是运行期抛NoClassDefFoundError: org/bouncycastle/jce/provider/BouncyCastleProvider。这个错误的字面意思是类找不到，但大多数时候不是真的缺失，而是版本不对或路径不对。
我遇到的一次比较典型：项目里有两个模块，一个模块的 pom 显式引入了bcprov-jdk18on:1.78，另一个模块没有引入，只依赖 jsch 的可选传递。结果运行时，后一个模块的 classpath 里根本没有 bcprov，jsch 初始化时一引用 BC 的类就抛异常。
解决方式是在该模块里显式添加 bcprov 依赖。很多人以为 jsch 的可选依赖会通过传递依赖自动带进来，这里要理清概念：传递依赖只有非 optional 时才生效，optional 意味着"用不用由你决定，我不替你带"。所以凡是需要 BC 能力的模块，pom 里都必须显式声明。
4.2 NoSuchMethodError：交叉编译版本错位
如果说NoClassDefFoundError是"根本没有"，NoSuchMethodError就是"有，但不是你想要的那个"。这个错误在 jsch 0.2.x 升级后高发的根本原因是类路径上存在两个或多个 bcprov 版本，实际加载的那个版本缺少新 API。
定位这个问题的标准动作有三个。第一是跑依赖树，确认解析到最终版本的路径；第二是用javap直接反编译实际 jar，确认方法是否存在：
javap -cp bcprov-jdk18on-1.78.jar org.bouncycastle.jce.provider.BouncyCastleProvider | grep -i algorithm第三是检查 classpath 顺序。如果多个 jar 存在，JVM 加载类时会按 classpath 顺序找到第一个匹配的类文件，这个顺序在你的构建工具里可能和依赖树显示的顺序不一样。可以用-XX:+TraceClassLoading参数启动应用，观察实际加载的BouncyCastleProvider来自哪个 jar：
java -XX:+TraceClassLoading -cp app.jar 2>&1 | grep BouncyCastle看到加载路径后，再去追它对应的 jar 从哪里来，基本就能定位到哪个组件干的。
4.3 无法加载 Ed25519 / bcrypt 私钥的处理
升级后有一个能力和依赖强相关的场景：加载 OpenSSH 格式的私钥。如果你手里的私钥是用 bcrypt 算法加密的 OpenSSH 私钥文件，jsch 0.2.x 需要 Bouncy Castle 来提供 bcrypt 实现。如果 bcprov 缺失或版本过低，加载私钥时会直接抛异常，提示无法解析私钥。
这个问题的隐蔽性在于：通常开发时用的密钥是未加密或明文格式的，一切正常，一到生产环境拿到加密私钥就失败，而且错误信息并不直接指向 Bouncy Castle。排查时要首先确认私钥的加密类型。可以通过打开私钥文件看头部信息来判断，如果BEGIN OPENSSH PRIVATE KEY段的内容在解密头部带了bcrypt相关参数，那基本就是要 BC 支持了。
解决方式就是确保 bcprov 版本不低于支持 bcrypt 的版本，一般 1.70 之后的jdk18on体系都能正常处理。这个能力是判断依赖是否真正到位的最直接指标之一。
4.4 回归验证清单：确保 SSH 功能不变形
依赖排查完以后，最后不要忘了把原有的 SSH 场景全部回归一遍。我的清单通常包含这几项：
- 常规密码认证连接：确认
session.connect()正常，服务端版本打印正确 - 公钥认证连接：确认密钥加载成功，没有提示无法解析
- 密钥交换算法协商：打开日志确认协商到了预期算法
- SFTP 上传下载：验证文件内容一致，断点传输和目录切换正常
- 端口转发和跳板机场景：jsch 的
setPortForwardingL行为是否和旧版一致 - 主动断开和超时重连：确认异常路径没有因为新依赖引入新的线程问题
这几项不用全部自动化，但要确保手工测过一遍。尤其是跳板机和转发的场景，个别版本对 channel 生命周期的处理有细微变化，不回归容易在线上临时炸掉。
5. 升级之外还要盯住的安全事项
jsch 0.2.x 升级完成不代表这件事可以画句号。bcprov 是一个安全敏感的基础库，它和 jsch 一起出现在依赖树里以后，安全意识反而要更强。
一个明显的问题是版本安全漏洞跟踪。Bouncy Castle 本身也属于安全组件，老版本同样被爆过漏洞。你升级 jsch 的时候顺手引入的新版本往往修复了旧漏洞，但如果后来又因为别的依赖把版本拉低，等于把漏洞重新带回来。建议引入 OWASP Dependency-Check 或类似工具，把每次依赖变更的 CVE 扫描结果纳入检查流程。
另一个问题是 BC 版本与 JDK 版本的匹配。如果项目以后升级到 Java 17，要注意 1.7x 以前的老 bcprov 版本可能在模块化系统下出现module-info相关的问题。现在普遍使用的bcprov-jdk18on对 Java 8 和 Java 17 都有较好支持，但如果你因为历史原因停留在bcprov-jdk15on，就要评估后续 JDK 升级的兼容性。
还要留意不要盲目排除依赖造成隐性问题。我见过有团队为了追求依赖树干净，把所有 optional 依赖全部排除，结果 jsch 变成了"半残版"，表面上功能正常，但实际上 Algo 协商能力被大幅削弱，只是因为目标服务器比较宽容而没暴露问题。升级依赖不是为了在依赖树里好看，是为了让真实业务链路在新环境里可靠运行。
这次升级之后我最大的一个感受是：依赖分析不是只盯着 jsch 这一个点看，而是要以它为引子，把 classpath 上所有密码学相关的组件重新盘一遍。整个过程里我反复用dependency:tree、javap、TraceClassLoading三个工具，把 bcprov 的最终生效路径和实际加载逻辑都摸了一遍，才敢把改动发出去。这里面的经验其实也很简单：先拉树、版本锁定、再验证算法协商，按这个顺序走，就不会在线上被突如其来的类加载错误打个措手不及。
