ContainerSSH 与 Fedora SSH 客户端兼容性问题排查实录

问题现象

在使用 ContainerSSH 0.4/0.5 版本部署于 Kubernetes 环境时，发现 Fedora 39/40 系统的 SSH 客户端无法正常完成认证流程。具体表现为客户端连接建立后，在显示本地版本字符串 SSH-2.0-OpenSSH_9.3 后便停滞不前，无法进入认证阶段。而同一环境下，Ubuntu 系统的 SSH 客户端则能正常工作。

技术背景

ContainerSSH 是一个基于容器的 SSH 服务器实现，它能够将 SSH 会话动态路由到后端容器。这种架构常用于提供临时性的、隔离的 SSH 访问环境。在 Kubernetes 环境中部署时，通常需要通过 Service 和 Ingress 等资源对外暴露服务。

初步排查

通过对比 Fedora 和 Ubuntu 客户端的调试输出，发现两者在连接建立阶段的行为存在差异：

1. Fedora 客户端在发送本地版本字符串后便停止响应
2. 服务端日志仅记录到连接建立，未显示后续的协议交互
3. 移除 Fedora 默认的 SSH 配置文件（/etc/ssh/ssh_config.d/50-redhat.conf）后问题依旧

深入分析

通过数据包捕获分析发现，问题的根源并非 ContainerSSH 本身，而是 Kubernetes 环境中的网络配置问题。具体表现为：

1. 当 ContainerSSH 服务端口、Service 资源的目标端口和 IngressRouteTCP 的端口设置不一致时
2. 某些网络环境下（特别是跨网络访问时）会导致协议交互异常
3. 同一局域网内的客户端可能不受此问题影响

解决方案

确保 Kubernetes 部署中的端口配置完全一致：

1. ContainerSSH 容器监听的端口
2. Service 资源中定义的 port 和 targetPort
3. Ingress 控制器（如 Traefik）中配置的端口

这种配置不一致可能导致网络地址转换（NAT）或端口映射异常，进而影响 SSH 协议的正常交互。

经验总结

1. 跨网络环境的协议问题往往比表面看起来更复杂
2. 容器化部署时，端口配置的一致性至关重要
3. 不同客户端实现可能对网络异常的容忍度不同
4. 数据包捕获是诊断此类问题的有效手段

这个问题虽然最终发现是环境配置问题，但排查过程展示了 SSH 协议交互和容器网络的重要特性，为类似问题的诊断提供了参考范例。