实际使用与边界
适用场景：只在可信设备上执行转换：每次导出后重新派生并比较公钥，记录每个客户端需要的格式，并删除不必要的私钥副本。
边界：转换后的私钥仍是凭证。移动端导入要求可能变化；不要把私钥上传到在线转换器，也不要把文件扩展名当成格式证明。
先给结论
Ed25519 是密钥算法，OpenSSH 和 PKCS8 是私钥保存格式。Mac 的系统 ssh 通常直接使用 OpenSSH 私钥；某些移动端导入流程可能要求未加密的 PKCS8 PEM。最稳妥的做法是保留一个服务器公钥身份，为不同客户端生成受控的私钥导出，并在每次转换后验证公钥没有变化。
服务器只需要匹配的公钥
服务器在目标账户的 authorized_keys 中保存公钥，用它验证客户端私钥产生的签名。将同一个私钥转换成另一种容器格式，不应改变派生出的公钥。不要只看文件名、扩展名或短指纹；应从每个私钥重新导出完整的 OpenSSH 公钥行，再比较算法前缀、密钥材料和注释。
OpenSSH 与 PKCS8 的区别
OpenSSH 私钥常见头部是 BEGIN OPENSSH PRIVATE KEY，适合系统 ssh。PKCS8 PEM 常见头部是 BEGIN PRIVATE KEY，是更通用的序列化格式，部分应用导入器会要求它。pem 扩展名不能证明真实格式；旧版 OpenSSL 或 LibreSSL 也可能对 Ed25519 支持不完整。
一套可复核的转换流程
在可信电脑上生成并保护原始 Ed25519 私钥，只把公钥放进服务器。移动端确实需要另一格式时，使用当前加密库在隔离环境中导出副本，避免上传到在线转换网站。转换后立即派生公钥、和服务器记录比较，并删除不再需要的临时文件。
配置、权限与连接验证
在 SSH 配置中明确 Host、HostName、User、Port 和 IdentityFile，首次诊断使用 ssh -v 查看实际加载和提供了哪些身份。私钥应只有所有者可读；成功建立 TCP 连接只说明服务器可达，只有公钥认证成功才说明身份匹配。替换唯一凭证前，先保留一条已经测试的恢复路径。
常见问题与安全边界
为了导入方便而删除口令会增加设备丢失后的影响，只能在导入器确有要求、设备有强保护且可以快速撤销公钥时考虑。不要把私钥放进聊天、工单、命令历史、共享云盘或代码仓库。算法、格式和授权记录是三个不同层次，必须分别检查。
常见问题
需要为 Mac 和 iPhone 生成两对密钥吗？
通常不需要。一个 Ed25519 密钥对可以授权两个客户端，但两个客户端可能需要不同格式的私钥副本。
OpenSSH 转 PKCS8 会改变公钥吗？
使用同一个私钥正确转换时不会改变。应通过重新导出的完整公钥验证，而不是相信文件名。
可以把私钥上传到在线转换网站吗？
不应该。私钥一旦离开受控环境，就很难确认是否被保存或复制；应使用本地、受信任的加密库完成转换。