Back In Time项目中SSH密钥密码缓存机制的问题与解决方案

Back In Time是一个流行的Linux备份工具，它使用rsync和SSH进行远程备份。在实现SSH连接功能时，项目使用了一个名为backintime-askpass的工具来缓存SSH密钥的密码。然而，这个机制存在一个严重的设计缺陷：当用户更改了SSH密钥密码但缓存中仍保留旧密码时，系统会进入无限循环状态。

问题背景

SSH密钥通常用于安全的远程连接，许多用户会选择为密钥设置密码以增加安全性。Back In Time通过backintime-askpass工具缓存这些密码，避免在每次备份时都需要用户手动输入。这个机制的工作原理是：

1. 当首次使用SSH密钥时，backintime-askpass会提示用户输入密码
2. 工具将密码缓存在内存中
3. 后续使用时直接从缓存获取密码

问题重现

当用户更改了SSH密钥密码后，会出现以下情况：

1. 系统尝试使用缓存的旧密码进行认证
2. 认证失败后，ssh-add会再次请求密码
3. backintime-askpass再次提供相同的旧密码
4. 这个过程无限循环，导致系统挂起和高CPU使用率

技术分析

问题的核心在于backintime-askpass缺乏密码有效性验证机制。它盲目地提供缓存的密码，而不验证这个密码是否仍然适用于当前的SSH密钥。此外，ssh-add在密码错误时会不断重试，而不会给用户重新输入密码的机会。

解决方案探讨

经过深入分析，我们考虑了多种解决方案：

1. 直接密钥验证法：使用加密库直接尝试用缓存密码解锁密钥

   • 优点：直接有效
   • 缺点：增加依赖项，可能限制平台兼容性

2. ssh-keygen验证法：通过系统命令验证密码有效性

   ssh-keygen -y -f $KEY -P $PASSWORD
   

   • 优点：无需额外依赖
   • 缺点：密码会短暂出现在进程列表中

3. 集成askpass验证法：利用askpass机制本身进行验证

   SSH_ASKPASS=backintime-askpass ssh-keygen -y -f $KEY
   

   • 优点：安全且无需额外依赖
   • 缺点：实现略显复杂

4. PTY交互验证法：使用ptyprocess或pexpect库进行安全交互

   • 优点：最安全的实现方式
   • 缺点：需要添加新依赖

推荐解决方案

综合考虑安全性、实现复杂度和依赖关系，我们推荐采用集成askpass验证法。这种方案：

1. 在调用ssh-add前，先用ssh-keygen测试缓存密码的有效性
2. 如果密码无效，强制backintime-askpass获取新密码
3. 只有验证通过的密码才会用于实际连接

这种实现既保持了现有架构的简洁性，又有效解决了无限循环问题，同时不需要引入新的依赖项。

实施建议

在实际代码修改中，应该：

1. 在所有调用ssh-add的地方添加预验证逻辑
2. 实现密码无效时的处理流程
3. 确保错误信息能正确反馈给用户
4. 考虑添加密码尝试次数限制，防止未授权访问

这个改进不仅解决了当前的问题，还增强了整个SSH连接过程的安全性和可靠性，为用户提供了更好的使用体验。