实际使用与边界
适用场景：维护一份密钥清单，记录负责人、设备、用途、服务器范围、创建日期、最近复核和撤销动作；在设备丢失前测试恢复路径。
边界：没有一种密钥管理方式适合所有威胁模型。分离身份能缩小影响范围，但会增加恢复和清单维护工作。
先画出真实的信任关系
远程开发至少包含设备、客户端私钥、服务器主机密钥，以及使用连接的账户或工具四条信任关系。一把私钥复制到多个设备会扩大泄露影响，多把无记录的密钥又会让恢复困难。先确定要优化的是便利、隔离、审计还是恢复，再决定身份模型。
一把身份还是多把身份
在两个设备同样可信、撤销可控的个人服务器上，共享一把 Ed25519 身份可以简单有效。按设备或人员分别建钥匙则更便于审计：丢失手机时只删除它的公钥。团队和生产环境通常更适合分离身份。
把格式转换当成敏感导出
如果一个客户端需要 PKCS8、另一个使用 OpenSSH，应把转换视作创建新的敏感凭证副本。使用当前库、隔离环境、已知输出路径和严格权限，绝不把私钥交给在线转换服务。完成后验证派生公钥并清理临时文件。
在需要恢复之前建立恢复路径
轮换唯一密钥前，准备已测试的云控制台、第二管理员或其他授权入口。记录服务器地址、账户、密钥标签、主机指纹核验方式和要删除的公钥行。备份只有在可读、可用且不依赖正在修复的凭证时才算恢复方案。
让连接可观察
使用命名 Host 别名、明确 IdentityFile 和简短运行手册，记录日期、设备、密钥用途、服务器和变更原因。保持主机验证，诊断时才临时使用详细日志；不要把秘密放进 shell 历史、工单、聊天、截图或可能提交的环境文件。
有计划地轮换和撤销
设备丢失、私钥可能被复制、人员离开或权限范围变化时，应先添加替代公钥并通过恢复路径测试，再删除旧公钥。怀疑泄露时，撤销和查看服务器日志比保留便利更重要。
结论
良好的 SSH 密钥管理是一套小型运营系统：身份清晰、格式受支持、主机经过验证、权限严格、恢复路径已测试，并且撤销动作明确。目标不是让远程开发变得脆弱，而是让安全路径成为最容易重复的路径。
常见问题
一把 SSH 密钥用于两台设备一定不安全吗？
不一定，但每个私钥副本都会增加丢失或暴露的影响。分设备密钥更利于撤销和审计。
备份私钥应该放在哪里？
放在符合威胁模型的受保护密码管理器或加密离线存储中，不要放入共享云盘、仓库或聊天记录。
手机丢失后第一步做什么？
从所有服务器撤销手机对应的公钥，查看近期认证日志，并轮换可能暴露的凭证，然后通过已测试的恢复路径恢复访问。