为了更好地安全性方便快捷的管理方法和维护保养服务器，严禁SSH登陆密码登录，并且用证书验证是比较好的挑选。其方式 是用户生成密匙对，其私钥严苛存放不泄漏，将公钥加上到服务器上用户相匹配的authorized_keys文件，随后就可以用证书方法开展登录，在证书生成的情况下，还可以对证书加上登陆密码，避免私钥失窃用。

这类方法很便捷，可是存有一个难题，便是当服务器比较多的情况下，对服务器上公钥的管理方法便会较为不便，非常容易当工作人员产生变化情况下，非常容易清除忽略，进而造成 安全风险。文中大家详细介绍一种根据管理中心CA统一审签证书管理方法SSH证书的方式 。

简述

为了更好地处理统一管理方法的难题，引进CA来统一管理方法SSH的验证。用户依然必须生成一个公钥和私钥对证书。可是，验证并不是根据将用户公钥加上服务器来进行，应用证书授予组织（CA）密匙对用户公钥开展签字。签字全过程仅生成了第三个证书文档，用户根据该审签证书和自身原来的证书对就能进行登录。

服务器上，只需配备SSH对CA的公钥验证，服务器根据检验用户证书是不是根据CA审签，来进行验证全过程。

具体方法

建立CA

用户生成一个证书授予组织CA私钥对，并确保私钥的私钥安全性：

umask 77 # 改动掩码，确保自此生成文件目录和文档的管理权限

mkdir ~/CC-ca && cd ~/CC-ca

ssh-keygen -C CA -f ca -b 4096 # 生成情况下，给证书加上一个登陆密码，以避免泄漏

配备CA公钥验证

随后在服务器上，特定容许由CA签字的全部用户浏览该服务器：

将CA的公钥上传入服务器上，比如在/etc/ssh/ca.pub

在/etc/ssh/sshd_config加上下边的行，配备CA审签的证书的信赖：

TrustedUserCAKeys /etc/ssh/ca.pub

重新启动sshd服务项目：

service sshd reload。

CA审签用户证书

用户应用ssh-keygen生成证书，而且把公钥发送给CA管理中心，CA管理中心用私钥对该证书加上签字：

ssh-keygen -s ca -I USER_ID -V 12w -z 1 id_ecdsa.pub

cmd表明：

-s ca 想应用CA开展签字

-I USER_ID -用户ID/用户名

-V 12w -证书到期前的時间，该事例中证书有效期限为12周

-z 1 设定证书的系列号，可以用证书的系列号来销户证书。

id_ecdsa.pub：必须签字的用户公钥

生成证书id_ecdsa-cert.pub，该证书必须发给开发者，用户将其放进~/.ssh文件夹名称。

加上人物角色

上边就可以完成了证书的CA签字和统一验证。可是还有一个难题，很有可能用户也必须归类，不一样的精英团队和人物角色的，必须有不一样的访问限制。事实上，能够 在签字全过程中加上人物角色，用于特定容许服务器的访问限制。新加上用户情况下，就可以使她们能够 浏览全部有关服务器，而不用在这种服务器上加上一切內容。

服务器上配备人物角色信息内容

建立用以配备访问限制的文件夹名称：

mkdir /etc/ssh/auth_principals

在该文件夹名称中，能够 应用服务器用户名创建文件，该用户能够 登陆。比如，要授于对一些人物角色的root用户访问限制，请加上文档/etc/ssh/auth_principals/root。

在/etc/ssh/auth_principals/root文档中，配备能够 以root用户真实身份登陆的人物角色，每列一个人物角色，例如

admin_dev

root_op

ROLE1

在服务器上SSHD环境变量/etc/ssh/sshd_config，加上对人物角色的验证：

AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

随后重新加载sshd服务项目

service sshd reload。

CA审签带人物角色的用户证书

能够 应用一下cmd，审签带人物角色的证书：

ssh-keygen -s ca -I USER_ID -n ROLE1,ROLE2 -V 12w -z 2 id_ecdsa.pub

与之前cmd一样，多提升了-n ROLE1,ROLE2标示。

如今，该用户能够 登陆到auth_principals文档配备了ROLE1或ROLE2人物角色的服务器。

销户证书

前边讲过，能够 对用户证书开展销户。销户用户必须用的用户的系列号。提议愿意维护保养一个用户系列号的目录，或创建数据库。

销户证书文档

根据下边的指令生成一个销户证书文档

ssh-keygen -k -f revoked-keys -u -s ca list-to-revoke

当早已有一个revoked-keys目录并要想升级证书情况下（-u标示）。

在list-to-revoke文档內容由用户名（IDS）或系列号（的-z生成期内标示）是那样的：

serial: 1

id: test.user

这将注销对系列号为1的证书和全部ID为test.user的证书的访问限制。

服务器配备销户

为了更好地使服务器进行对撤消密匙配备，必须将生成的/升级的revoked keys文件加上到/etc/ssh/revoked-keys并在/etc/ssh/sshd_config配备：

RevokedKeys /etc/ssh/revoked-keys

留意：请保证该revoked-keys文件为可浏览且可写，不然会造成 一切用户都不可以浏览。

小结

文中大家详细介绍了一个根据CA签字用户公钥的证书统一管理方案。根据该方式 能够 完成根据人物角色根据ssh管理方法对服务器的浏览。只必须配备服务器一次（容许什么人物角色浏览服务器）。针对每一个用户，只必须生成一个签字证书，就可以完成按人物角色登录全部有关设备的方式 。还可以便捷销户用户的证书，进而限定用户的浏览。因为每一个证书签字必须实效性限定，即便 无法立即销户用户管理权限，还可以在超出有效期限后全自动销户，进而确保了安全性。

文章转载自网络，如有侵权，请联系api@1dq.com删除