配置sshd_使用CA签名证书登录_更新sshd服务端的通讯密钥

配置sshd_使用CA签名证书登录_更新sshd服务端的通讯密钥

转载注明来源: 本文链接 来自osnosn的博客，写于 2022-11-06.

用CA签名证书登录

• 请参考【SSH 证书登录教程】,这个旧了。
• 参考:【Creating SSH CA Certificate Signing Keys】,这是基于openSSH-5.3p1
• 【SSH 证书登录教程】
• 【基于CA签名的用户公钥管理】,【基于CA签名的用户公钥管理】
• 【证书登录的流程】
• 【Linux 采用 SSH CA 登陆验证】
• putty-0.77 还不支持这种认证。putty-0.78 开始支持CA签名证书认证。
• winscp-5.21.5 还不支持这种认证。下一个版本可能会支持。

ssh登录过程中，基于签名(证书)的用户认证

• 基于 openSSH-8.0p1 , 测试成功。

• 创建 用于签发用户证书的密钥(用户CA)。管理员创建，私钥不传递。
  ssh-keygen -t ed25519 -C user_ca@myCA -f user_ca。
  得到两个文件，user_ca , user_ca.pub。
  只是密钥对，不是证书。因为没做自签名证书。

• 让sshd服务端信任”用户CA”的公钥。(方法一,用户级)
  建议限制 principals。如果多个服务器信任同一个CA，只要每个服务器上的 principals 都不同。
  就能做到，用同一个CA签发的用户证书，能登录其中一个服务器，而不能登录别的服务器。
  在sshd服务器上，用户的 ~/.ssh/authorized_keys 中加入一行(用户CA的公钥)。此文件权限mode要求是0600。
  cert-authority,principals="host02,allhost" ssh-ed25519 AAAAC.....xx user_ca@myCA
  内容为 user_ca.pub 文件的内容。
  如果用户证书包含 host02 或 allhost 才能登录(此种情况不判断用户名)。
  每个想用证书登录的用户的 ~/.ssh/authorized_keys 都要加一行。

  • 不做限制，在sshd服务器上，用户的 ~/.ssh/authorized_keys 中加入一行(用户CA的公钥)。
    cert-authority ssh-ed25519 AAAAC.....xx user_ca@myCA
    如果用户证书没有principals，可以登录
    如果用户证书有principals，必须包含用户名 才能登录。

• 让sshd服务端信任”用户CA”的公钥。(方法二,全局系统级)
  在sshd服务器上，在 /etc/ssh/sshd_config 中加入一行:
  TrustedUserCAKeys /etc/ssh/user_ca_list.pub ,
  重启 sshd 服务生效, service sshd restart。
  这种配置，用户证书必须有principals，且包含用户名才能登录。
  user_ca_list.pub 可以多行，CA公钥文件user_ca.pub的内容占其中一行。文件权限mode可以是0600或0644。
  例如: ssh-ed25519 AAAAC.....xx Comment

  • 静态限制 principals
    在sshd服务器上，创建 principals 目录 mkdir /etc/ssh/principals。此目录权限mode要求是0755。
    然后在 /etc/ssh/sshd_config 中再加入一行，重启 sshd 服务。
    AuthorizedPrincipalsFile /etc/ssh/principals/%u 。
    之后再次修改 user_ca_list.pub 和 /etc/ssh/principals/ 中的文件，无需重启sshd即生效。

    • AuthorizedPrincipalsFile，只能配置一个路径，不支持多个路径。
    • 根据不同的用户名, 限制 principals, 比如 /etc/ssh/principals/root 文件:
      一行一个 principal。文件权限mode必须是0644。

      ## 注释:/etc/ssh/principals/root文件内容principl_01principl_02

    • 用户证书包含任意一个 principal 才能登录。这种情况不匹配用户名，用户证书的principals包含”用户名”无用。
    • 如果对应用户的文件不存在或为空，用户证书无论包含什么princpals,或者无principal,都不能登录。

  • 动态限制 principals
    在sshd服务器上， /etc/ssh/sshd_config 中再加入两行:
    AuthorizedPrincipalsCommand /etc/ssh/princ.sh %u %U %s %i ,
    AuthorizedPrincipalsCommandUser root , (或指定一个别的用户身份)
    重启 sshd 服务生效, service sshd restart。

    #!/bin/sh# 例子 /etc/ssh/princ.sh 文件, 权限mode是 0755，owner,group 都是 root# 传入四个参数 $1=username，$2=user ID, $3=证书的serial num, $4=证书的key ID# 例子中, $3 $4 没有使用# 因 OpenSSH 权限提升漏洞 (CVE-2021-41617), 此程序只能由管理员编写，不应该开放给用户修改。host=myhost02buf="$host-$1"buf2=$(echo "$buf" |/bin/shasum -)buf2=${buf2%% *-}echo "$buf2"if [ "$2" -eq 0 ]; then   echo "$host-root"   echo "allhost-root"else   echo "$buf"   echo "allhost-user"fi

  • AuthorizedPrincipalsCommandUser abc 指定程序以 abc 用户身份执行。
    可以接受 “%u” 表示以登录的身份执行, 但不建议。

  • 另一个例子，也可以通过webserver查询principals。
    AuthorizedPrincipalsCommand /bin/curl -s http://localhost/sshprincipals?user=%u&serial=%s&id=%i

  • 任何用户登录，使用的用户证书，签名的CA在TrustedUserCAKeys列表中，
    sshd 都会先检查 AuthorizedPrincipalsFile 中的 principals，
    如果找不到，才会执行 AuthorizedPrincipalsCommand 程序。
    如果程序的输出中，也没有找到匹配的 principals，则认证失败。

  • 任何用户登录，使用的用户证书，签名的CA不在TrustedUserCAKeys列表中，
    sshd不使用AuthorizedPrincipalsFile,AuthorizedPrincipalsCommand中的principals。

  • 用户证书的签名CA通过TrustedUserCAKeys认证的，都必须有principals。
    无principals的用户证书，不能登录。即使sshd服务端的principals为空，也不能登录。

  • 有AuthorizedPrincipalsFile或AuthorizedPrincipalsCommand配置时,
    这种情况不匹配用户名，用户证书的principals包含”用户名”无用。

• 只要是用这个密钥(用户CA)签名过的用户公钥，满足 principals 要求，就能登录此sshd服务器的相应用户。

• 创建用户密钥。用户自己创建，私钥不传递。
  ssh-keygen -t ed25519 -C user@myhost -f users_key
  得到两个文件，users_key , users_key.pub。

• 用 user_ca (私钥)对用户密钥的公钥签名，得到一个用户证书。
  只把用户公钥发给管理员签名即可。只须要有”users_key.pub”公钥文件，无需用户的私钥文件。
  ssh-keygen -s user_ca -I ident -n user1,principal_02 -V -10m:+90d users_key.pub
  得到一个文件 users_key-cert.pub，发回给用户。
  -n user1,principal_02 限制证书的用户名 或principals。不限制就去掉这个参数。
  -V -1m:+10d 限制证书的时效。不限制就去掉这个参数。
  -O source-address=192.168.123.0/24,10.1.2.3 限制来源IP。
  -O force-command="date" 强制只执行某个命令。

• 查看已经签名的用户证书的内容。
  ssh-keygen -L -f users_key-cert.pub。

• 在ssh客户端上，
  把两个文件放在一起 users_key , users_key-cert.pub。这个文件没用 users_key.pub。
  用命令 ssh user1@sshd服务器 -i users_key 就能够登录了。

• 创建或更新 KRL 文件。然后把 KRL 文件传到sshd服务器上。或者直接在sshd服务器上创建或更新。
  创建 revoke 文件,并把证书加入: ssh-keygen -k -f KRL_file key-cert.pub。
  更新 revoke 文件,并把公钥加入: ssh-keygen -ku -f KRL_file key.pub。
  更新 revoke 文件,并把CA公钥加入: ssh-keygen -ku -f KRL_file user_ca.pub。
  不仅能吊销ca签名证书，也可以吊销普通密钥的公钥。

• 列出 KRL 文件内容: ssh-keygen -Ql -f KRL_file。
  测试 key-cert.pub 是否被 revoked : ssh-keygen -Q -f KRL_file key-cert.pub。

• KRL 文件也可以是纯文本的，不用 ssh-keygen 生成，格式同/etc/ssh/user_ca_list.pub,一行一个公钥。
  例如: ssh-ed25519 AAAAC.....xx Comment
  可以是CA公钥 user_ca.pub，也可以是普通密钥的公钥，也可以是用户证书users_key-cert.pub的内容。

• 让sshd服务器检查 KRL 文件。(KRL文件,纯文本或者二进制格式,都支持)
  在sshd服务器上, /etc/ssh/sshd_config 中加入一行 RevokedKeys /path_to/KRL_file ,
  重启 sshd 服务生效, service sshd restart。
  /path_to/KRL_file 文件的权限mode可以是 0600 或 0644。
  之后再次修改 KRL 文件，无需重启sshd。

• sshd服务器会最先检查 KRL 文件。
  即，会吊销在 TrustedUserCAKeys,AuthorizedKeysFile,AuthorizedKeysCommand中的公钥。

• 区别:

  • 用户证书认证, 可以限制登录用户名 或principals, 可以设置有效期, 可以限制来源IP。
  • 密钥认证, 无这些功能。

公钥的动态认证

• 在sshd服务器上， /etc/ssh/sshd_config 中加入两行:
  AuthorizedKeysCommandUser /etc/ssh/keys.sh %u %U
AuthorizedKeysCommandUser root , (或指定一个别的用户身份)
  重启 sshd 服务生效, service sshd restart。

  #!/bin/sh# 例子 /etc/ssh/keys.sh 文件, 权限mode是 0755，owner,group 都是 root# 传入两个参数 $1=username，$2=user ID# 例子中, $1 $2 没有使用# 因 OpenSSH 权限提升漏洞 (CVE-2021-41617), 此程序只能由管理员编写，不应该开放给用户修改。echo "ssh-ed25519 AAAAC.....xx Comment"   # 普通密钥的公钥echo "cert-authority ssh-ed25519 AAAAC.....xx Comment"   # CA的公钥,无principals限制# CA的公钥, 有principals限制echo 'cert-authority,principals="host02,allhost" ssh-ed25519 AAAAC.....xx Comment'

• AuthorizedKeysCommandUser abc 指定程序以 abc 用户身份执行。
  可以接受 “%u” 表示以登录的身份执行, 但不建议。
• 任何用户登录，sshd 都会先检查 AuthorizedKeysFile 中的公钥，
  如果找不到，才会执行 AuthorizedKeysCommand 程序。
  如果程序的输出中，也没有找到匹配的公钥，则继续其他认证，如TrustedUserCAKeys。
• 任何用户登录，使用的用户证书，签名的CA在AuthorizedKeysFile或AuthorizedKeysCommand中找到，
  是否有principals限制看匹配行的principals="" 。
  在AuthorizedPrincipalsFile,AuthorizedPrincipalsCommand的cert-authority...匹配行中，
  • 如果无principals= 则用户证书无principals可以登录，或者用户证书有principals，且包含用户名 才能登录。
  • 如果有principals="xx02,xx03" 则用户证书有principals，且包含任意一个principal 才能登录。

ssh登录过程中，基于签名(证书)的服务器认证

• 基于 openSSH-8.0p1 , 测试成功。
• 创建 用于签发服务器证书的密钥(服务器CA)。管理员创建，私钥不传递。
  ssh-keygen -t ed25519 -C server_ca@myCA -f server_ca。
  得到两个文件，server_ca , server_ca.pub。
  只是密钥对，不是证书。因为没做自签名证书。
• 让ssh客户端信任”服务器CA”的公钥。(用户级)
  在ssh客户端上, 用户的 ~/.ssh/known_hosts 中加入一行(服务器CA的公钥)。此文件权限mode通常是0644。
  @cert-authority * ssh-ed25519 AAAAC.....xx server_ca@myCA
  内容为 server_ca.pub 文件的内容。
• 让ssh客户端信任”服务器CA”的公钥。(全局)
  在ssh客户端上，/etc/ssh/ssh_known_hosts 中加入一行(服务器CA的公钥)。此文件权限mode是0644。
  @cert-authority * ssh-ed25519 AAAAC.....xx server_ca@myCA
  内容为 server_ca.pub 文件的内容。
• 只要是这个密钥(服务器CA)签名过的服务器公钥，配置到sshd服务器之后。ssh连接服务器时，就不会有连接警告。
• 用 server_ca (私钥)对服务器的公钥签名，得到服务器证书。
  直接在sshd服务器上签名，或者把服务器的三个公钥发给管理员签名。
  对于openSSH-8，是这三个ssh_host_ecdsa_key.pub,ssh_host_ed25519_key.pub,ssh_host_rsa_key.pub。
  比如,签其中一个: ssh-keygen -s server_ca -I ident -h /etc/ssh/ssh_host_ed25519_key.pub
  得到一个文件 ssh_host_ed25519_key-cert.pub。
  别忘了 -h 参数，漏了就无效了。
  可以带上 -V -1m:forever -n "*.myhost.cn,*.xxx.com"
-n abc.mydomain.com 限制证书的域名,IP。不限制就去掉这个参数。
  -V -1m:+3d 限制证书的时效。不限制就去掉这个参数。
  可以对多个不同类型的公钥签名，得到不同类型的服务器证书。
  sshd服务器原本使用的密钥，不满意，可以在sshd服务器上重新生成一遍。保证服务器私钥不传递。见下面【更新sshd服务端的通讯密钥/证书】部分。
• 查看已经签名的服务器证书的内容。
  ssh-keygen -L -f ssh_host_ed25519_key-cert.pub。
• 在sshd服务器上，修改 /etc/ssh/sshd_config 加三行，
  HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
  如果只签一个类型的服务器证书，HostCertificate /etc/ssh/.... 就只写一行吧。
  重启 sshd，执行 /sbin/service sshd reload。
• 在ssh客户端上，用命令 ssh user1@sshd服务器 就没有连接警告了。
• 让ssh客户端 revoked 服务器的公钥。(用户级)
  在ssh客户端上，用户的 ~/.ssh/known_hosts 中加入一行的公钥。
  @revoked * ssh-ed25519 AAAAC.....xx server_ca@myCA
  内容可以是CA公钥 server_ca.pub，也可以是普通服务器的公钥，也可以是服务器证书ssh_host_ed25519_key-cert.pub的内容。
• 让ssh客户端 revoked 服务器的公钥。(全局)
  在ssh客户端上，/etc/ssh/ssh_config 中加入 RevokedHostKeys /path_to/KRL_file，
  /path_to/KRL_file文件权限mode是0644。
  KRL文件格式，可以是纯文本，一行一个公钥。也可以是由ssh-keygen生成的二进制格式。
  ssh-keygen 创建 KRL 文件，见前面【基于签名(证书)的用户认证】部分。
• 让ssh客户端 revoked 服务器的公钥。(全局)
  在ssh客户端上，/etc/ssh/ssh_known_hosts 中加入一行，也可以。此文件权限mode是0644。
  @revoked * ssh-ed25519 AAAAC.....xx server_ca@myCA

更新 sshd 服务端的通讯密钥/证书，保证服务器安全

• 目前的 OpenSSH-8 需要三套密钥，一共六个文件。

  cd /etc/ssh/ssh-keygen -l -f ssh_host_rsa_key  #看一下,原来密钥的注释是什么。然后决定下面的 -C 参数写什么ssh-keygen -t ecdsa -b 384 -C root@你的机器名 -f ssh_host_ecdsa_keyssh-keygen -t ed25519 -C root@你的机器名 -f ssh_host_ed25519_keyssh-keygen -t rsa -b 4096 -C root@你的机器名 -f ssh_host_rsa_keyservice sshd restart   #重启sshd服务

• 其中，
  ecdsa默认是256bit，可以用 -b 指定，
  ed25519固定是256bit，不能改，
  rsa默认已经从2048改为3072bit了，可以用 -b 指定。
• 还有个简单的办法。
  删除所有的服务器密钥 rm /etc/ssh/ssh_host_* , 重新用默认值生成一遍 ssh-keygen -A。
  重启sshd服务 service sshd restart。
• 参考【更换ssh通信证书,ssh更改公钥和密钥，以保证服务器安全】
  【更换ssh通信证书,ssh更改公钥和密钥，以保证服务器安全】

—end—

转载注明来源: 本文链接 https://www.cnblogs.com/osnosn/p/16870594.html 来自osnosn的博客.