真的，宇宙射线会导致部分 SSH 服务器的私钥泄露
如果你是 OpenSSL、LibreSSL、OpenSSH 的用户，你可以坐下来看看了，因为这不会影响你。最近一项学术研究展示了如下情况：对于某些特定设备，他人可以监听其 SSH 连接，然后借助一些运气在无声无息中破译出主机的私有 RSA 密钥，从而冒充该设备。冒充这些设备后，通过使用推断出的主机密钥私钥实施的中间人攻击，间谍可以安静地记录用户的登录信息，同时，通过将这些连接转发给真正的设备，他们还可以监控用户在远程 SSH 服务器上的活动。尽管 SSH 还有其他功能，但其主要应用场景仍然是用户登录到设备并通过命令行接口进行控制。据悉，可以通过被动监视从客户端到易受攻击设备的 SSH 服务器的连接，获得主机的 RSA 密钥私钥：无论是在签名生成过程中的偶发运算错误，还是因宇宙射线等微小故障产生的自然错误，都可以被观察和利用来推算 SSH 服务器的主机密钥私钥，这本应是保密的。虽然可能认为自然错误发生的概率很小，偶发错误可能已为众所周知，但实际上只要你连续观察足够多的到有漏洞的 SSH 服务器的 SSH 连接，你就有可能发现一个你可以利用的。重要的一点是，软件库 OpenSSL 和 LibreSSL，以及 OpenSSH，都未发现存在上述密钥推导问题的漏洞。由此，我们认为，网上的大部分设备、服务器和其他设备都不会受到影响，只有特定的物联网设备和类似的嵌入式设备可能会对此种攻击敏感。此外，这种问题也仅影响 RSA 密钥。细节由加利福尼亚大学圣地亚哥分校的 Keegan Ryan、Kaiwen He（他同时也在麻省理工学院任职）、George Arnold Sullivan 以及 Nadia Heninger 基于早期的一些研究，完成并撰写了这项研究。他们采用的技术，旨在揭示 RSA 密钥私钥，该技术源于 Florian Weimer 在 2015 年对 TLS 的突破性研究，以及 2022 年圣地亚哥论文的几位作者以及其他研究者的一些工作，这些工作可追溯到 1990 年代。信息安全专家 Thomas Ptacek 曾高度赞扬了 2023 年研究的合著者 Nadia Heninger，并在此分享了 RSA 密钥分析论文的摘要，以便于理解这个问题。我们同时也要感谢曾在 Register vulture 工作的 Dan Goodin，他在周一通过 Ars Technica 向我们报告了 UC 圣地亚哥论文的消息。基本上，当客户端尝试连接到一个容易受到攻击的 SSH 服务器时，它们在协商建立全面安全加密通信的过程中，服务器将会生成一个数字签名以供客户端检查，以确保其正在与预期的服务器通信。如我们之前所述，这个签名的计算过程可能会随机或意外地产生错误，聪明的算法可以从错误的签名中推导出服务器的私有 RSA 密钥，此密钥用于签名生成。对此的一种防范措施是在将签名发送给客户端前确保其计算正确；OpenSSL 和 LibreSSL 已经在实施这种防范。正如论文作者在他们的摘要中提到的：“我们证明了一种可能性：若 SSH 服务器在进行签名计算过程中出现自然故障，一名被动的网络攻击者便有机会获得其私有 RSA 主机密钥。在之前的研究中，我们通常认为这对于 SSH 协议是不可行的，因为签名中包含了一些信息，比如 Diffie-Hellman 共享密钥，这些信息对于被动的网络观察者来说无法获得。然而，我们证明了，在 SSH 中经常使用的签名参数下，如果出现了签名错误，我们便能有效地使用 格攻击 lattice attack 来恢复私钥。我们对 SSH、IKEv1、IKEv2 协议进行了安全分析，在此场景下，我们利用我们的攻击方法在现实环境中挖掘出几个存在漏洞的独立实现中的数百个被攻破的密钥。“一个被动的对手可以安静地监控合法的连接，不用冒被检测的风险，直到他们观察到一个包含私钥的错误签名。”研究团队做出了这样的结论：“然后，攻击者可以主动且不会被检测地冒充被攻破的主机，从而截取敏感数据。”研究人员表示，他们已经扫描了整个互联网，并翻查了以前收集的 SSH 扫描数据，以测量易受攻击的签名的流行程度。他们声称，他们的数据集涵盖了 52 亿条 SSH 记录和超过七年的观察，其中包含了超过 59 万个无效的 RSA 签名。通过他们的格密钥恢复技术，学者们表示，其中超过 4900 个错误的签名揭示了对应 RSA 公钥的因子分解。他们利用这些信息，推导出了 189 个公钥的私有 RSA 密钥。在他们的研究中，作者们发现，思科、Zyxel、山石网科和 Mocana 这四个制造商的产品都可能受到这种密钥侦测攻击。研究者已经向思科和 Zyxel 报告了这个问题，观察到两家供应商都迅速进行了调查行动。思科判定其 ASA 和 FTD 软件在 2022 年已经解决了此问题，且在这篇论文发布之前，公司正在对其 IOS 和 IOS XE 软件进行调查，看看如何应对此问题。同一时间，Zyxel 发现这个缺陷只影响到了它那些已停止服务的固件，并且它已经开始使用不受此问题影响的 OpenSSL。研究人员表示，他们没有成功地与山石网科和 Mocana 取得联系，所以决定把这个问题提交给了 CERT 协调中心。据称，自诩为 “SSH-2.0-SSHD” 的 SSH 服务器实现也可能受到攻击，这可能会影响到一些企业级的 Java 应用。有鉴于这个密钥推导技术的关键在于 PKCSv1.5，使用 PKCSv1.5-RSA 签名的 DNSSEC 可能也在风险之中。他们还指出，他们在 IPsec 连接中收集到的签名数据集不大，所以无法确定此协议是否也可能受到类似的密钥泄漏攻击。他们表示：“鉴于易受攻击的签名故障很罕见，根据我们的数据，我们无法对 IPsec 实现得出多少结论，我们认为这个问题值得进一步研究。”更新：已经与山石网科取得联系，官方确认该问题已在 2015 年发布的相关版本中修复，之后的版本也不存在相关问题。具体详情可以咨询山石网科客服或查看如下链接： https://www.hillstonenet.com.cn/security-notification/2015/07/28/dsfyj/（题图：MJ/f94093f0-9ffe-4cf1-82fb-cdac1427e923）via: https://www.theregister.com/2023/11/14/passive_ssh_key_compromise/作者：Jessica Lyons Hardcastle 译者：ChatGPT 校对：wxy
硬核观察 #1185 宇宙射线可以导致 SSH 私钥被窃取
宇宙射线可以导致 SSH 私钥被窃取研究人员发现，可以观察到 SSH 签名生成过程中意外或自然发生的计算错误，并利用这些错误来计算 SSH 服务器的本应保密的密钥私钥。所谓自然发生的错误，指的是宇宙射线和其他会翻转比特的小故障造成的错误；而所谓意外发生的错误，指的是 RSA 签名生成算法执行不力。如果你监控了足够多的到易受攻击的 SSH 服务器的连接，你最终会发现一个可以利用的漏洞。研究人员检查了过去七年扫描互联网收集的 10 亿个使用了 RSA 算法的签名。在这些签名中，有百万分之一的主机私钥会被暴露。消息来源：The Register老王点评：所以，加密算法还得防着宇宙射线的攻击。苹果公司拿走了 1/3 的 Safari 上的谷歌搜索广告收入谷歌和苹果公司早在 2002 年就建立了合作关系，谷歌成为苹果 Safari 浏览器的默认搜索引擎，过去几年谷歌每年为此向苹果支付了数十亿美元。在诉谷歌反垄断案审判中，谷歌的经济学家在法庭上意外披露了用户通过 Safari 浏览器使用谷歌搜索产生的广告收入，其中 36% 会支付给苹果公司。谷歌和苹果公司都曾反对公开披露双方协议的细节。消息来源：彭博社老王点评：好家伙，浏览器可真是个摇钱树啊。谷歌起诉涉嫌发布植入恶意软件的山寨版 Bard 的骗子谷歌起诉称，越南的一些人一直在建立社交媒体页面并发布广告，鼓励用户下载一个 “Bard”，但这个版本的 “Bard” 并不能提供如何烹饪意大利烩饭之类的有用答案。一旦某个傻瓜下载了这个 “Bard”，它就会侵入系统并窃取密码和社交媒体凭证。诉讼指出，这些骗子特别将 Facebook 作为他们的首选传播方式。消息来源：Engadget老王点评：这是把免费服务当成恶意软件的载体了，不过我觉得比起来今天圈内将开源 LLaMA “改成” 自己的开源大模型的大瓜，也算不了什么。
FIDO U2F 安全密钥是一种小型的基于 USB/NFC 的设备。它是一种硬件安全令牌，具有多个安全相关的用途模块。FIDO U2F 标准兼容的密钥品牌有多种，包括 NitroKey、SoloKey v2 和 YubiKey。与类似 Yubico OTP 的专有协议相比，FIDO 协议是不依赖特定硬件令牌的，并且使用的工具也不依赖特定制造商。本文介绍了 FIDO 协议，并展示了如何安装和启用 FIDO U2F 安全密钥作为替代身份验证因素，以用于登录终端、GDM 或进行 sudo 认证。对于 YubiKey，特别是其不支持 FIDO2/U2F 的旧版设备，请参阅之前的文章：如何在 Fedora Linux 上使用 YubiKey本文不涵盖存储 OpenPGP 密钥或 X.509 证书的操作，因为这些功能与硬件相关，不属于 FIDO U2F 标准的一部分。保留备用安全密钥一旦你开始使用安全令牌，就必须考虑到自己可能会被锁定在与这些令牌相关联的账户之外的情况。由于硬件安全令牌是独特的，并且被设计为非常难以复制，你不能像在使用 KeePass 或 AndOTP 等软件保险库时那样制作备份。因此，你使用主要密钥进行的所有注册都应立即使用第二个备份密钥重复进行，并将其存储在安全的位置，甚至可能是保险箱中。在实践中，这意味着你需要将两个硬件令牌注册到你的 Linux 和 Web 账户中，并生成两份 OpenSSH 私钥，并将这两份 OpenSSH 公钥上传到你使用的服务器和服务（例如 GitHub）中。如果你丢失了一个密钥，你将需要使用第二个密钥登录与密钥注册的每个服务，删除丢失的密钥，并注册一个新密钥。对于使用 FIDO2 协议的无密码登录尤其如此。FIDO2、U2F 和 FIDO 联盟FIDO2 是由 FIDO 联盟 维护的一系列标准。FIDO 联盟希望最终完全摒弃密码，并提供通过多个因素安全验证用户身份的过程，而无需使用密码。该标准包括万维网联盟（W3C）的 网页认证 Web Authentication （WebAuthn）和 FIDO 联盟的 客户端到认证器协议 Client-to-Authenticator Protocol （CTAP）。WebAuthn 是一种用于请求和处理公钥挑战进行认证的标准 API。通过这个标准，浏览器会向客户端发送一个 挑战 challenge ，然后客户端使用私钥生成一个 响应 response ，挑战者再使用之前交换的公钥进行验证。如何生成挑战答案对于服务来说是不可知的，而是由 CTAP 控制。用户可能会被要求使用多种验证方法，如生物识别、PIN 或存在性检查（或这些方法的组合）。这些验证方式在认证时与注册密钥时的方式相同。为了保护与硬件令牌的任何交互，可以选择设置一个访问 PIN，并且默认情况下未设置。大多数密钥在连续八次输入访问 PIN 失败后将自动失效。恢复失效的密钥并设置新 PIN 的唯一方法是重置密钥。然而，当密钥重置时，所有其服务注册将丢失！FIDO2 密钥还支持 FIDO U2F 协议（现已更名为 CTAP1）。该协议旨在提供第二或多因素（但非无密码）认证。Linux 的 PAM 认证系统也可以配置为使用 U2F 协议。虽然 FIDO U2F 不是为无密码认证设计的，但 U2F PAM 模块允许无密码认证。安全影响FIDO2 / U2F 通过将安全密钥与用户账户绑定来工作。大多数密钥默认启用/使用基本的存在性检查。它们通常通过点亮并提示你触摸密钥来进行存在性检查。FIDO2 PIN 是可选的，默认情况下未设置。当密钥用于登录 Linux 帐户或用于使用 sudo 时，只需确保设备和密钥物理上存在即可。FIDO2 PIN 是一个重要的附加验证步骤，用于确保只有你才能使用密钥进行身份验证。等一下！现在我还要记住额外的 PIN 吗？这不就是一个更短的密码吗？—— 担心的读者FIDO2 PIN 不是密码，它是一个简短、容易记住的短语。这并不是一个问题，因为：你需要物理访问密钥 且 需要知道 PIN。输入 PIN 错误达到八次会使密钥失效，这使得暴力破解变得困难。相反地，现在你可以使用存储在密码管理器中的安全密码，而无需记住它。谷歌在 2016 年进行的一项案例研究，题为 《安全密钥：现代网络的实用密码学第二因素》，显示了安全密钥有效地保护用户免受密码重用、钓鱼和中间人攻击的影响。使用 PAM 进行用户认证本地系统认证使用 可插拔认证模块（PAM）。U2F 设备的 PAM 模块（因此进行认证）是 pam_u2f。你的密钥是否支持 FIDO2 或 FIDO U2F 取决于其固件版本和硬件型号。设置如下：安装 PAM 模块。将密钥注册到你的用户账户上。使用 authselect 在 PAM 中激活智能卡支持。authselect 是一个用于配置带有可重现配置文件的 PAM 的工具。使用 authselect 的配置文件可以避免手动修改 /etc/pam.d 目录下的配置文件。依赖项所需的软件包可在官方仓库中获取。[…]$ sudo dnf install pam-u2f pamu2fcfg fido2-tools 在密钥上设置 FIDO2 PINFIDO2 标准定义了一种用于访问保护的可选 PIN。如果 PIN 丢失或失效，没有 PUK 或其他恢复方式，请确保你有一种备用的身份验证方法。如果通过连续输入无效的 PIN 使 PIN 失效，恢复的唯一方法是重置密钥。然而，重置密钥会删除其所有凭据，并将其与以前注册的所有服务断开连接。fido2-tools 包含一个用于设置密钥的 FIDO2 PIN 的工具： fido2-token。使用 fido2-token -L 获取当前连接的 FIDO2 设备列表，并使用 fido2-token -C </path/to/device> 设置一个新的 PIN：[…]$ fido2-token -L /dev/hidraw1: vendor=0x1050, product=0x0407 (Yubico YubiKey OTP+FIDO+CCID) […]$ fido2-token -C /dev/hidraw1 Enter current PIN for /dev/hidraw1: Enter new PIN for /dev/hidraw1: 将安全密钥注册到本地账户使用工具 pamu2fcfg 检索一个配置行，该行将放入 ~/.config/Yubico/u2f_keys 中。pam_u2f 是由 Yubico 提供的通用 U2F 密钥模块，因此使用 Yubico 特定的默认配置路径。该文件中的每个配置行由用户名和密钥特定的凭据/配置部分以冒号分隔。确保每个用户仅使用一行。fedora-user:owBYtPIH2yzjlSQaRrVcxB...Pg==,es256,+presence+pin[:该用户另外的密钥] 如果密钥受 PIN 保护，你将被要求输入 PIN 来进行此操作。对于第一个密钥的初始注册，请使用以下命令：[…]$ mkdir -p ~/.config/Yubico […]$ pamu2fcfg --pin-verification > ~/.config/Yubico/u2f_keys 要将另一个密钥（例如备份密钥）添加到此单用户配置中，请使用以下命令：[…]$ pamu2fcfg --nouser --pin-verification >> ~/.config/Yubico/u2f_keys pam_u2f 还支持使用一个中心身份验证文件。在这种情况下，请确保每个用户使用一行，并将给定用户的所有密钥保持在同一行上。如果两行引用相同的用户名，那么只有最后一行将被使用！请参阅 pam\_u2f 手册页 获取所有可用选项的详细信息。使用 authselect 配置 PAMauthselect 是一个用于控制系统 PAM 配置的工具。它引入了配置文件作为额外的抽象层。一个 authselect 配置文件可以更改多个 PAM 配置文件。配置文件具有控制附加功能和行为的参数，例如启用 FIDO U2F 安全密钥。有关 authselect 的详细介绍计划在未来的文章中进行。显示当前活动的 authselect 配置文件。如果选择了 SSSD（系统安全服务守护程序）配置文件并启用了 U2F 支持，则输出可能类似于以下内容：[…]$ authselect current Profile ID: sssd Enabled features: - with-pam-u2f 使用 authselect 和 with-pam-u2f 标志，在 PAM 中激活 FIDO U2F 支持：[…]$ sudo authselect select sssd with-pam-u2f 如果你还想使用指纹读取器，必须同时启用这两个功能：[…]$ sudo authselect select sssd with-pam-u2f with-fingerprint 这会在 PAM 中激活具有 pam_u2f 和指纹读取器支持的 SSSD 配置文件。例如，当使用上述 authselect 配置文件在终端上使用 sudo 时，首先会要求你提供指纹，如果指纹识别失败，则使用 U2F 密钥。然而，GDM 将首先使用 U2F 密钥。解锁 GNOME 钥匙环守护程序当使用生物识别、U2F 密钥或任何其他不需要密码短语登录 GNOME 的方法时，无法自动解锁“登录”钥匙环。这是因为，默认情况下，钥匙环的密码短语设置为与你的登录密码短语相同。通常，PAM 将你的登录密码短语传递给钥匙环守护程序。由于你在通过生物识别或 U2F 密钥进行身份验证时不需要输入密码短语，因此 PAM 没有密码短语可以传递给钥匙环守护程序。这个问题没有简单直接的解决方法。如果你为家目录使用 LUKS 加密并且操作的是单用户系统，你可以从钥匙环中移除密码短语。这将使你的 GNOME 钥匙环在文件级别上保持未加密。但它仍然在块级别上由 LUKS 加密，因为 LUKS 加密与单用户系统上的默认基于文件的钥匙环加密等效。由于钥匙环的加密仅旨在保护其内容免受离线访问，钥匙环在登录后将被解密/解锁，任何运行时应用程序或恶意软件在解锁后都有可能访问钥匙环的内容。由于 LUKS 也是一种离线保护机制，因此可以认为它是钥匙环正常基于文件的加密的替代选择。如果你的系统被多个用户使用，则 LUKS 加密和钥匙环的正常基于文件的加密不是等效的。在具有只由 LUKS 保护的钥匙环的多用户系统中，具有解密磁盘和引导系统授权的任何用户都能够访问同一系统上的任何其他用户的钥匙环。移除 GNOME “登录”钥匙环密码短语非常简单。只需设置一个新的空密码，钥匙环将被解锁，并且其内容将以未加密的方式存储在文件级别上。可以使用图形实用程序 Seahorse（也称为“密码和密钥”）来在 GNOME “登录”钥匙环上设置一个空密码。警惕和其他用例即将发布的文章将探讨如何使用 U2F Dracut 插件使用 FIDO2/U2F 密钥解锁 LUKS 加密的磁盘。OpenSSH 8.2+ 支持使用 ed25519-sk 安全密钥。这个主题已经在之前的文章《如何在 Fedora Linux 上使用 YubiKey》中涉及到。需要注意的是，FIDO2/U2F 是一种认证标准。还有其他用于安全令牌的用例（主要由 Yubico 建立），例如 (T)OTP、PIV（用于 x509 密钥管理）或 OpenPGP，这些用例不是一般性的，而是具体硬件上的用例。（题图：MJ/4bd195dc-130b-4ef2-af6c-9a6ef5d54223）via: https://fedoramagazine.org/use-fido-u2f-security-keys-with-fedora-linux/作者：Alexander Wellbrock 选题：lujun9972 译者：ChatGPT 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
硬核观察 #737 现代公司的电动汽车在其车载系统使用教程上的示例密钥
现代公司的电动汽车在其车载系统使用教程上的示例密钥一位开发者发帖称，他想要修改汽车上的车载信息娱乐系统，他的汽车是现代公司 2021 款的“全新未来移动生活概念的电动汽车 IONIQ”。在试图找出如何为汽车更新定制固件时发现，其中用来为某些部分签名的 RSA 公钥可以在网上搜索找到。更离谱的是，正如这位开发者说的，“如果运气好的话，他们不仅留下了公钥，还留下了私钥”，它是一个常见的密钥对，出现在“使用 OpenSSL 进行 RSA 加密和解密的 C 语言示例”之类的在线教程中，在这些教程中列出了使用的示例公钥和私钥。现代公司对此没有置评。消息来源：The Register老王点评：这可真是按照教程来的，连示例的密钥对都一起学习了。AI 被用于通过监控视频中的行人步态识别和分类行人据报道，马里兰大学的一个明星教授研究团队在资金的支持下，开发了一种城市监控软件，可以根据行人的独特步态特征来识别他们。然后，该算法将使用这些步态特征将行人分为“好斗”、“害羞”、“冲动”和其他性格。“这些能力将被用来预测每个行人的行为，对监视很有用”。他们在赞助方提供的视频上进行了测试，并提供了该软件的 C++ 代码库和原始数据集作为交付品。该团队还进行了“模拟大规模异质人群的有效计算模型”等类似研究。这一研究引发了对“关于机器学习研究中的严重道德问题”的关注。消息来源：The Daily Beast老王点评：AI 究竟该用于什么地方，该如何用，这里面不仅仅是道德问题，还应该是法律问题。我只能说这么多了。苹果公司的服务成为其收入的重要来源迄今为止，苹果公司已将 18 亿台设备装入世界上一些最富裕的消费者的口袋和办公桌上。现在，它正在向其他公司出售这些客户的使用权，并说服那些拥有其设备的人注册自己的订阅服务。去年，苹果的服务带来了 680 亿美元的收入，占苹果总收入的 19%。在最近一个季度，服务收入的份额甚至高达 24%。据估计，最大的一块是来自其应用商店的费用，去年的费用可能达到 250 亿美元。其次是谷歌为 iOS 中的默认搜索引擎付出的费用，2020 年付出了 100 亿美元，据估计现在接近 200 亿美元。而其广告服务今年估计是 70 亿美元。剩下的是一系列订阅服务：iCloud 存储、苹果音乐和苹果护理保险等等。消息来源：Economist老王点评：成功的硬件和软件带来的大量用户，其附加服务也是日进斗金。
如果你用过 Ubuntu 或者其他的 Linux 发行版里的自动登录功能, 你可能遇到过这种弹出消息：请输入密码以解锁你的登录密钥环登录密钥环在你登录系统时未解锁。如果你一直点击取消，它会不断弹出几次才会消失。你可能想知道，为什么你会一直看到这个密钥环信息呢？让我来告诉你吧。它其实不是错误，而是一个安全特性。奇怪吗？下面就让我来解释下 Linux 里的密钥环概念。Linux 里的密钥环是什么。为什么需要它？在现实生活中你为什么要用钥匙环（也叫钥匙链）？你用它把一把或多把钥匙串到一起, 以便于携带和查找。Linux 里也是类似的。密钥环特性使你的系统可以将各种密码放在一起，并将其保存在一个地方。大多数 Linux 桌面环境，如 GNOME、KDE、Xfce 等采用 GNOME 密钥环来提供这个功能。该密钥环保存了 ssh 密钥、GPG 密钥以及使用此功能的应用程序（例如 Chromium 浏览器）的密钥。默认情况下，“密钥环”通过主密码来保护，该密码通常是帐户的登录密码。系统上的每个用户都有自己的密钥环，（通常）密码与用户帐户本身的密码相同。当你使用密码登录系统时，你的密匙环将使用你帐户的密码自动解锁。当你启用 Ubuntu 中的自动登录功能时时，就有问题了。这意味着你无需输入密码即可登录系统。在这种情况下，你的密钥环不会自动解锁。密钥环是一个安全特性记得我说过密钥环是一个安全特性吗？现在想象一下你在 Linux 电脑上开启了自动登录功能。有权访问你电脑的任何人无需密码就能进入你的系统。但是你可能不会在意，因为你只是用它来访问互联网。但是，如果你在 Ubuntu 中使用 Chromium 或 Google Chrome 之类的浏览器，并使用它来保存各种网站的登录密码，那么你将遇到麻烦。任何人都可以使用浏览器并利用你在浏览器中保存的密码登录网站。这不很危险吗？这就是为什么当你使用 Chrome 时，它将反复地提示你先解锁密钥环。这确保了只有知道密钥环密码（即账户密码）的人才能使用在浏览器中保存的密码来登录它们相关的网站。如果你反复取消解锁密钥环的提示，它最终将消失，并允许你使用浏览器。但是，保存的密码将不会被解锁，你在 Chromium/Chome 浏览器上将会看到“同步暂停”的提示。如果密钥环一直存在，为什么你从来没有见过它呢?如果你在你的 Linux 系统上从没见过它的话，这个问题就很有道理。如果你从没有用过自动登录功能（或者修改你的账户密码），你可能都没有意识到这个特性的存在。这是因为当你通过你的密码登录系统时，你的密钥环被你的账户密码自动解锁了。Ubuntu（和其他发行版）在执行普通的管理任务如修改用户、安装新软件等需要输入密码，无论你是否是自动登录的。但是对于日常任务像使用浏览器，它不需要输入密码因为密钥环已经被解锁了。当你切换到自动登录时，你不再需要输入登录密码。这意味着密钥环没有被自动解锁，因此当你使用利用了密钥环特性的浏览器时，它将提示你来解锁密钥环。你可以轻松地管理密钥环和密码这个密钥环放在哪里？它的核心是一个守护任务（一个后台自动运行的程序）。别担心。你不必通过终端来操作守护任务。大多数桌面环境都自带一个可以和这个守护进程进行交互的图形化应用程序。KDE 上有 KDE 钱包，GNOME 和其他桌面上叫做“密码和密钥”（之前叫 Seahorse）。你可以用这个 GUI 程序来查看哪些应用程序在用密钥环来管理/保护密码。你可以看到，我的系统有自动创建的登录密钥环。也有一个存储 GPG 和 SSH 密钥的密钥环。那个证书用来保存证书机构颁发的证书（如 HTTPS 证书）。你也可以使用这个应用程序来手动保存网站的密码。例如，我创建了一个新的叫做“Test”的被密码保护的密钥环，并手动存储了一个密码。这比在一个文本文件中保存一批密码要好一些。至少在这种情况下，你的密码只有在你通过密码解锁了密钥环时才允许被看到。这里有一个潜在的问题，如果你格式化你的系统，手动保存的密码必然会丢失。通常，你会备份你的个人文件，但并不是所有的用户特定数据，如密钥环文件。有一种办法能解决它。密钥环数据通常保存在 ~/.local/share/keyrings 目录。在这里你可以看到所有的密钥环，但是你不能直接看到它们的内容。如果你移除密钥环的密码（我会在这篇文章的后面描述操作步骤），你可以像一个普通的文本文件一样读取密钥环的内容。你可以将这个解锁后的密钥环文件完整地复制下来，并在其他的 Linux 机器上运行“密码和密钥”应用程序导入到其中。总结一下目前为止所学的内容：大多数 Linux 系统缺省已经安装并激活了密钥环特性系统上的每个用户都拥有他自己的密钥环密钥环通常是用账户密码锁定的（保护）当你通过密码登录时密钥环会被自动解锁对于自动登录，密钥环不会自动解锁，因此当你试图使用依赖密钥环的应用程序时会被提示先解锁它并不是所有的浏览器或应用程序利用了密钥环特性（Linux 上）安装一个 GUI 程序可以和密钥环交互你可以用密钥环来手动存储加密格式的密码你可以自己修改密钥环密码你可以通过导出（需要先解锁密钥环）并导入到其他计算机上的方式来获取手工保存的密码。修改密钥环密码假设你修改了你的账户密码。当你登录时，你的系统试图通过新的登录密码来自动解锁密钥环。但是密钥环还在使用老的登录密码。这种情况下，你可以修改密钥环密码为新的登录密码，这样密码环才能在你登录系统时自动解锁。从菜单中打开“密码和密钥”应用程序：在“Login”密钥环上右击并点击“修改密码”：如果你不记得老的登录密码怎么办？你可能知道在 Ubuntu 上重置忘记的密码很容易。但是密钥环在这种场景下还是有问题。你修改了账户密码，但是你不记得仍然被密钥环使用的老的账户密码。你不能修改它因为你不知道老的密码。怎么办？这种情况下，你将不得不移除整个密钥环。你可以通过“密码和密钥”应用程序来操作：它会提示你进行确认：另外，你也可以手动删除 ~/.local/share/keyrings 目录下的密钥环文件。老的密钥环文件被移除后，你再打开 Chrome/Chromium 时，它会提示你创建一个新的密钥环。你可以用新的登录密码，密钥环就会被自动解锁了。禁用密钥环密码在你想用自动登录但又不想手动解锁密钥环时，你可以把禁用密钥环密码作为一个规避方法。记住你正在禁用一个安全特性，因此请三思。操作步骤和修改密钥环相似。打开“密码和密钥”应用程序，然后修改密钥环密码。技巧在于当它提示修改密码时，不要输入新密码，而是点击“继续”按钮。这将移除密钥环的密码。这种方法，密钥环没有密码保护，并将一直处于解锁状态。via: https://itsfoss.com/ubuntu-keyring/作者：Abhishek Prakash 选题：lujun9972 译者：messon007 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
如果你长期使用亚马逊 Web 服务（AWS）中的实例，你可能会遇到下面这个常见的问题，它不是因为技术性的原因导致的，更多的是因为人类追求方便舒适的天性：当你登录一台你最近没有使用的区域的新实例，你最终会创建一个新的 SSH 密钥对，久而久之这最终就会造成个人拥有太多密钥，导致管理起来复杂混乱。本文将会介绍一种在所有区域中使用你的公钥的方法。最近，一篇 Fedora Magazine 的文章介绍了另一种解决方案。但本文中的解决方案可以进一步的以更简洁和可扩展的方式实现自动化。假设你有一个 Fedora 30 或 31 系统，其中存储了你的密钥，并且还安装了 Ansible。当这两件事同时满足时，就提供了解决这个问题的办法，甚至它还能做到更多。使用 Ansible 的 ec2\_key 模块，你可以创建一个简单的 Ansible 剧本来在所有区域中维护你的 SSH 密钥对。如果你需要增加或者删除密钥，在 Ansible 中这就像从文件中添加和删除行一样简单。设置和运行 Ansible 剧本如果要使用剧本，首先需要安装 ec2_key 模块的必要依赖项：$ sudo dnf install python3-boto python3-boto3该剧本很简单：你只需要像下面的例子一样，修改其中的密钥及其对应的名称。然后，运行该剧本，它会帮你遍历所有列出的公共 AWS 区域。该示例还包括一些你可能要访问的受限区域，只需根据需要来取消对应行的注释，然后，保存文件重新运行剧本即可。--- - name: Maintain an ssh key pair in ec2 hosts: localhost connection: local gather_facts: no vars: ansible_python_interpreter: python tasks: - name: Make available your ssh public key in ec2 for new instances ec2_key: name: "YOUR KEY NAME GOES HERE" key_material: 'YOUR KEY GOES HERE' state: present region: "{{ item }}" with_items: - us-east-2 #US East (Ohio) - us-east-1 #US East (N. Virginia) - us-west-1 #US West (N. California) - us-west-2 #US West (Oregon) - ap-east-1 #Asia Pacific (Hong Kong) - ap-south-1 #Asia Pacific (Mumbai) - ap-northeast-2 #Asia Pacific (Seoul) - ap-southeast-1 #Asia Pacific (Singapore) - ap-southeast-2 #Asia Pacific (Sydney) - ap-northeast-1 #Asia Pacific (Tokyo) - ca-central-1 #Canada (Central) - eu-central-1 #EU (Frankfurt) - eu-west-1 #EU (Ireland) - eu-west-2 #EU (London) - eu-west-3 #EU (Paris) - eu-north-1 #EU (Stockholm) - me-south-1 #Middle East (Bahrain) - sa-east-1 #South America (Sao Paulo) # - us-gov-east-1 #AWS GovCloud (US-East) # - us-gov-west-1 #AWS GovCloud (US-West) # - ap-northeast-3 #Asia Pacific (Osaka-Local) # - cn-north-1 #China (Beijing) # - cn-northwest-1 #China (Ningxia)这个剧本需要通过 API 访问 AWS，为此，请使用环境变量，如下所示：$ AWS_ACCESS_KEY="aws-access-key-id" AWS_SECRET_KEY="aws-secret-key-id" ansible-playbook ec2-playbook.yml另一个方式是安装 aws 命令行工具并添加凭据，如以前的一篇 Fedora Magazine 文章所述。如果你在线存储它们，这些参数将不建议插入到剧本中！你可以在 GitHub 中找到本文的剧本代码。完成该剧本之后，请确认你的密钥在 AWS 控制台上可用。为此，可以做如下操作：登录你的 AWS 控制台转到 “EC2 > Key Pairs”你应该会看到列出的密钥。唯一的限制是你必须使用此方法逐个区域来检查。另一种方法是在 shell 中使用一个快速命令来为你做这些检查。首先在剧本上创建一个包含所有区域的变量：AWS_REGION="us-east-1 us-west-1 us-west-2 ap-east-1 ap-south-1 ap-northeast-2 ap-southeast-1 ap-southeast-2 ap-northeast-1 ca-central-1 eu-central-1 eu-west-1 eu-west-2 eu-west-3 eu-north-1 me-south-1 sa-east-1"然后，执行如下循环，你就可以从 aws 的 API 获得结果：for each in ${AWS_REGION} ; do aws ec2 describe-key-pairs --key-name <YOUR KEY GOES HERE> ; done请记住，要执行上述操作，你需要安装 aws 命令行。via: https://fedoramagazine.org/using-ansible-to-organize-your-ssh-keys-in-aws/作者：Daniel Leite de Abreu 选题：lujun9972 译者：hj24 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
什么是基于 SSH 密钥的认证？众所周知，Secure Shell，又称 SSH，是允许你通过无安全网络（例如 Internet）和远程系统之间安全访问/通信的加密网络协议。无论何时使用 SSH 在无安全网络上发送数据，它都会在源系统上自动地被加密，并且在目的系统上解密。SSH 提供了四种加密方式，基于密码认证，基于密钥认证，基于主机认证和键盘认证。最常用的认证方式是基于密码认证和基于密钥认证。在基于密码认证中，你需要的仅仅是远程系统上用户的密码。如果你知道远程用户的密码，你可以使用 ssh user@remote-system-name 访问各自的系统。另一方面，在基于密钥认证中，为了通过 SSH 通信，你需要生成 SSH 密钥对，并且为远程系统上传 SSH 公钥。每个 SSH 密钥对由私钥与公钥组成。私钥应该保存在客户系统上，公钥应该上传给远程系统。你不应该将私钥透露给任何人。希望你已经对 SSH 和它的认证方式有了基本的概念。这篇教程，我们将讨论如何在 Linux 上配置基于密钥认证的 SSH。在 Linux 上配置基于密钥认证的 SSH为方便演示，我将使用 Arch Linux 为本地系统，Ubuntu 18.04 LTS 为远程系统。本地系统详情：OS: Arch Linux DesktopIP address: 192.168.225.37/24远程系统详情：OS: Ubuntu 18.04 LTS ServerIP address: 192.168.225.22/24本地系统配置就像我之前所说，在基于密钥认证的方法中，想要通过 SSH 访问远程系统，需要将公钥上传到远程系统。公钥通常会被保存在远程系统的一个 ~/.ssh/authorized_keys 文件中。注意事项：不要使用 root 用户生成密钥对，这样只有 root 用户才可以使用。使用普通用户创建密钥对。现在，让我们在本地系统上创建一个 SSH 密钥对。只需要在客户端系统上运行下面的命令。$ ssh-keygen上面的命令将会创建一个 2048 位的 RSA 密钥对。你需要输入两次密码。更重要的是，记住你的密码。后面将会用到它。样例输出：Generating public/private rsa key pair. Enter file in which to save the key (/home/sk/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/sk/.ssh/id_rsa. Your public key has been saved in /home/sk/.ssh/id_rsa.pub. The key fingerprint is: SHA256:wYOgvdkBgMFydTMCUI3qZaUxvjs+p2287Tn4uaZ5KyE [email protected] The key's randomart image is: +---[RSA 2048]----+ |+=+*= + | |o.o=.* = | |.oo * o + | |. = + . o | |. o + . S | | . E . | | + o | | +.*o+o | | .o*=OO+ | +----[SHA256]-----+如果你已经创建了密钥对，你将看到以下信息。输入 y 就会覆盖已存在的密钥。/home/username/.ssh/id_rsa already exists. Overwrite (y/n)?请注意密码是可选的。如果你输入了密码，那么每次通过 SSH 访问远程系统时都要求输入密码，除非你使用了 SSH 代理保存了密码。如果你不想要密码（虽然不安全），简单地敲两次回车。不过，我建议你使用密码。从安全的角度来看，使用无密码的 ssh 密钥对不是什么好主意。这种方式应该限定在特殊的情况下使用，例如，没有用户介入的服务访问远程系统。（例如，用 rsync 远程备份……）如果你已经在个人文件 ~/.ssh/id_rsa 中有了无密码的密钥，但想要更新为带密码的密钥。使用下面的命令：$ ssh-keygen -p -f ~/.ssh/id_rsa样例输出：Enter new passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved with the new passphrase.现在，我们已经在本地系统上创建了密钥对。接下来，使用下面的命令将 SSH 公钥拷贝到你的远程 SSH 服务端上。$ ssh-copy-id sk@192.168.225.22在这里，我把本地（Arch Linux）系统上的公钥拷贝到了远程系统（Ubuntu 18.04 LTS）上。从技术上讲，上面的命令会把本地系统 ~/.ssh/id_rsa.pub 文件中的内容拷贝到远程系统 ~/.ssh/authorized_keys 中。明白了吗？非常棒。输入 yes 来继续连接你的远程 SSH 服务端。接着，输入远程系统用户 sk 的密码。/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys sk@192.168.225.22's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'sk@192.168.225.22'" and check to make sure that only the key(s) you wanted were added.如果你已经拷贝了密钥，但想要替换为新的密码，使用 -f 选项覆盖已有的密钥。$ ssh-copy-id -f sk@192.168.225.22我们现在已经成功地将本地系统的 SSH 公钥添加进了远程系统。现在，让我们在远程系统上完全禁用掉基于密码认证的方式。因为我们已经配置了密钥认证，因此不再需要密码认证了。在远程系统上禁用基于密码认证的 SSH你需要在 root 用户或者 sudo 执行下面的命令。禁用基于密码的认证，你需要在远程系统的终端里编辑 /etc/ssh/sshd_config 配置文件：$ sudo vi /etc/ssh/sshd_config找到下面这一行，去掉注释然后将值设为 no：PasswordAuthentication no重启 ssh 服务让它生效。$ sudo systemctl restart sshd从本地系统访问远程系统在本地系统上使用命令 SSH 你的远程服务端：$ ssh sk@192.168.225.22输入密码。样例输出：Enter passphrase for key '/home/sk/.ssh/id_rsa': Last login: Mon Jul 9 09:59:51 2018 from 192.168.225.37 sk@ubuntuserver:~$现在，你就能 SSH 你的远程系统了。如你所见，我们已经使用之前 ssh-keygen 创建的密码登录进了远程系统的账户，而不是使用当前账户实际的密码。如果你试图从其它客户端系统 ssh（远程系统），你将会得到这条错误信息。比如，我试图通过命令从 CentOS SSH 访问 Ubuntu 系统：样例输出：The authenticity of host '192.168.225.22 (192.168.225.22)' can't be established. ECDSA key fingerprint is 67:fc:69:b7:d4:4d:fd:6e:38:44:a8:2f:08:ed:f4:21. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.225.22' (ECDSA) to the list of known hosts. Permission denied (publickey).如你所见，除了 CentOS（LCTT 译注：根据上文，这里应该是 Arch）系统外，我不能通过其它任何系统 SSH 访问我的远程系统 Ubuntu 18.04。为 SSH 服务端添加更多客户端系统的密钥这点非常重要。就像我说过的那样，除非你配置过（在之前的例子中，是 Ubuntu），否则你不能通过 SSH 访问到远程系统。如果我希望给更多客户端予以权限去访问远程 SSH 服务端，我应该怎么做？很简单。你需要在所有的客户端系统上生成 SSH 密钥对并且手动拷贝 ssh 公钥到想要通过 ssh 访问的远程服务端上。在客户端系统上创建 SSH 密钥对，运行：$ ssh-keygen输入两次密码。现在，ssh 密钥对已经生成了。你需要手动把公钥（不是私钥）拷贝到远程服务端上。使用以下命令查看公钥：$ cat ~/.ssh/id_rsa.pub应该会输出类似下面的信息：ssh-rsa [binary] ostechnix@centosserver拷贝所有内容（通过 USB 驱动器或者其它任何介质），然后去你的远程服务端的终端，像下面那样，在 $HOME 下创建文件夹叫做 .ssh。你需要以 root 身份执行命令（注：不一定需要 root）。$ mkdir -p ~/.ssh现在，将前几步创建的客户端系统的公钥添加进文件中。echo {Your_public_key_contents_here} >> ~/.ssh/authorized_keys在远程系统上重启 ssh 服务。现在，你可以在新的客户端上 SSH 远程服务端了。如果觉得手动添加 ssh 公钥有些困难，在远程系统上暂时性启用密码认证，使用 ssh-copy-id 命令从本地系统上拷贝密钥，最后禁用密码认证。推荐阅读：SSLH – Share A Same Port For HTTPS And SSHScanSSH – Fast SSH Server And Open Proxy Scanner好了，到此为止。基于密钥认证的 SSH 提供了一层防止暴力破解的额外保护。如你所见，配置密钥认证一点也不困难。这是一个非常好的方法让你的 Linux 服务端安全可靠。不久我会带来另一篇有用的文章。请继续关注 OSTechNix。干杯！via: https://www.ostechnix.com/configure-ssh-key-based-authentication-linux/作者：SK 选题：lujun9972 译者：LuuMing 校对：pityonline本文由 LCTT 原创编译，Linux中国 荣誉推出
学习使用 Seahorse GUI 工具去管理 PGP 和 SSH 密钥。安全即内心的平静。毕竟，安全是许多用户迁移到 Linux 的最大理由。但是为什么要止步于仅仅采用该平台，你还可以采用多种方法和技术去确保你的桌面或者服务器系统的安全。其中一项技术涉及到密钥 —— 用在 PGP 和 SSH 中。PGP 密钥允许你去加密和解密电子邮件和文件，而 SSH 密钥允许你使用一个额外的安全层去登入服务器。当然，你可以通过命令行接口（CLI）来管理这些密钥，但是，如果你使用一个华丽的 GUI 桌面环境呢？经验丰富的 Linux 用户可能对于脱离命令行来工作感到很不适应，但是，并不是所有用户都具备与他们相同的技术和水平，因此，使用 GUI 吧！在本文中，我将带你探索如何使用 Seahorse GUI 工具来管理 PGP 和 SSH 密钥。Seahorse 有非常强大的功能，它可以：加密/解密/签名文件和文本。管理你的密钥和密钥对。同步你的密钥和密钥对到远程密钥服务器。签名和发布密钥。缓存你的密码。备份密钥和密钥对。在任何一个 GDK 支持的格式中添加一个图像作为一个 OpenPGP photo ID。创建、配置、和缓存 SSH 密钥。对于那些不了解 Seahorse 的人来说，它是一个管理 GNOME 钥匙环中的加密密钥和密码的 GNOME 应用程序。不用担心，Seahorse 可以安装在许多的桌面环境上。并且由于 Seahorse 可以在标准的仓库中找到，你可以打开你的桌面应用商店（比如，Ubuntu Software 或者 Elementary OS AppCenter）去安装它。你可以在你的发行版的应用商店中点击去安装它。安装完成后，你就可以去使用这个很方便的工具了。我们开始去使用它吧。PGP 密钥我们需要做的第一件事情就是生成一个新的 PGP 密钥。正如前面所述，PGP 密钥可以用于加密电子邮件（通过一些工具，像 Thunderbird 的 Enigmail 或者使用 Evolution 内置的加密功能）。PGP 密钥也可以用于加密文件。任何人都可以使用你的公钥加密电子邮件和文件发给你（LCTT 译注：原文此处“加密”误作“解密”）。没有 PGP 密钥是做不到的。使用 Seahorse 创建一个新的 PGP 密钥对是非常简单的。以下是操作步骤：打开 Seahorse 应用程序在主面板的左上角点击 “+” 按钮选择 “ PGP 密钥 PGP Key ”（如图 1 ）点击 “ 继续 Continue ”当提示时，输入完整的名字和电子邮件地址点击 “ 创建 Create ”图 1：使用 Seahorse 创建一个 PGP 密钥。在创建你的 PGP 密钥期间，你可以点击 “ 高级密钥选项 Advanced key options ” 展开选项部分，在那里你可以为密钥添加注释信息、加密类型、密钥长度、以及过期时间（如图 2）。图 2：PGP 密钥高级选项增加注释部分可以很方便帮你记住密钥的用途（或者其它的信息）。要使用你创建的 PGP，可在密钥列表中双击它。在结果窗口中，点击 “ 名字 Names ” 和 “ 签名 Signatures ” 选项卡。在这个窗口中，你可以签名你的密钥（表示你信任这个密钥）。点击 “ 签名 Sign ” 按钮然后（在结果窗口中）指出 “ 你是如何仔细的检查这个密钥的？ how carefully you’ve checked this key? ” 和 “ 其他人将如何看到该签名 how others will see the signature ”（如图 3）。图 3：签名一个密钥表示信任级别。当你处理其它人的密钥时，密钥签名是非常重要的，因为一个签名的密钥将确保你的系统（和你）做了这项签名工作并且完全信任这个重要的密钥。谈到导入的密钥，Seahorse 可以允许你很容易地去导入其他人的公钥文件（这个文件以 .asc 为后缀）。你的系统上有其他人的公钥，意味着你可以加密发送给他们的电子邮件和文件（LCTT 译注：原文将“加密”误作“解密”）。然而，Seahorse 在很长的一段时间内都存在一个 已知的 bug。这个问题是，Seahorse 导入使用 GPG 版本 1，但是显示的是 GPG 版本 2。这意味着，在这个存在了很长时间的 bug 被修复之前，导入公钥总是失败的。如果你想导入一个公钥文件到 Seahorse 中，你只能去使用命令行。因此，如果有人发送给你一个文件 olivia.asc，你想去导入到 Seahorse 中使用它，你将只能运行命令 gpg2 --import olivia.asc。那个密钥将出现在 GnuPG 密钥列表中。你可以打开该密钥，点击 “ 我信任签名 I trust signatures ” 按钮，然后在问题 “ 你是如何仔细地检查该密钥的？ how carefully you’ve checked the key ” 中，点击 “ 签名这个密钥 Sign this key ” 按钮去签名。SSH 密钥现在我们来谈谈我认为 Seahorse 中最重要的一个方面 — SSH 密钥。Seahorse 不仅可以很容易地生成一个 SSH 密钥，而且它也可以很容易地将生成的密钥发送到服务器上，因此，你可以享受到 SSH 密钥验证的好处。下面是如何生成一个新的密钥以及如何导出它到一个远程服务器上。打开 Seahorse 应用程序点击 “+” 按钮选择 “Secure Shell Key”点击 “Continue”提供一个密钥描述信息点击 “Set Up” 去创建密钥输入密钥的验证密钥点击 OK输入远程服务器地址和服务器上的登录名（如图 4）输入远程用户的密码点击 OK图 4：上传一个 SSH 密钥到远程服务器。新密钥将上传到远程服务器上以备使用。如果你的服务器已经设置为使用 SSH 密钥验证，那就一切就绪了。需要注意的是，在创建一个 SSH 密钥期间，你可以点击 “ 高级密钥选项 Advanced key options ”去展开它，配置加密类型和密钥长度（如图 5）。图 5：高级 SSH 密钥选项。Linux 新手必备任何 Linux 新手用户都可以很快熟悉使用 Seahorse。即便是它有缺陷，Seahorse 仍然是为你准备的一个极其方便的工具。有时候，你可能希望（或者需要）去加密或者解密一个电子邮件/文件，或者为使用 SSH 验证来管理 SSH 密钥。如果你想去这样做而不希望使用命令行，那么，Seahorse 将是非常适合你的工具。通过来自 Linux 基金会和 edX 的 "Linux 入门" 免费课程学习更多 Linux 的知识。via: https://www.linux.com/learn/intro-to-linux/2018/2/how-manage-pgp-and-ssh-keys-seahorse作者：JACK WALLEN 译者：qhwdw 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
存储 SSH 的加密秘钥和记住密码一直是一个让人头疼的问题。但是不幸的是，在当前这个充满了恶意黑客和攻击的世界中，基本的安全预防是必不可少的。对于许多普通用户来说，大多数人只能是记住密码，也可能寻找到一个好程序去存储密码，正如我们提醒这些用户不要在每个网站采用相同的密码。但是对于在各个 IT 领域的人们，我们需要将这个事情提高一个层面。我们需要使用像 SSH 密钥这样的加密秘钥，而不只是密码。设想一个场景：我有一个运行在云上的服务器，用作我的主 git 库。我有很多台工作电脑，所有这些电脑都需要登录到这个中央服务器去做 push 与 pull 操作。这里我设置 git 使用 SSH。当 git 使用 SSH 时，git 实际上是以 SSH 的方式登录到服务器，就好像你通过 SSH 命令打开一个服务器的命令行一样。为了把这些配置好，我在我的 .ssh 目录下创建一个配置文件，其中包含一个有服务器名字、主机名、登录用户、密钥文件路径等信息的主机项。之后我可以通过输入如下命令来测试这个配置是否正确。ssh gitserver 很快我就可以访问到服务器的 bash shell。现在我可以配置 git 使用相同配置项以及存储的密钥来登录服务器。这很简单，只是有一个问题：对于每一个我要用它登录服务器的电脑，我都需要有一个密钥文件，那意味着需要密钥文件会放在很多地方。我会在当前这台电脑上存储这些密钥文件，我的其他电脑也都需要存储这些。就像那些有特别多的密码的用户一样，我们这些 IT 人员也被这些特别多的密钥文件淹没。怎么办呢？清理在我们开始帮助你管理密钥之前，你需要有一些密钥应该怎么使用的基础知识，以及明白我们下面的提问的意义所在。同时，有个前提，也是最重要的，你应该知道你的公钥和私钥该放在哪里。然后假设你应该知道：公钥和私钥之间的差异；为什么你不可以从公钥生成私钥，但是反之则可以？authorized_keys 文件的目的以及里面包含什么内容；如何使用私钥去登录一个你的对应公钥存储在其上的 authorized_keys 文件中的服务器。这里有一个例子。当你在亚马逊的网络服务上创建一个云服务器，你必须提供一个用于连接你的服务器的 SSH 密钥。每个密钥都有一个公开的部分（公钥）和私密的部分（私钥）。你要想让你的服务器安全，乍看之下你可能应该将你的私钥放到服务器上，同时你自己带着公钥。毕竟，你不想你的服务器被公开访问，对吗？但是实际上的做法正好是相反的。你应该把自己的公钥放到 AWS 服务器，同时你持有用于登录服务器的私钥。你需要保护好私钥，并让它处于你的控制之中，而不是放在一些远程服务器上，正如上图中所示。原因如下：如果公钥被其他人知道了，它们不能用于登录服务器，因为他们没有私钥。进一步说，如果有人成功攻入你的服务器，他们所能找到的只是公钥，他们不可以从公钥生成私钥。同时，如果你在其他的服务器上使用了相同的公钥，他们不可以使用它去登录别的电脑。这就是为什么你要把你自己的公钥放到你的服务器上以便通过 SSH 登录这些服务器。你持有这些私钥，不要让这些私钥脱离你的控制。但是还有一点麻烦。试想一下我 git 服务器的例子。我需要做一些抉择。有时我登录架设在别的地方的开发服务器，而在开发服务器上，我需要连接我的 git 服务器。如何使我的开发服务器连接 git 服务器？显然是通过使用私钥，但这样就会有问题。在该场景中，需要我把私钥放置到一个架设在别的地方的服务器上，这相当危险。一个进一步的场景：如果我要使用一个密钥去登录许多的服务器，怎么办？如果一个入侵者得到这个私钥，这个人就能用这个私钥得到整个服务器网络的权限，这可能带来一些严重的破坏，这非常糟糕。同时，这也带来了另外一个问题，我真的应该在这些其他服务器上使用相同的密钥吗？因为我刚才描述的，那会非常危险的。最后，这听起来有些混乱，但是确实有一些简单的解决方案。让我们有条理地组织一下。（注意，除了登录服务器，还有很多地方需要私钥密钥，但是我提出的这个场景可以向你展示当你使用密钥时你所面对的问题。）常规口令当你创建你的密钥时，你可以选择是否包含一个密钥使用时的口令。有了这个口令，私钥文件本身就会被口令所加密。例如，如果你有一个公钥存储在服务器上，同时你使用私钥去登录服务器的时候，你会被提示输入该口令。没有口令，这个密钥是无法使用的。或者你也可以配置你的密钥不需要口令，然后只需要密钥文件就可以登录服务器了。一般来说，不使用口令对于用户来说是更方便的，但是在很多情况下我强烈建议使用口令，原因是，如果私钥文件被偷了，偷密钥的人仍然不可以使用它，除非他或者她可以找到口令。在理论上，这个将节省你很多时间，因为你可以在攻击者发现口令之前，从服务器上删除公钥文件，从而保护你的系统。当然还有一些使用口令的其它原因，但是在很多场合这个原因对我来说更有价值。（举一个例子，我的 Android 平板上有 VNC 软件。平板上有我的密钥。如果我的平板被偷了之后，我会马上从服务器上删除公钥，使得它的私钥没有作用，无论有没有口令。）但是在一些情况下我不使用口令，是因为我正在登录的服务器上没有什么有价值的数据，这取决于情境。服务器基础设施你如何设计自己服务器的基础设施将会影响到你如何管理你的密钥。例如，如果你有很多用户登录，你将需要决定每个用户是否需要一个单独的密钥。（一般来说，应该如此；你不会想在用户之间共享私钥。那样当一个用户离开组织或者失去信任时，你可以删除那个用户的公钥，而不需要必须给其他人生成新的密钥。相似地，通过共享密钥，他们能以其他人的身份登录，这就更糟糕了。）但是另外一个问题是你如何配置你的服务器。举例来说，你是否使用像 Puppet 这样工具配置大量的服务器？你是否基于你自己的镜像创建大量的服务器？当你复制你的服务器，是否每一个的密钥都一样？不同的云服务器软件允许你配置如何选择；你可以让这些服务器使用相同的密钥，也可以给每一个服务器生成一个新的密钥。如果你在操作这些复制的服务器，如果用户需要使用不同的密钥登录两个不同但是大部分都一样的系统，它可能导致混淆。但是另一方面，服务器共享相同的密钥会有安全风险。或者，第三，如果你的密钥有除了登录之外的需要（比如挂载加密的驱动），那么你会在很多地方需要相同的密钥。正如你所看到的，你是否需要在不同的服务器上使用相同的密钥不是我能为你做的决定；这其中有权衡，你需要自己去决定什么是最好的。最终，你可能会有：需要登录的多个服务器多个用户登录到不同的服务器，每个都有自己的密钥每个用户使用多个密钥登录到不同的服务器（如果你正在别的情况下使用密钥，这个同样的普适理论也能应用于如何使用密钥，需要多少密钥，它们是否共享，你如何处理公私钥等方面。）安全方法了解你的基础设施和特有的情况，你需要组合一个密钥管理方案，它会指导你如何去分发和存储你的密钥。比如，正如我之前提到的，如果我的平板被偷了，我会从我服务器上删除公钥，我希望这在平板在用于访问服务器之前完成。同样的，我会在我的整体计划中考虑以下内容：私钥可以放在移动设备上，但是必须包含口令；必须有一个可以快速地从服务器上删除公钥的方法。在你的情况中，你可能决定你不想在自己经常登录的系统上使用口令；比如，这个系统可能是一个开发者一天登录多次的测试机器。这没有问题，但是你需要调整一点你的规则。你可以添加一条规则：不可以通过移动设备登录该机器。换句话说，你需要根据自己的状况构建你的准则，不要假设某个方案放之四海而皆准。软件至于软件，令人吃惊的是，现实世界中并没有很多好的、可靠的存储和管理私钥的软件解决方案。但是应该有吗？考虑下这个，如果你有一个程序存储你所有服务器的全部密钥，并且这个程序被一个快捷的密钥锁住，那么你的密钥就真的安全了吗？或者类似的，如果你的密钥被放置在你的硬盘上，用于 SSH 程序快速访问，密钥管理软件是否真正提供了任何保护吗？但是对于整体基础设施和创建/管理公钥来说，有许多的解决方案。我已经提到了 Puppet，在 Puppet 的世界中，你可以创建模块以不同的方式管理你的服务器。这个想法是服务器是动态的，而且不需要精确地复制彼此。这里有一个聪明的方法，在不同的服务器上使用相同的密钥，但是对于每一个用户使用不同的 Puppet 模块。这个方案可能适合你，也可能不适合你。或者，另一个选择就是完全换个不同的档位。在 Docker 的世界中，你可以采取一个不同的方式，正如关于 SSH 和 Docker 博客所描述的那样。但是怎么样管理私钥？如果你搜索过的话，你无法找到很多可以选择的软件，原因我之前提到过；私钥存放在你的硬盘上，一个管理软件可能无法提到更多额外的安全。但是我使用这种方法来管理我的密钥：首先，我的 .ssh/config 文件中有很多的主机项。我要登录的都有一个主机项，但是有时我对于一个单独的主机有不止一项。如果我有很多登录方式，就会出现这种情况。对于放置我的 git 库的服务器来说，我有两个不同的登录项；一个限制于 git，另一个用于一般用途的 bash 访问。这个为 git 设置的登录选项在机器上有极大的限制。还记得我之前说的我存储在远程开发机器上的 git 密钥吗？好了。虽然这些密钥可以登录到我其中一个服务器，但是使用的账号是被严格限制的。其次，大部分的私钥都包含口令。（对于需要多次输入口令的情况，考虑使用 ssh-agent。）再次，我有一些我想要更加小心地保护的服务器，我不会把这些主机项放在我的 host 文件中。这更加接近于社会工程方面，密钥文件还在，但是可能需要攻击者花费更长的时间去找到这个密钥文件，分析出来它们对应的机器。在这种情况下，我就需要手动打出来一条长长的 SSH 命令。（没那么可怕。）同时你可以看出来我没有使用任何特别的软件去管理这些私钥。无放之四海而皆准的方案我们偶尔会在 linux.com 收到一些问题，询问管理密钥的好软件的建议。但是退一步看，这个问题事实上需要重新思考，因为没有一个普适的解决方案。你问的问题应该基于你自己的情景。你是否简单地尝试找到一个位置去存储你的密钥文件？你是否寻找一个方法去管理多用户问题，其中每个人都需要将他们自己的公钥插入到 authorized_keys 文件中？通过这篇文章，我已经囊括了这方面的基础知识，希望到此你明白如何管理你的密钥，并且，只有当你问出了正确的问题，无论你寻找任何软件（甚至你需要另外的软件），它都会出现。via: http://www.linux.com/learn/tutorials/838235-how-to-best-manage-encryption-keys-on-linux作者：Jeff Cogswell 译者：mudongliang 校对：wxy本文由 LCTT 原创翻译，Linux中国 荣誉推出
大家好，今天我来向大家介绍如何在 Ubuntu12.04 上设置 SSH 的无密码登录功能。仅在工作站上有正确的（公私）密钥对以供匹配时SSH服务端才会允许你登录，反之访问将不会被允许。正常情况下，我们需要连上SSH的控制台输入用户名及其密码才行。如果两者全部正确，我们就可以访问，反之访问被服务端拒绝。不过相比而言还有一种比用密码更安全的登录方式，我们可以在登录SSH时通过加密密钥进行无密码登录。如果你想启用这个安全的方式，我们只需简单的禁用密码登录并只允许加密密钥登录即可。使用这种方式时，客户端计算机上会产生一对私钥和公钥。接着客户端得把公钥上传到SSH服务端的authorized\_key文件中去。在授予访问前，服务器及客户端电脑会校验这个密钥对。如果服务器上的公钥与客服端提交的私钥匹配则授予访问权限，否则访问被拒绝。这是认证到SSH服务器的非常安全的一种做法，如果你想为单一的SSH用户登录实现安全登录，这也是备受推崇的方式。这里快速的过一遍如何启用无密码登录SSH的配置过程。1.安装Openssh服务端首先，我们需要更新我们的本地库索引。所以如下所见，我们需要先输入“apt-get update”$ sudo apt-get update 现在我们可以通过以下命令安装openssh-server：$ sudo apt-get install openssh-server 2. 开启openssh服务在OpenSSH已经成功安装在Ubuntu14.04操作系统上了之后，我们要启动OpenSSH的服务。以下命令让你启动/开启服务。$ sudo service ssh start 或$ sudo /etc/init.d/ssh start 3. 配置密钥对在我们安装并启动了OpenSSH服务以后。现在终于到了要我们搞定公私钥对的时候了，在终端中运行以下命令：$ ssh-keygen -t rsa 在运行完以上命令了以后，我们需要回答一系列的问题。首先选择保存密钥的路径，按回车将会选择默认路径即家目录的一个隐藏的.ssh文件夹。下一个提示是请输入口令提醒。我个人将此留空（直接回车）。之后密钥对就会创建，大功告成。在密钥对生成以后，我们需要将客户端上的公钥复制到SSH服务端或者主机，来创建对客户端的信任关系。运行以下命令复制客户端的公钥到服务端。$ ssh-copy-id user@ip_address 在公钥上传之后，我们现在可以禁用通过密码登陆SSH的方式了。为此，我们需要通过以下命令用文本编辑器打开/etc/ssh/ssh\_config。$ sudo nano /etc/ssh/sshd_config 现在，我们需要按照下图所示去掉几行注释并进行一些赋值。4. 重启SSH服务最后，在我们配置完SSH服务端后，为了使改动生效我们需要重启SSH服务。在终端或控制台运行以下命令重启。$ sudo service ssh restart 或$ sudo /etc/init.d/ssh restart 现在，我们可以试试不用密码仅用密钥对的方式登录ssh服务端了。总结太好了！我们成功的配置了无密码登录SSH。使用加密密钥对进行SSH服务器认证是非常安全的一种做法，如果你想为SSH的单一用户登录实施安全的认证这也是备受推崇的方式。所以，如果你还有什么问题或建议，请在意见框中向我们反馈。很欣慰你能读完，希望你能喜欢加密的SSH安全登录 :-)via: http://linoxide.com/ubuntu-how-to/setup-passwordless-ssh-logon-ubuntu-14-04/作者：Arun Pyasi 译者：martin2011qi 校对：wxy本文由 LCTT 原创翻译，Linux中国 荣誉推出