- A+
http://drops.wooyun.org/tips/1055
0x00 摘要
2010年三月，ssh证书认证悄然地包含到了OpenSSH5.4中。到了2014年，很多人对ssh证书依旧相当模糊，既没有得到广泛的理解，也没有得到广泛的使用。对于这样一个问题，我们可能会认为它实施起来要不是很难，就是很复杂。实际上这样做既不难，也不复杂，只是它没有得到较好的文档化的描述。
本文的目标是以一种实际的方式向各位展示使用和管理ssh证书认证有多容易，无论是较小的还是较大的环境。
本文的创建用于解答笔者日常中遇到的一些ssh证书认证的问题，当然还增添了在学习过程中发现的一些东西。本文内容中也许会有点小差错，某些特性也没有提到，欢迎各位指正。
0x01 基本知识
本文假设你已经了解：
基本的Unix/Linux服务器管理
SSH管理，包括但不限于：
a) 密钥生成
b) SSH公钥认证
c) 使用SSH代理
d) 使用口令加密密钥
基本的安全概念如：
不要直接以root身份登陆
0x02 SSH证书介绍
证书是已有的ssh公钥认证系统的扩展，可被应用于任何已有的公钥和私钥对，也可以用于任何当前ssh支持的认证方法。
尽管(SSH证书认证)基于公钥认证，它同时也被设计来简化多台服务器之间密钥管理的复杂性。证书免除了对已知主机和经授权用户文件的需要，如果实现合理的话，只许更少的人力便能复制全部功能。
由于证书认证是公钥加密的一个扩展，它可以与OPenSSH支持的任意密钥类型和密钥大小的ssh2协同使用。这意味着如果你当前的OpenSSH支持的话，RSA、DSA、EC都能使用。方便起见，本文将使用默认的RSA-1024。
Tips:有些较老的操作系统虽然使用OpenSSH5.4或更高的版本，但是还是不支持EC。
0x03 证书 VS. 公钥
常规的公钥认证和证书认证之间有几点较大的不同，最大的不同就是证书验证上。
与其他公钥证书标准不同
SSH证书相比其他证书格式如x509、SSL中使用的PEM更为简单
a) 没有证书链，只有一个CA
b) 没有可疑的的商业签名授权(authority)
c) 除了CA签名外没有可信模式
主机认证
| 操作 | 公钥认证 | 证书认证 |
|---|---|---|
| 认证未知主机 | 初始登陆时询问用户是否接受主机秘钥 | 验证CA签发的主机证书 |
| 认证已知主机 | 将密钥和用户的已知主机文件对比 | 验证CA签发的主机证书 |
| 替换已知主机的密钥 | a) 入口必须从用户的已知主机文件中删除 b) 用户登录时会被问及是否接受新的主机秘钥 | 验证CA签发的主机证书 |
| 撤销密钥/证书 | [email protected] | [email protected] |
使用证书认证的好处
a) 用户可以认证之前没有登入过的主机
b) 无需再分发或管理已知的已知主机文件(例：puppet)
c) 可以无需用户干预实现服务器替换及密钥再生成
d) 除非什么地方出错了，用户在工作场合再也不会收到接受服务器密钥的提示
e) 通过搜索未签名的主机密钥可以发现不一致的主机
用户认证
| 操作 | 公钥认证 | 证书认证 |
|---|---|---|
| 认证 | 用户的公钥来自每个服务器主机用户经授权的密钥文件 | 检查用户证书是否由CA签名 |
| 过期密钥/证书 | 不做强制 | 过期时间由管理员在签名时设置 |
| 登录用户名 | 服务器上的目标用户的公钥置于每个用户目录下的authorized_keys文件中 | 用户名可在签名时添加到证书中，也可由每个服务器上的AuthorizedPrinciples文件控制 |
| 限制(端口转发、强制命令等) | 可以在authorized_keys文件中(可被用户编辑)，可在每个服务器sshd_config的匹配用户/组块中 | 可在签名时加入证书中，可在每个服务器sshd_config的匹配用户/组块中，可在每个服务器”经授权的规则”中添加 |
| 撤销密钥/证书 | 可添加到每个服务器的RevokedKeys文件中或从服务器上每个受影响的authorized_keys文件移除 | 每个服务器上将证书添加到”RevokedKeys”文件中 |
| 替换用户的证书 | 服务器上authorized_keys文件必须可被编辑 | 将旧证书添加到服务器上已撤销的密钥文件或签名新的证书 |
使用证书认证的好处
a) 证书过期时间可由管理员在签名时设置，强制实施轮转策略
b) 无需跨越多台主机管理已授权的证书
c) 不用担心恶意用户编辑或添加内容到未管理的经授权文件
d) 在签名时更容易限制某些用户的权限
e) 无需从已授权密钥文件中移除已吊销的密钥
f) 证书签名时可以限制用户使用指定的用户名
0x04 让它工作起来
实现ssh证书认证要比SSL证书容易得多，最难的地方是决定签名用户和服务器是使用单个CA密钥还是使用两个CA密钥——服务器和用户各一个
我们推荐使用两个独立的密钥用于签名的用户和服务器，以便让不同的角色来管理每一个功能：例如，一个系统管理员可以登录服务器密钥，而安全管理员可以登录该用户的密钥。
下面的例子中服务器和用户使用各自的证书授权
服务器授权
激活服务器授权仅需4个步骤
1. 创建服务器CA
在你的证书授权服务器上运行下列命令：
#!bash
~ $ # Lets start with good organization
~ $ mkdir -p ssh_cert_authorita/server_ca
~ $ cd ysh_cert_authority/server_ca/
~/ssh_cert_authority/server_ca $ # Now lets generate our server certificate authority keypair
~/ssh_cert_authority/server_ca $ ssh-keygen -f server_ca -C "companyname_server_ca"
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
wour identification has been saved in server_ca.
Your public key has been saved in server_ca.pub.
The key fingerprint is:
21:f6:9f:5d:ec:75:2e:df:c0:6b:5e:9d:5b:97:d8:19 "companyname_server_ca"
~/ssh_cert_authority/server_ca $ # The resulting files
~/ssh_cert_authority/server_ca $ ls -l
total 8
-rw------- 1 username username 1675 Aug 16 14:12 server_ca
-rw-r--r-- 1 username username 409 Aug 16 14:12 server_ca.pub
Tips:强烈建议不仅使用密码，还要使用强密码。任何用这个密钥签名的人都能添加受信任的服务器访问到你的网络。
2. 签名主机密钥
既然证书认证是公钥认证的一个扩展，你可以使用已有的
/etc/ssh/ssh_host*key.pub
ssh主机密钥。举例来说，任何类型的ssh主机密钥都可以。
在你的证书授权服务器上运行如下命令：
#!bash
~/ssh_cert_authority/server_ca $ # 为�