据我所知，ssh 证书至少有两个好处：防止密钥蔓延和应用过期。服务器不需要为服务器上的每个用户提供公钥，而只需要一个公钥 - CA 的公钥。
我的问题是：如何对单个用户进行身份验证；如何授权特定权限和角色？如果 CA 公钥通过数字签名对连接进行身份验证，并且服务器不存储公钥（因为毕竟这是 SSH 证书颁发机构的魅力所在，即不存储一堆授权密钥），它如何知道我的身份，以及如何将特定权限应用于我的会话？
至于客户端的身份验证，在我看来，即使我使用 ssh 证书，服务器也必须：首先通过使用 CA 公钥解密数字签名来验证客户端公钥。如果成功解密，则证明我的密钥已由 CA 签名。很好。但接下来呢。它会如何处理我的公钥？如果它没有存储在授权密钥目录中，它怎么知道是我？
简单来说，ssh 服务器是否存储了我的公钥？否则我看不出这怎么可能。但如果它确实存储了公钥，那么这怎么不会导致密钥蔓延呢？这正是我们试图避免的。
除非服务器在验证 CA 签名后使用我的公钥加密某些内容，然后将其发回给客户端解密。如果解密后返回，则证明客户端拥有私钥。此后，服务器会丢弃公钥。是这样工作的吗？
答案1
参考：https://smallstep.com/blog/use-ssh-certificates/
本质上，您的客户端向 CA 发送证书请求。CA 会说您可以xx在服务器上以用户身份登录yy。它会向您颁发私有证书以供使用，并且该证书的有效期很短 - 例如，一个工作日的有效期为 8 小时。
然后，您的 SSH 客户端将该证书发送到远程目标。远程目标获取证书，使用公共 CA 证书对其进行验证，以证明您与 CA 进行了通信。然后，它可以使用自己的私有证书加密数据，并将其发送回您的客户端。您的客户端使用远程的公共证书来验证信息并保护连接。
您无需编辑~/.ssh/authorized_keys使用证书。您的远程主机只需要 CA 的公共证书和他们自己的私有证书，而您的 CA 主机也拥有针对您的目标的公共证书。
这是一个对过程的过度简化。
答案2
在您描述的所有过程中，还有“委托人”的概念。目前，将委托人视为某种“角色”。
也就是说，一个用户可以有多个角色（在 CA 签署她的密钥时指定），并且一个服务器可以允许多个角色（见下文）使用证书登录。只要这两个角色列表至少有一个共同的角色（即“主体”），您就可以加入。
服务器主体来自 sshd 配置AuthorizedPrincipalsFile或principals=用户~/.ssh/authorized_keys文件中的选项。它们也可以来自指定的AuthorizedPrincipalsCommand程序，该程序动态生成具有所需主体语法的行（换句话说，动态版本的AuthorizedPrincipalsFile）