Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

了解有关 SSM Agent 的技术细节

使用本主题中的信息有助于您实施 Amazon Systems Manager Agent (SSM Agent) 并了解该代理的工作原理。

SSM Agent 版本 3.2.x.x 凭证行为

使用 Quick Setup 中的默认主机管理配置加载实例时，SSM Agent 将一组临时凭证存储在 /var/lib/amazon/ssm/credentials（适用于 Linux 和 macOS）或 %PROGRAMFILES%\Amazon\SSM\credentials（适用于 Windows Server）。临时凭证具有您为默认主机管理配置选择的 IAM 角色指定的权限。在 Linux 上，只有 root 账户才能访问这些凭证。在 Windows Server 上，只有 SYSTEM 账户和本地管理员才能访问这些凭证。

SSM Agent 凭证优先级

本主题介绍有关如何向 SSM Agent 授予对资源执行操作的权限的重要信息。

在计算机上安装 SSM Agent 后，需要适当的权限才能与 Systems Manager 服务进行通信。在 Amazon Elastic Compute Cloud (Amazon EC2) 实例上，将在附加到实例的实例配置文件中提供这些权限。在非 EC2 计算机上，SSM Agent 通常从共享的凭证文件中获取所需的权限，该文件位于 /root/.aws/credentials（Linux 和 macOS）或 %USERPROFILE%\.aws\credentials（Windows Server）。所需的权限将在混合激活过程中添加至此文件。

但是，在极少数情况下，计算机的权限最终可能会添加至多个位置，SSM Agent 将检查这些位置是否有权运行其任务。

例如，您可能将 EC2 实例配置为由 Systems Manager 托管。该配置包括附加实例配置文件。但是，之后您决定还将该实例用于开发人员或终端用户任务，并在上面安装 Amazon Command Line Interface（Amazon CLI）。此类安装会导致将其他权限添加至实例上的凭证文件。

在实例上运行 Systems Manager 命令时，SSM Agent 可能会尝试使用与您期望使用的凭证不同的凭证，例如凭证文件而不是实例配置文件中的凭证。这是因为 SSM Agent 将按照默认凭证提供程序链的规定顺序查找凭证。

默认提供程序链将按照以下顺序查找凭证：

有关信息，请参阅以下主题：

关于本地 ssm-user 账户

从 SSM Agent 2.3.50.0 版开始，该代理会创建一个名为 ssm-user 的本地用户账户，并将其添加至 /etc/sudoers.d 目录（Linux 和 macOS）或管理员组 (Windows Server)。在 2.3.612.0 之前的代理版本上，账户会在 SSM Agent 安装后首次启动或重启时创建。在版本 2.3.612.0 及更高版本上，ssm-user 账户将在会话在实例上首次启动时创建。当会话在 Amazon Systems Manager 的 Session Manager 功能中启动会话时，该 ssm-user 是默认操作系统用户。您可以通过将 ssm-user 移动到权限较低的组或更改 sudoers 文件来更改权限。在卸载 SSM Agent 后，不会从系统中移除 ssm-user 账户。

在 Windows Server 上，SSM Agent 处理每个会话启动时对 ssm-user 账户的新密码的设置。Linux 托管实例上没有为 ssm-user 设置密码。

从 SSM Agent 2.3.612.0 版开始，不会在用作域控制器的 Windows Server 计算机上自动创建 ssm-user 账户。要在 Windows Server 域控制器上使用 Session Manager，手动创建 ssm-user 账户（如果尚不存在），然后向用户分配域管理员权限。

SSM Agent 和 Instance Metadata Service (IMDS)

Systems Manager 需要依靠 EC2 实例元数据才能正常运行。Systems Manager 可以使用 Instance Metadata Service 1 或 2 版（IMDSv1和IMDSv2）访问实例元数据。您的实例必须能够访问实例元数据服务的 IPv4 地址：169.254.169.254。有关更多信息，请参阅《Amazon EC2 用户指南》中的实例元数据和用户数据。

保持 SSM Agent 的最新状态

如果有新功能添加至 Systems Manager 或者对现有功能进行了更新，则将发布 SSM Agent 的更新版本。不能使用代理的最新版本可能会阻止托管式节点使用各种 Systems Manager 功能和特性。因此，我们建议您自动完成确保机器上的 SSM Agent 为最新的过程。有关信息，请参阅自动更新到 SSM Agent。要获得有关 SSM Agent 更新的通知，请在 GitHub 上订阅 SSM Agent 发布说明页面。

确保 SSM Agent 安装目录未被修改、移动或删除

SSM Agent 安装在 /var/lib/amazon/ssm/（Linux 和 macOS）和 %PROGRAMFILES%\Amazon\SSM\（Windows Server）上。这些安装目录包含 SSM Agent 使用的关键文件和文件夹，例如凭证文件、进程间通信（IPC）资源和编排文件夹。不得修改、移动或删除安装目录中的任何内容。否则，SSM Agent 可能会停止正常运行。

按 Amazon Web Services 区域 的 SSM Agent 滚动更新

SSM Agent 更新在 GitHub 存储库中可用后，可能需要长达两周时间，更新的版本才会在不同的时间推广到所有 Amazon Web Services 区域。为此，当您尝试在区域中部署 SSM Agent 的新版本时，可能会收到以下错误：“在当前平台上不受支持”或“正在将 amazon-ssm-agent 更新为早期版本，请启用‘允许降级’以继续”。

要确定您的可用 SSM Agent 版本，可以运行 curl 命令。

要查看全局下载存储桶中的可用代理版本，请运行以下命令。

curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/VERSION

要查看特定区域中的可用代理版本，请运行以下命令，将 region 替换为与您正在使用的区域，例如对于美国东部（俄亥俄州）区域使用 us-east-2。

curl https://s3.region.amazonaws.com/amazon-ssm-region/latest/VERSION

还可以直接在浏览器中打开 VERSION 文件，无需使用 curl 命令。

SSM Agent 与 Amazon 托管 S3 存储桶进行通信

在执行各种 Systems Manager 操作过程中，Amazon Systems Manager Agent (SSM Agent) 将访问许多 Amazon Simple Storage Service (Amazon S3) 存储桶。这些 S3 存储桶可以公开访问，默认情况下，SSM Agent 使用 HTTP 调用连接到这些存储桶。

但是，如果您正在 Systems Manager 操作中使用虚拟私有云（VPC）端点，则必须在 Systems Manager 的 Amazon Elastic Compute Cloud（Amazon EC2）实例配置文件中提供显式权限，或者在混合和多云环境中的非 EC2 计算机的服务角色中提供。否则，资源无法访问这些公有存储桶。

要在使用 VPC 端点时授予这些存储桶的托管式节点访问权限，您需要创建一个自定义 Amazon S3 权限策略，然后将其附加到您的实例配置文件（适用于 EC2 实例）或服务角色（适用于非 EC2 托管式节点）。

有关在 Systems Manager 操作中使用虚拟私有云（VPC）端点的信息，请参阅使用适用于 Systems Manager 的 VPC 端点提高 EC2 实例的安全性。

有关更多信息，请参阅以下主题：

所需的存储桶权限

下表介绍了对于 Systems Manager 操作 SSM Agent 可能需要访问的每个 S3 存储桶。

SSM Agent 所需的 Amazon S3 权限

示例

以下示例演示了如何提供对美国东部（俄亥俄）区域 (us-east-2) 中 Systems Manager 操作所需的 S3 存储桶的访问权限。在大多数情况下，仅当使用 VPC 端点时，才需要在实例配置文件或服务角色中显式提供这些权限。

{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "s3:GetObject",
                "Resource": [
                    "arn:aws:s3:::aws-windows-downloads-us-east-2/*",
                    "arn:aws:s3:::amazon-ssm-us-east-2/*",
                    "arn:aws:s3:::amazon-ssm-packages-us-east-2/*",
                    "arn:aws:s3:::us-east-2-birdwatcher-prod/*",
                    "arn:aws:s3:::aws-ssm-document-attachments-us-east-2/*",
                    "arn:aws:s3:::patch-baseline-snapshot-us-east-2/*",
                    "arn:aws:s3:::aws-ssm-us-east-2/*",
                    "arn:aws:s3:::aws-patchmanager-macos-us-east-2/*"
                ]
            }
        ]
    }

使用硬件指纹验证混合激活的计算机

当非 EC2 计算机处于混合和多云环境中时，SSM Agent 将收集许多系统属性（称为硬件哈希），并使用这些属性计算指纹。指纹是代理传递给某些 Systems Manager API 的不透明字符串。这种唯一的指纹将调用方与特定混合激活的托管节点关联起来。代理将指纹和硬件哈希存储在本地磁盘上名为文件库的位置。

当计算机注册为与 Systems Manager 一起使用时，代理会计算硬件哈希和指纹。然后，在代理发送 RegisterManagedInstance 命令时，将指纹传递回 Systems Manager 服务。

稍后，当发送 RequestManagedInstanceRoleToken 命令时，代理将检查文件库中的指纹和硬件哈希，以确保当前计算机属性与存储的硬件哈希匹配。如果当前计算机属性确实与文件库中存储的硬件哈希匹配，则代理将在指纹中从文件库传递到 RegisterManagedInstance，从而成功调用。

如果当前计算机属性与存储的硬件哈希不匹配，SSM Agent 将计算新的指纹，将新的硬件哈希和指纹存储在文件库中，然后将新指纹传递给 RequestManagedInstanceRoleToken。这会导致 RequestManagedInstanceRoleToken 失败，并且代理将无法获取连接到 Systems Manager 服务的角色令牌。

此失败是特意设计的，将用作验证步骤，以防多个托管式节点作为同一托管式节点与 Systems Manager 服务进行通信。

将当前计算机属性与在文件库中存储的硬件哈希进行比较时，代理使用以下逻辑来确定旧哈希和新哈希是否匹配：

相似性阈值作为硬件哈希的一部分存储在文件库中。

可以在注册实例后使用如下所示的命令设置相似性阈值。

在 Linux 计算机上：

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

在使用 PowerShell 的 Windows Server 计算机上：

cd "C:\Program Files\Amazon\SSM\" `
    .\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1

SSM Agent，发布时间：GitHub

GitHub 上提供 SSM Agent 的源代码，便于您根据需要调整代理。我们鼓励您针对要包含的更改提交提取请求。但是，Amazon Web Services 不支持运行此软件的已修改副本。