密码安全：如何强化 TLS 和 SSH
加密和安全通信对于我们在互联网上的生活至关重要。如果没有身份验证和保密的能力，我们就无法进行商业活动，也无法信任朋友和同事的话语。
令人惊讶的是，近年来对强加密的关注不足，我们许多“安全”协议都容易被破解。最近的 Heartbleed、POODLE、CRIME 和 BEAST 漏洞使我们对网络和彼此的信任面临风险。
这里汇集了关闭已知漏洞并加强通信安全的最佳实践方法。这些建议绝不是关于此主题的最终定论——这里的目标是强调持续的最佳实践。
请注意，许多政府和司法管辖区已宣布加密为非法，即使在允许的情况下，执法部门也对日益不透明的内容变得越来越绝望（请参阅资源部分中有关这些主题的文章）。确保这些技术及其保护的内容均未公然违法。
本文重点介绍 Oracle Linux 版本 5、6 和 7 以及近亲版本（Red Hat、CentOS 和 Scientific Linux）。从现在开始，我将这些平台简称为 V5、V6 和 V7。Oracle 的 V7 仅在 x86_64 平台上运行，因此这是本文的主要关注点。
尽管供应商不断发布补丁，但这些产品理所当然地可以被认为是存在缺陷的。库设计者可能会辩称他们的职责是实现机制，而不是策略，但由此产生的产品仍然存在严重缺陷。以下是如何修复它们。
TLS 中的强密码传输层安全 (TLS) 协议源于 Netscape 浏览器和服务器软件中较早的安全套接字层 (SSL)。
SSL 不得在任何安全通信的场合中使用，这应该不足为奇。SSLv3 的最后一个版本已被最近的 POODLE 漏洞完全破坏。任何版本的 SSL 对于任何类型的安全通信都是不安全的——该协议的设计存在致命缺陷，并且它的任何实现都无法保证安全。
TLS 1.0 版本也不再安全。安全通信的首选是现代 TLS 1.2 协议，但不幸的是，该协议尚未（还）被广泛使用。尽管缺乏普及性，但如果您重视安全性，请优先选择 1.2。
然而，即使使用 TLS 1.2 版本，仍然存在许多重要的弱点，必须加以解决才能满足 RFC 7525 中指定的当前最佳实践
-
“实现绝不能协商 RC4 密码套件。” RC4 密码在许多 TLS 版本中默认启用，必须显式禁用。RFC 7465 先前已解决此特定问题。
-
“实现绝不能协商提供低于 112 位安全性的密码套件，包括所谓的‘出口级’加密（提供 40 或 56 位安全性）。” 在 SSL 时代，美国政府强迫在出售或赠送给外国国民的加密产品中使用弱密码。创建这些弱“出口”密码是为了容易被破解（在资源充足的情况下）。它们应该早已被删除，但最近已被用于针对 TLS 的新漏洞中。
-
“实现绝不能协商 SSL 版本 3。” 这正式表达了我们对整个 SSL 套件的反感。
-
“实现不应协商 TLS 版本 1.0（或）1.1。” 尽可能首选 TLS 1.2。
TLS 协议有多种实现，Oracle Linux 系统默认安装了三个相互竞争的库：OpenSSL、NSS 和 GnuTLS。所有这些库都可以为 Apache 提供 HTTPS 的 TLS。有人断言 GnuTLS 的代码质量低下，并且对于二进制数据不安全，因此在关键应用程序中应特别注意此特定库。本文仅关注 OpenSSL，因为它是使用最广泛的库。
对于 OpenSSL 下的 TLS 密码强化，我转向 Hynek Schlawack 关于该主题的网站。他列出了 Apache Web 服务器 SSL 配置的以下选项
SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+
↪AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:
↪RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
此配置侧重于高级加密标准 (AES)——也称为 Rijndael 密码（以密码的创始人命名），并使用 3DES 作为旧浏览器的后备方案。请注意，3DES 通常被认为提供 80 位安全性，并且速度也很慢。这些特性不符合上述标准，但我们允许传统的 数据加密标准（三重 DES）密码继续为旧浏览器提供访问。
在较旧的 V5 系统上（OpenSSL 中未实现 TLS 1.1 或 1.2），可接受的密码列表相对较短
$ cat /etc/oracle-release /etc/redhat-release
Oracle Linux Server release 5.11
Red Hat Enterprise Linux Server release 5.11 (Tikanga)
$ openssl ciphers -v
'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+
↪AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:
↪RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS'
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
请注意，TLS 1.1 版本引入了针对 CBC 漏洞的新防御措施。CBC 在上面仅与 3DES 密码一起使用，这引起了人们对在 TLS 1.0 版本中使用 3DES 的质疑。如果您的安全顾虑非常严重，则可能需要删除 3DES 和/或强制执行 TLS 1.1 的最低协议，但这将对与旧浏览器的兼容性产生不利影响。在 OpenSSL 0.9.8e 上禁止 CBC 将使您几乎没有可用的密码。
在 V7 上，允许的密码列表要长得多
$ cat /etc/oracle-release /etc/redhat-release
Oracle Linux Server release 7.1
Red Hat Enterprise Linux Server release 7.1 (Maipo)
$ openssl ciphers -v
'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+
↪AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:
↪RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS'
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA
↪Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
↪Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH
↪Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA
↪Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA
↪Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
↪Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH
↪Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA
↪Au=ECDH Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA
↪Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA
↪Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA
↪Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
↪Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA
↪Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA
↪Enc=AES(256) Mac=SHA1
ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH
↪Enc=AES(256) Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA
↪Au=ECDH Enc=AES(256) Mac=SHA384
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH
↪Enc=AES(256) Mac=SHA1
ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH
↪Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA
↪Enc=AES(256) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA
↪Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA
↪Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH
↪Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA
↪Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA
↪Enc=AES(128) Mac=SHA1
ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA
↪Au=ECDH Enc=AES(128) Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA
↪Au=ECDH Enc=AES(128) Mac=SHA256
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH
↪Enc=AES(128) Mac=SHA1
ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA
↪Au=ECDH Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA
↪Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA
↪Enc=AES(128) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA
↪Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA
↪Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH
↪Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA
↪Au=ECDH Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA
↪Enc=3DES(168) Mac=SHA1
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA
↪Enc=AESGCM(256) Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA
↪Enc=AESGCM(128) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA
↪Enc=AES(256) Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA
↪Enc=AES(256) Mac=SHA1
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA
↪Enc=AES(128) Mac=SHA256
AES128-SHA SSLv3 Kx=RSA Au=RSA
↪Enc=AES(128) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA
↪Enc=3DES(168) Mac=SHA1
如果您的 Apache 版本允许，还可以发出 SSLCompression Off 指令。由于 CRIME 攻击，不应将压缩与 TLS 一起使用。
如果您遇到 Web 客户端的连接问题，请首先尝试禁用 Cipher Order 指令。自定义 HTTP 客户端可能未完全实现 TLS 协商，这可以通过允许客户端选择密码来解决。
上面的密码选择器还可以防止最近出现的“Logjam”（弱 Diffie-Hellman 素数）安全漏洞的任何利用。如果您的 Apache 版本支持备用 dh-prime 配置，建议您按照以下步骤操作
openssl dhparam -out /home/httpd/conf/dhparams.pem 2048
然后将以下行添加到您的 Apache SSL 配置中
SSLOpenSSLConfCmd DHParameters "/home/httpd/conf/dhparams.pem"
确保您对 dhparams.pem 文件具有适当的权限，并注意 V5 不支持此配置。
将这些配置更改应用于 Apache Web 服务器后，请使用 SSLlabs.com 扫描工具对您的服务器进行评级（请参阅资源）。如果您使用的是使用 OpenSSL 0.9.8e 版本的旧 V5 平台，则分配给您的服务器的等级应为“B”——如果您使用的是更高版本，则最终的安全等级将更高。
每天重启 TLS Web 服务器以进行密钥重新生成也很重要，正如 Apache 更改日志中所述
会话票证创建使用在 Web 服务器启动期间创建并在重启期间重新创建的随机密钥。目前没有其他密钥重新创建机制可用。因此，在不以适当的频率（例如，每天）重启 Web 服务器的情况下使用会话票证会损害完美前向保密性。
此信息鲜为人知，并在安全社区中引起了一些惊讶和沮丧：“您看，事实证明，生成新的 RSA 密钥有点昂贵。因此，现代 Web 服务器不会为每个连接都这样做。实际上，默认情况下，Apache mod_ssl 会在服务器启动时生成一个出口级 RSA 密钥，并会在该服务器的生命周期内简单地重复使用该密钥”（来自 http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html）。
请注意，除了 Apache 之外，Hynek Schlawack 的站点还提供了 nginx 和 HAProxy 的配置说明。其他几个应用程序允许自定义密码规范——我在这里提及的两个是 stunnel 和 sendmail。
stunnel “TLS shim” 允许将明文套接字应用程序透明地包装在 TLS 加密中。在您的 stunnel 配置中，使用上述字符串指定 cipher= 指令，以强制 stunnel 采用最佳实践。此外，在 V7 平台上，提供 fips=no 指令；否则，您将被锁定到 TLS 1 协议，并显示消息 'sslVersion = TLSv1' is required in FIPS mode.
sendmail 传输代理最近收到了完整指定密码的补丁。您可以将以下选项添加到您的 sendmail.cf 中，以强制执行最佳实践密码
O CipherList=ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+
↪AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:
↪RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
↪+SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
↪+SSL_OP_CIPHER_SERVER_PREFERENCE
使用这些设置，您将在邮件日志中看到加密信息
May 12 10:17:58 myhost sendmail[1234]: STARTTLS=client,
↪relay=mymail.linuxjournal.com., version=TLSv1/SSLv3,
↪verify=FAIL, cipher=AES128-SHA, bits=128/128
May 12 10:38:28 myhost sendmail[5678]: STARTTLS=client,
↪relay=mymail.linuxjournal.com., version=TLSv1/SSLv3,
↪verify=FAIL, cipher=AES128-SHA, bits=128/128
verify=FAIL 表示您的密钥未由证书颁发机构签名（对于 SMTP 服务器而言，这并不重要）。加密列为 AES128-SHA。
对于公共邮件服务器，更重要的是对允许的密码更加宽松，以防止 SMTP 会话以明文形式进行。但是，在公司防火墙后面，最好更严格地强制执行强 TLS 密码。
及时应用供应商提供的 TLS 补丁也很重要。最近发现，更高版本的 TLS 直接在 SSLv3 填充函数中使用，违反了标准，导致最新版本容易受到攻击（这对于 NSS 而言比 OpenSSL 更令人担忧）。及时修补是安全 TLS 配置的要求。
我要感谢 Hynek Schlawack 对 TLS 安全的贡献和富有见地的评论。
SSH 中的强密码现在众所周知，（某些）SSH 会话可以被具有足够资源的攻击者解密（可能实时解密）。自协议开发以来，SSH 最佳实践已发生变化，过去相当安全的现在已完全不安全。
SSH 管理员的首要关注点是禁用协议 1，因为它已被彻底破解。尽管供应商不断更新，但旧版本的 Linux 仍然保持这种有缺陷的配置，需要系统管理员手动删除它。通过确保您的 sshd_config 中出现“Protocol 2”，并删除所有对“Protocol 2,1”的引用来完成此操作。也建议从客户端 SSH 应用程序中删除它，以防服务器无法访问或被忽略。
为了进一步强化协议 2 密码，我转向 Stribika SSH 指南。这些规范适用于最新版本的 SSH，并且仅直接适用于 Oracle Linux 7.1。
对于旧版本的 SSH，我转向 Stribika Legacy SSH 指南，其中包含适用于 Oracle Linux 5、6 和 7 的相关配置详细信息。
对于 Oracle Linux 5，只有两个推荐的 sshd_config 更改
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-ripemd160
不幸的是，用于 Win32 的 PuTTY SSH 客户端程序套件与 MACs hmac-ripemd160 设置不兼容，并且在此配置实施后将无法连接到 V5 服务器。由于 PuTTY 已悄然成为企业标准，因此这很可能是一个无法克服的兼容性问题，因此大多数企业部署将仅实施 Cipher 指令。
PuTTY 的 0.58 版本也没有实现强大的 AES-CTR 密码（这些密码似乎是在 0.60 版本中引入的），同样也无法连接到专门使用这些密码的 SSH 服务器。强烈建议您实施 Cipher 指令，因为它会删除 RC4 (arcfour)，这对于现代 SSH 完全不合适。期望企业客户端运行最新版本的 PuTTY 并非不合理，因为新版本非常容易安装。
Oracle Linux 5 作为 Oracle Exadata 架构的 Linux 版本的底层操作系统（备用操作系统为 Solaris）具有特殊的地位。如果您是 Exadata 客户，请与 Oracle 确认，如果您更改受支持的 Exadata 设备上的密码和协议设置，您是否仍将保留供应商支持。
V5 的默认 SSH 密码将被特别严格地修剪
$ man sshd_config | col -b | awk "/Ciphers/,/ClientAlive/"
Ciphers
Specifies the ciphers allowed for protocol version 2.
Multiple ciphers must be comma-separated. The
supported ciphers are 3des-cbc, aes128-cbc, aes192-cbc,
aes256-cbc, aes128-ctr, aes192-ctr, aes256-ctr, arcfour128,
arcfour256, arcfour, blowfish-cbc, and cast128-cbc. The
default is
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
aes256-cbc,arcfour
可以在 V5 上安装较新版本的 OpenSSH，但这并不容易。尝试编译最新版本会导致以下错误
error: OpenSSL >= 0.9.8f required (have "0090802f
↪(OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008)")
可以使用以下命令编译没有 OpenSSL 依赖项的 OpenSSH
--without-openssl Disable use of OpenSSL; use only
↪limited internal crypto **EXPERIMENTAL**
企业部署可能不愿意使用实验性代码，因此我将不再赘述。如果您获得用于升级的二进制 RPM，请确保您知道它们的生成方式。
Oracle Linux 7 缺少最新版本 SSH 中的一些密码，并且仅与推荐设置略有不同
HostKey /etc/ssh/ssh_host_rsa_key
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,
↪aes256-ctr,aes192-ctr,aes128-ctr
KexAlgorithms diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-
↪etm@openssh.com,hmac-ripemd160-etm@openssh.com,
↪umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,
↪hmac-ripemd160,umac-128@openssh.com
Oracle Linux 7.1 可以完全按照建议配置，包括新的 ed25519 主机密钥
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
Ciphers chacha20-poly1305@openssh.com,aes256-
↪gcm@openssh.com,aes128-gcm@openssh.com,
↪aes256-ctr,aes192-ctr,aes128-ctr
KexAlgorithms curve25519-sha256@libssh.org,diffie-
↪hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-
↪etm@openssh.com,hmac-ripemd160-etm@openssh.com,
↪umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-
↪256,hmac-ripemd160,umac-128@openssh.com
Stribika 指南立即驳回了 3DES 密码，这可能是合理的，因为它速度慢且相对较弱，但也花了很多篇幅批评 NIST 和 NSA 的影响。从长远来看，这并非完全公平，因为美国政府对密码学领域的Influence在很大程度上是有益的。引用密码学家 Bruce Schneier 的话，“学术界花了二十年才弄清楚 NSA 的‘调整’实际上提高了 DES 的安全性……DES 比任何其他事物都更能激发密码分析领域的发展。” 尽管最近发生了一些不幸的事件，但现代安全通信在很大程度上要归功于数据加密标准以及参与引入该标准的人员。
Stribika 提出了具体的批评
...建议不要使用 NIST 椭圆曲线，因为它们众所周知难以正确实现。如此之难，以至于我怀疑这是否是故意的。任何简单的实现似乎都可以工作，但会通过侧信道泄漏秘密。禁用它们似乎不会引起问题；客户端要么也具有 Curve25519，要么它们具有足够好的 DH 支持。而且 ECDSA（或常规 DSA）无论使用什么曲线都不是一个好的算法。
在任何情况下，都有技术理由将 3DES 保留在 TLS 中，但从 SSH 中删除它——当浏览器和客户无法访问您时，比您的管理员因软件标准升级而感到不便时，财务成本更高。
如果您将 ssh-agent 与私钥一起使用，则可以使用 Martin Kleppmann 使用 PKCS#8 记录的方法来加强密钥上密码的加密。以下是从作者处总结的步骤
cd ~/.ssh
mv ~/.ssh/id_rsa ~/.ssh/id_rsa.old
openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa.old
↪-out ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa
作者估计，此过程提供了相当于向密码添加两个额外字符的好处。但是，重要的是要注意，PuTTY 代理无法读取此处生成的新格式。如果您将 pagent 与 PuTTY 一起使用（或期望使用），请首先将您的 OpenSSH 密钥转换为 pagent，然后运行此过程，假设允许保留两种格式的密钥。明智的做法是在离线介质上保留原始私钥的副本。同样重要的是要注意，此过程不会增加任何额外的防键盘记录器保护。
用户 SSH 密钥对在许多安全方面可能优于密码。SSH 服务器无法对远程密钥强制执行密码标准（最小密码长度、更改频率、防止重用等），并且转发 ssh-agent 肯定存在风险，这会损害服务器安全性。如果您允许用户使用他们生成的 SSH 密钥对进行身份验证，则应了解它们可能如何被（滥）用。
最后，请注意，击键延迟时间可以用作 SSH 中的侧信道漏洞，通过应用维特比算法。交互式 SSH 会话比大多数人预期的更容易泄露内容，对于那些具有高安全要求的人员应避免使用。发送批量的 ssh 命令，或者如果在需要交互式会话但安全性至关重要的情况下，在同一通道上的辅助会话中实施带宽“模糊器”。尤其值得注意的是
-
“超级用户”命令（即
su -）在加密数据流中创建独特的流量签名，从而泄露目标密码的准确长度以及击键时间。不应通过 SSH 会话使用它。 -
如果用户登录到远程 SSH 主机，然后使用远程主机登录到三主机配置中的另一个主机，这会在加密数据流中创建更独特的流量签名，从而基本上公开任何使用的密码的准确长度。避免这种做法。
-
根据使用的密码，可以在登录时检测到短密码（少于七个字符）。强制执行大于七个字符的最小密码长度，尤其是对于 SSH 会话。
我要感谢 Stribika 对 SSH 安全的贡献和富有见地的评论。
牢不可破的加密虽然上述最佳实践很有帮助，但这些协议在确保私有通信通道方面完全不足，并且已被多次破解。
如果您的安全通信需求如此迫切，以至于任何被拦截的风险都太大，那么您可能应该考虑使用迄今为止似乎尚未被破解的加密工具。
仔细分析最近的证据表明，Gnu Privacy Guard 对 Pretty Good Privacy (PGP) 的实现继续为窃听和未经授权的解密带来不可逾越的困难。
此实用程序默认安装在所有最新版本的 Oracle Linux 中。它应该是您安全通信的首选，您应该意识到上面描述的所有技术都是为了权宜之计而做出的妥协。
资源Heartbleed 漏洞：http://heartbleed.com
Dan Goodin 的“更恶劣的 POODLE 漏洞绕过 TLS 加密，影响 10% 的网站”：http://arstechnica.com/security/2014/12/meaner-poodle-bug-that-bypasses-tls-crypto-bites-10-percent-of-websites
CRIME (“压缩率信息泄露变得容易”)：https://en.wikipedia.org/wiki/CRIME
Omar Santos 的“使用 TLS 1.1/1.2 及更高版本击败 BEAST”：http://blogs.cisco.com/security/beat-the-beast-with-tls
加密法律调查：http://www.cryptolaw.org
Annalee Newitz 的“国土安全部恳求硅谷停止加密”：http://gizmodo.com/dhs-secretary-begs-silicon-valley-to-stop-the-encryptio-1699273657
Bill Shelton 的 NIST 弃用政府使用的 TLS 1.0：http://forums.juniper.net/t5/Security-Now/NIST-Deprecates-TLS-1-0-for-Government-Use/ba-p/242052
RFC 7525—安全使用传输层安全 (TLS) 和数据报传输层安全 (DTLS) 的建议：https://www.rfc-editor.org/rfc/rfc7525.txt
RFC 7465—禁止 RC4 密码套件：http://tools.ietf.org/html/rfc7465
OpenSSL：http://www.openssl.org
GnuTLS 传输层安全库：http://gnutls.org
GnuTLS 被认为有害：http://www.openldap.org/lists/openldap-devel/200802/msg00072.html
强化 Web 服务器的 SSL 密码—Hynek Schlawack：https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers
Logjam 攻击：https://weakdh.org
SSL Labs 扫描工具：https://www.ssllabs.com
Apache 更改日志：https://apache.ac.cn/dist/httpd/CHANGES_2.4
Matthew Green 的“本周攻击：FREAK（或‘为了乐趣和利润而分解 NSA’）”：http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html
“POODLE 再次发威”：https://www.imperialviolet.org/2014/12/08/poodleagain.html
Stribika SSH 指南：https://stribika.github.io/2015/01/04/secure-secure-shell.html
Stribika Legacy SSH 指南：https://github.com/stribika/stribika.github.io/wiki/Secure-Secure-Shell
Bruce Schneier 的“向数据加密遗产致敬”：http://www.cnet.com/news/saluting-the-data-encryption-legacy
Martin Kelppmann 的“提高 SSH 私钥文件的安全性”：http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html
Dawn Xiaodong Song、David Wagner 和 Xuqing Tian 的“击键时序分析和对 SSH 的时序攻击”：http://www.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf
Kelsey Campbell 的“新泄露揭示了 NSA 仍然无法破解的加密工具”：http://gizmodo.com/the-encryption-tools-the-nsa-still-cant-crack-revealed-1675978237
SPIEGEL Staff 的“窥探之眼：深入了解 NSA 对互联网安全发起的战争”：http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html
GNU Privacy Guard：https://gnupg.org
Charles Fisher 拥有爱荷华大学的电气工程学位，并在一家财富 500 强矿业和制造公司担任系统和数据库管理员。
