Otomi-core项目中Gitea的SSH访问功能增强探讨

在基于Kubernetes的云原生平台Otomi-core中，Gitea作为内置的Git服务组件，其访问控制机制存在值得优化的技术点。本文将深入分析当前认证模式的局限性，并探讨SSH接入的实施方案。

现有认证机制分析

当前Otomi-core集成的Gitea服务采用OpenID Connect作为主要认证方式，这种设计在Web界面访问时表现良好，但在代码仓库操作场景下暴露了两个关键问题：

1. 密码认证的固有缺陷
   用户必须单独设置Gitea账户密码才能执行git操作，这导致：

   • 密码复用风险增加（与Otomi控制台密码相同）
   • 缺乏密码轮换机制（修改需原密码）
   • HTTP Basic Auth传输敏感信息的安全隐患

2. 开发者体验断层
   命令行操作与Web控制台采用不同认证体系，不符合Git平台的主流实践模式（如GitHub/GitLab的SSH密钥或专用CLI令牌机制）。

技术改进方案

临时解决方案：访问令牌机制

通过Gitea的"应用令牌"功能可部分缓解问题：

1. 在用户设置中生成repo权限的访问令牌
2. 使用https://[token]@gitea.domain/[org]/[repo].git格式克隆仓库
3. 支持令牌的即时吊销与再生

该方案虽解决了密码管理问题，但仍存在HTTP传输的潜在风险，且不符合基础设施即代码(IaC)工作流的最佳实践。

终极方案：SSH协议支持

建议通过以下改造实现原生SSH支持：

1. 服务端配置

   • 启用Gitea的SSH服务监听（默认端口22需映射）
   • 集成集群的Ingress Controller处理SSH流量
   • 配置SSH证书颁发机构(CA)实现集中式密钥管理

2. 客户端适配

   • 用户通过[e-mail]:org/repo.git格式访问
   • 支持Ed25519等现代加密算法
   • 与现有SSH agent集成实现密钥安全存储

3. 密钥生命周期管理

   • 提供CLI工具自动注册用户公钥
   • 设置密钥自动过期策略
   • 审计日志记录所有SSH访问事件

安全增强对比

认证方式	传输加密	MFA支持	密钥轮换	会话劫持防护
HTTP密码	TLS	❌	手动	弱
访问令牌	TLS	✅	即时	中
SSH公钥	原生加密	✅	自动	强

实施建议路线图

1. 阶段一：文档补充现有令牌使用方案
2. 阶段二：增加SSH服务Helm chart配置项
3. 阶段三：集成Vault实现自动密钥分发
4. 阶段四：弃用密码认证强制使用SSH

通过分阶段演进，可在保证现有用户不受影响的前提下，逐步过渡到更安全的认证体系。对于企业级用户，建议直接采用SSH方案以获得完整的审计和安全控制能力。