位开发人员|防患于未然，应对“删库跑路”的一种解决思路( 二 ) 解决|公钥|开发人员|应对|跑路

你的组织里可能有很多拥有不同经验水平、身处不同团队、承担不同职责的开发人员，并不是每个人都会访问相同的服务器。
这样的话，让我们在签名流程中添加角色吧。
这样，你可以在服务器上设置允许哪些角色访问服务器，并且在签名过程中可以指定要签名的开发人员的角色。
然后，这位开发人员就能访问与其角色匹配的所有服务器。
当你添加新的开发人员时，只需生成一个证书即可让他们获得授权，访问所有相关服务器，而无需在这些服务器上添加任何内容。
大致上是这样的：

文章插图
带有角色的 ssh 证书签名
下面是在服务器上配置角色的方式：
首先，创建用于配置访问权限的文件夹：sudo mkdir /etc/ssh/auth_principals。在该文件夹中，你可以用允许登录服务器的用户名创建文件。例如，要对某些角色授予 root 访问权限，请添加文件 /etc/ssh/auth_principals/root。
在 /etc/ssh/auth_principals/root 内部，你只需列出所有可以用 root 身份登录的角色，每行一个角色：
最后，再在 /etc/ssh/sshd_config 中添加一行，在服务器上配置为使用角色：
为了使更改生效，你应该重新加载 ssh 服务：sudo service ssh reload。
下面是使用角色签署密钥的方式（它们已添加到证书中）：
这里和之前是一样的，但带有 -n ROLE1,ROLE2 标志。重要提示：不同角色的逗号之间不能有空格！现在，这位开发人员可以登录 auth_principals 文件中有 ROLE1 或 ROLE2 的任何服务器，以获取他们尝试登录时使用的用户名。
注销密钥
最后，如果要使证书无效，可以通过用户名或证书的序列号（-z 标志）来实现。建议你在 Excel 电子表格中列出生成的证书列表，或者根据你的具体情况来建立数据库。
当你已经有一个 revoked-keys 列表并想要更新它时（-u 标志）就这样做。对于初始生成，请拿掉更新标志。list-to-revoke 需要包含用户名（id）或序列号（生成期间为 -z 标志），如下所示：
这将撤消对序列号为 1 的证书以及 ID 为 test.user 的所有证书的访问权限。
为了让服务器知晓已注销的密钥，你需要将生成的 / 更新的 revoked keys 文件添加到 /etc/ssh/revoked-keys，并在 /etc/ssh/sshd_config 中再次配置：
警告：确保 revoked-keys 文件可访问且可读，否则你可能无法访问服务器
小结：ssh 密钥管理的好方
我认为这种解决方案是最好用的。你可以选择通过 ssh 基于角色管理对服务器的访问权限。你只需配置一次服务器（允许哪些角色访问服务器）即可。对于新加入的开发人员，你只需要生成一个签名证书，他们就能立即访问与他们的角色 / 经验相匹配的所有相关机器。当他们离开公司时，你也可以通过一种简单的方式撤销他们的访问权限。
即使发生不幸事故，并且开发人员在未取消访问权限的情况下离开，他们的证书也会在一段时间后过期，因此他们也将自动失去访问权限。
对小型团队来说，你可以手动执行这些步骤，因为这些工作做起来非常快；然后随着你的成长，可以使用基于公司身份验证详细信息的登录服务来自动进行证书签名。
祝你 ssh 快乐！
https://www.paepper.com/blog/posts/how-to-properly-manage-ssh-keys-for-server-access/
每周精要上线移动端，立刻订阅，你将获得
InfoQ 用户每周必看的精华内容集合：
资深技术编辑撰写或编译的全球 IT 要闻；
一线技术专家撰写的实操技术案例；
InfoQ 出品的课程和技术活动报名通道；
“码”上关注，订阅每周新鲜资讯
点个在看少个 bug