在 AWS，确保安全是我们的首要任务，因此我们建议客户在其应用程序的各层中实施安全控制。在本博文中，我将通过要求管理员进行双重身份认证才能使用 SSH 连接，来为 EC2 实例增添一层身份验证安全保护。

创建 EC2 实例时，系统会提示为实例创建或选择以前创建的密钥对，以便可以通过 SSH 连接进入盒子。该密钥对已下载并保留在本地计算机上。此操作的风险是本地计算机可能会遭到入侵。现在，拥有此密钥对和用户名的任何用户都拥有您的实例的完整访问权限。为了提高实例访问安全性，以帮助防止漏洞攻击，您应该加强控制。在 AWS 控制台访问方面，一种最佳实践是为根账户和所有用户账户启用 Multi-Factor Authentication (MFA)。我们可以采用这一做法，为 EC2 实例启用 MFA。启用 MFA 后，用户将使用已知的信息（即密码）和已有的信息（OATH-TOTP 应用程序或物理令牌生成的一次性密码）登录。

最常见的是，我们看到人们使用公共 IP 地址直接通过 SSH 访问实例，这便为各种复杂和重复的实例施加了安全控制。我们推荐的一种方法是在实例前安装堡垒主机或跳转盒，并通过堡垒主机访问您的实例。我们建议将对实例的访问限制在堡垒主机上，以便人们不会因直接登录实例而违反安全策略。这可以通过在这些实例的安全组中创建 SSH 类型的入站规则来实现，其中源是堡垒主机的 IP 或安全组。完成后，您可以专注于加强堡垒主机的安全性，不必再专门强化控制了。另一项好处是您无需在每个实例上启用 MFA。您只能在堡垒主机上启用 MFA，如果需要，可在运行 SSH 命令从堡垒主机登录其他实例时，使用其他提示符来获取另一个一次性密码 (OTP)。

常见的架构反面模式

推荐架构

在上面的示例中，只有与安全组 sg-bdabdb2d（堡垒主机）关联的实例可以通过端口 22 与安全组 sg-hb3abcdc（所有其他实例）关联的实例通信。用户必须首先使用公共 IP 地址借助 SSH 通过端口 22 进入堡垒主机，然后通过 SSH 进入其他实例。

在 EC2 实例上启用 MFA – Amazon Linux

在下面的示例中，在 Linux 实例上启用了 MFA。为此，我们将使用 Google 的插入式验证模块 (PAM) 来启用 MFA。在您的设备上安装 Google 身份验证器应用程序，稍后将用于生成 OTP。

1. 在 EC2 实例上安装 Google 身份验证器
以正常方式通过 SSH 进入 EC2 实例，然后切换到根账户或使用 sudo 并运行：

sudo yum install google-authenticator -y

安装软件包后，运行初始化应用程序，为您以其身份登录的用户（例如 ec2-user）生成密钥，以向该用户账户添加第二重身份验证。

2. 配置 Google 身份验证器
运行初始化应用程序：

google-authenticator

系统将询问您使用的身份验证令牌是否应基于时间。在本例中，我们将使用基于时间的令牌。

是否希望身份验证令牌基于时间 (y/n) y
这将生成一个 URL，其中包含您应使用 Google 身份验证器应用程序扫描的二维码，或在您的应用程序中手动输入密钥以注册设备。在应用程序中添加账户名称，并确保启用了基于时间的选项。妥善保管在实例上生成的密钥、验证码和暂存代码，以备在您无法访问注册设备上的应用程序时使用。每个暂存代码只能使用一次。

接下来，系统会询问您是否应为用户“ec2-user”更新 google_authenticator 文件。输入“y”将保存密钥、暂存代码以及您选择稍后在文件中使用的其他配置选项。您将运行初始化应用程序并对每个用户账户执行相同的程序，以在每个账户上启用 MFA。

是否希望更新“/home/ec2-user/.google_authenticator”文件 (y/n) y
是否希望禁止多次使用同一身份验证
令牌？ 这会将您每次登录的时间限制为大约 30 秒，但有助于
发现或防止中间人攻击 (y/n) y
是否希望禁止多次使用同一身份验证
令牌？ 这会将您每次登录的时间限制为大约 30 秒，但有助于
发现或防止中间人攻击 (y/n) y

选择“n”作为下列问题的答案，除非遇到问题，否则在一个 1 分 30 秒的时段内会出现三个有效代码。

默认情况下，令牌的有效期为 30 秒，为了补偿
客户端与服务器之间可能存在的时滞，我们允许在当前时间前后
存在一个额外的令牌。如果您在时间同步方面遇到了问题，
可以将 1 分 30 秒的默认时段值增加到大约 4 分钟。
是否希望这样做 (y/n) n
如果您要登录的计算机没有经过防止暴力登录尝试的强化处理，
则可对身份验证模块启用尝试次数限制。
默认情况下，这会限制攻击者每 30 秒最多只能登录 3 次。
是否希望启用尝试次数限制 (y/n) y

3. 配置 SSH 来使用 Google 插入式验证模块
运行以下命令更改 PAM 配置。

sudo vi /etc/pam.d/sshd

将以下内容添加到文件底部以使用 Google 身份验证器。如果存在应能在未进行 MFA 的情况下登录的服务账户或用户，请在以下语句的末尾添加 nullok。这意味着，不会要求未运行 Google 身份验证器初始化的用户进行第二次身份验证。

auth required pam_google_authenticator.so 或 auth required pam_google_authenticator.so nullok

添加密码要求注释。我们只想使用 Google 身份验证器应用程序上生成的密钥对和验证码。

#auth       substack     password-auth

保存文件。接下来，我们需要更改 SSH 配置以使其提示进行第二次身份验证。

运行：

sudo vi /etc/ssh/sshd_config

为内容为 ChallengeResponseAuthentication“no”的一行添加注释，并删除显示“yes”的一行的注释。

ChallengeResponseAuthentication yes
#ChallengeResponseAuthentication no

最后，我们要让 SSH 知道其应请求可让我们登录的 SSH 密钥和验证码。在文件的底部添加：

AuthenticationMethods publickey,keyboard-interactive

保存文件。重启 SSH 使更改生效。

sudo /etc/init.d/sshd restart 或 sudo service sshd restart

要测试它是否正常工作，请打开一个新的终端窗口并通过 SSH 连接到实例，系统将要求您提供验证码。我无需输入密钥对，因为 SSH 代理中有该密钥对。在新窗口中使用 SSH 时，使会话在原始终端窗口中保持打开状态。

输入 Google 身份验证器应用上生成的代码。

配置 Google 身份验证器

4. 管理用户及其身份验证
您可以通过多种方式对用户进行多重身份验证。以下各项具有不同的安全级别。

为所有用户使用相同的 .google_authenticator。如果您是根用户，请将此文件复制到 /etc/skel/ 并与其他用户共享我们之前获得的密钥，要求他们注册设备。但是，如果用户离开组织，您可能需要运行 Google 身份验证器应用程序来生成新的密钥并向所有用户提供该密钥，这可能会变得很麻烦。
另一种方法是在创建新用户账户后登录该账户，运行初始化应用程序，然后共享与具体用户相关的生成密钥和暂存代码。这样您就不必与其他人共享相同的密钥了。当用户离开时，您只需删除相关用户账户即可。
最安全的方法是强制用户在首次登录时运行初始化应用程序，并保存生成的密钥和暂存代码。这可以通过在登录时运行脚本来完成。
5. 自动将 SSH 密钥复制到新用户账户并强制用户在首次登录时启用 MFA
创建新用户时，我们要做的第一件事就是将 authorized_key 文件复制到新用户账户中并相应地更改其权限，以便用户可以使用相同的密钥对成功通过 SSH 进入实例。最佳实践是为每个用户创建一个单独的密钥对，但在本博文中，我将在新用户账户中复制相同的密钥对。执行此操作的步骤如下：

打开 authorized_keys 文件 cat ~/.ssh/authorized_keys 并复制公钥。稍后，我们将使用该公钥在新用户账户中创建类似的文件。公钥如下所示：

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6Vhz2ItxCih+PnDS
Uaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXrlsLnBItntckiJ7FbtxJM
XLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZqaeJAAHco+CY/5WrUBkrHmFJr6
HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3RbBQoQzd8v7yeb7OzlPnWOyN0qFU0XA246
RA8QFYiCNYwI3f05p6KLxEXAMPLE

创建新用户：

sudo adduser newuser
sudo su - newuser
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys

粘贴之前复制的公钥：

vi ~/.ssh/authorized_keys

如果在 /etc/skel/ 目录中创建文件和目录结构 .ssh/authorized_keys，则可为所有用户自动执行上述复制过程。完成此操作后，创建的新用户将自动在其主目录中以适当的权限提供这些文件。

您还可以在创建用户之前运行以下命令，以执行上述操作，并且用户将能够使用自己的密钥对登录。

sudo su
mkdir -p -- "/etc/skel/.ssh" && sed -e 's/.*\(ssh-rsa.*\) .*/\1/' ~/.ssh/authorized_keys > "/etc/skel/.ssh/authorized_keys"

要强制用户在首次登录时配置 MFA，请切换到根用户，在 /etc/profile.d/ 目录中创建文件 mfa.sh 并将以下脚本粘贴到其中。

if [ ! -e ~/.google_authenticator ]  &&  [ $USER != "root" ]; then
google-authenticator --time-based --disallow-reuse --force --rate-limit=3 --rate-time=30 --window-size=3
echo
echo“保存生成的应急暂存代码，并使用密钥或扫描二维码
注册您的设备，以进行多重身份验证。”
echo
echo“使用 SSH 密钥对再次登录，并在注册的设备上生成一次性密码
。”
echo
logout
fi

如果要在切换到根用户时提示进行第二次身份验证，则可以删除 $USER != “root” 的条件。

/etc/pam.d/sshd 文件的底部应包含以下语句，以便用户登录时运行以上脚本。

auth       required     pam_google_authenticator.so nullok

如果用户离开组织，只需从堡垒主机中删除相应的用户账户即可。

sudo userdel -r olduser

小结

本博文演示了如何在 EC2 实例上设置多重身份验证，并为首次登录的用户自动运行 Google 身份验证器应用程序。这可确保用户将在其设备上生成的密钥对和基于时间的一次性密码一起用于通过 SSH 进入实例。

作者介绍：
Ronan Guilfoyle

本文转载自AWS技术博客。

原文链接：
https://amazonaws-china.com/cn/blogs/china/multi-factor-authentication-aws-security-startup/

创作场景

借助 Multi-Factor Authentication 保护实例安全