Coolify自托管部署中SSH密钥问题的分析与解决

问题背景

在自托管部署Coolify v4.0.0-beta.380版本时，用户遇到了一个与SSH密钥相关的启动问题。当容器启动时，系统会尝试建立到宿主机的SSH连接，但在失败后会删除/data/ssh/keys目录下的[e-mail]密钥文件，导致后续启动持续失败。

问题现象

1. 容器启动时输出错误信息："Could not setup dynamic configuration: [e-mail]: Permission denied (publickey,password)"
2. 检查SSH服务日志发现连接尝试被提前终止
3. 每次启动失败后，/data/ssh/keys目录下的密钥文件会被自动删除
4. 手动重新生成密钥并设置正确权限后，问题依然存在

技术分析

密钥管理机制

Coolify采用了一套完整的SSH密钥管理机制：

1. 密钥存储在PostgreSQL数据库的private_keys表中
2. 密钥数据采用Base64编码存储
3. 解码后可见JSON结构包含IV(初始化向量)、MAC(消息认证码)和实际私钥值
4. 系统启动时会检查数据库中的密钥与文件系统中的密钥是否匹配

问题根源

当用户"意外"覆盖了.ssh/authorized_keys文件后，系统原有的密钥对失效。此时：

1. 新生成的密钥与数据库中存储的加密密钥信息不匹配
2. 系统检测到不一致后，触发了安全机制删除文件系统中的密钥
3. 这导致后续启动时无法建立SSH连接，形成恶性循环

解决方案

方法一：重建密钥对

1. 停止Coolify容器
2. 删除PostgreSQL数据库中private_keys表的相关记录
3. 手动创建新的SSH密钥对：

   ssh-keygen -t ed25519 -f [e-mail]
   

4. 将公钥添加到宿主机的authorized_keys文件
5. 确保文件权限正确：

   chmod 600 [e-mail]
   chmod 644 [e-mail]
   

6. 重新启动容器

方法二：端口配置调整

部分用户反映解决密钥问题后仍无法访问Coolify界面，这是因为：

1. 新版本中默认服务端口可能从80变更为8080
2. 需要检查并更新docker-compose.prod.yml中的端口映射配置
3. 确保防火墙/安全组规则允许相应端口的访问

最佳实践建议

1. 定期备份/data/ssh/keys目录和数据库中的密钥信息
2. 修改authorized_keys文件前，先记录原有密钥指纹
3. 考虑使用密钥管理工具集中管理部署密钥
4. 升级版本时注意检查配置文件的变更，特别是端口等关键参数

总结

Coolify作为一款自托管PaaS解决方案，其安全机制设计严谨。遇到SSH连接问题时，理解其密钥管理机制是解决问题的关键。通过分析数据库存储结构和文件系统交互方式，可以快速定位并解决类似问题。同时，版本升级时的配置变更也需要特别关注，以确保服务的持续可用性。