Semaphore项目SSH认证问题分析与解决方案

问题背景

Semaphore是一个基于Web的Ansible管理界面，在最新版本v2.10.2中，用户报告了一个严重的SSH认证问题。当使用用户名/密码方式进行SSH连接时，系统会错误地尝试使用公钥认证，导致连接失败并返回"Permission denied (publickey,password)"错误。

问题现象

用户在Docker Compose环境中运行Semaphore，配置了ANSIBLE_HOST_KEY_CHECKING: false环境变量，并通过用户名/密码方式认证。升级到v2.10.2后，所有之前正常工作的playbook都开始出现认证失败。错误日志显示系统尝试了多种公钥认证方式，包括：

1. /home/semaphore/.ssh/id_rsa
2. /home/semaphore/.ssh/id_ecdsa
3. /home/semaphore/.ssh/id_ed25519
4. 其他多种密钥类型

尽管服务器配置了密码认证方式，系统却完全跳过了密码认证流程，直接尝试公钥认证后失败。

技术分析

从详细的SSH调试日志(-vvvv)可以看出几个关键点：

1. SSH客户端列出了所有可能的认证方法：publickey和password
2. 系统优先尝试了publickey认证，遍历了所有可能的密钥文件
3. 当所有公钥认证尝试失败后，系统没有回退到密码认证，而是直接终止了连接
4. 环境变量ANSIBLE_HOST_KEY_CHECKING在UI中显示异常（有删除线样式），但手动修复后问题依旧存在

这明显是一个认证流程逻辑错误，系统错误地跳过了配置的密码认证方式，直接尝试了不存在的公钥认证。

解决方案

Semaphore开发团队迅速响应并修复了此问题：

1. 在v2.10.5-beta版本中首次尝试修复
2. 经过用户验证后，确认v2.10.6-beta版本完全解决了该问题
3. 后续的v2.10.7版本也保持了修复效果

对于遇到此问题的用户，建议采取以下步骤：

1. 升级到v2.10.6或更高版本
2. 检查环境变量设置是否正确
3. 确认密钥库中的认证信息已正确配置

经验总结

这个案例展示了几个重要的DevOps实践：

1. 版本升级前应在测试环境充分验证
2. 认证流程是基础设施自动化的关键环节，需要特别关注
3. 详细的日志记录(-vvvv)对于诊断复杂问题至关重要
4. 开源社区的快速响应和协作能有效解决问题

对于使用Semaphore管理Ansible playbook的团队，建议建立完善的升级验证流程，特别是在涉及核心功能如认证机制变更时。同时，保持对项目issue跟踪的关注，可以及时获取关键问题的修复信息。