GPG keys、SSH keys与Personal Access Tokens适用场景及差异问询

1. 三类凭证的适用场景分别是什么？ #

• SSH keys：适用于本地常用设备和代码托管平台的日常通信鉴权，主要给Git的SSH协议做拉取、推送的身份验证，配置后不需要反复输入账号密码，是个人日常开发最常用的鉴权方式。
• Personal Access Tokens（PAT）：适用于HTTPS协议的仓库访问、第三方工具/CI/CD流水线鉴权、临时授权、细粒度权限管控的场景，可以按需设置有效期、可访问的资源范围，就算泄露也可以快速吊销，不会影响其他凭证的安全性。
• GPG keys：核心场景是提交内容的签名验证，用来给代码提交（commit）、版本标签（tag）做签名，证明提交内容确实来自你本人且没有被篡改，也可以用来加密仓库内的敏感配置，部分平台支持用GPG做SSH鉴权，但属于非主流用法。

2. 三者都能实现代码仓库的安全授权，为什么需要三种不同的实现？ #

三者的设计初衷完全不同，只是在代码仓库的安全体系里刚好有功能重叠：

SSH keys的原生设计目标是解决两台主机之间的加密通信、免密登录问题，属于传输层的安全方案，和代码仓库没有绑定关系，只是代码托管平台复用了这套成熟的协议做鉴权而已。
PAT是专门为Web服务、API场景设计的轻量令牌，天生支持细粒度权限配置、有效期管控，适配现在云服务、第三方集成、临时授权的需求，本身就是为了服务类鉴权设计的。
GPG keys的核心能力是非对称加密和数字签名，属于内容层的安全方案，解决的是「内容可溯源、不可篡改」的问题，本来就不是为了连接鉴权设计的，只是平台用它的签名能力来验证提交者身份，才进入了代码仓库的安全体系。

3. 有没有特定场景下某一种方案体验明显优于另外两种？ #

确实存在很多这类场景，举几个最常见的：

• 个人本地日常开发：SSH keys体验最好，配置一次后所有Git操作不需要额外输入凭证，适配所有主流Git客户端和代码托管平台，比每次输PAT方便，比用GPG做鉴权的兼容性高得多。
• CI/CD流水线、第三方工具授权：PAT是最优选择，你可以单独给某条流水线开仅对应仓库的只读权限，设置和流水线生命周期一致的有效期，就算泄露也不会影响账号其他资源的安全，SSH keys做不到这么细的权限管控，GPG完全不适合这类场景。
• 开源项目维护、正式版本发布：GPG是不可替代的，你给所有提交、版本标签签名后，用户可以直接验证这个版本确实是官方发布的，没有被篡改，另外两种凭证都做不了内容层面的签名校验。
• 临时在公共设备上访问私有仓库：用PAT最安全，用完直接手动吊销即可，不需要在公共设备上留下你的SSH、GPG密钥，避免密钥被盗造成长期风险。

内容的提问来源于stack exchange，提问作者IEEE754