• O AWS Systems Manager CloudWatch Dashboard não estará mais disponível a partir de 30 de abril de 2026. Os clientes podem continuar usando o console do Amazon CloudWatch para visualizar, criar e gerenciar os painéis do Amazon CloudWatch exatamente como fazem hoje. Para obter mais informações, consulte a [documentação do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
# Conheça os detalhes técnicos sobre o SSM Agent
Use as informações contidas neste tópico para implementar o AWS Systems Manager Agent (SSM Agent) e entender como ele funciona.
**Topics**
+ [Comportamento da credencial do SSM Agent versão 3.2.x.x](#credentials-file)
+ [SSM AgentPrecedência de credenciais do](#credentials-precedence)
+ [Configurar o SSM Agent para usar com o Federal Information Processing Standard (FIPS, Padrão federal de processamento de informações)](#fips-compliant-configurations)
+ [Sobre a conta local ssm-user](#ssm-user-account)
+ [SSM Agent e Instance Metadata Service (IMDS)](#imds)
+ [Manter o SSM Agent atualizado](#updating)
+ [Garantir que o diretório de instalação do SSM Agent não seja modificado, movido ou excluído](#installation-directory)
+ [SSM Agent Atualizações contínuas do nas Regiões da AWS](#rolling-updates)
+ [SSM Agent Comunicações do AWS com os buckets do S3 gerenciados pela](#ssm-agent-minimum-s3-permissions)
+ [SSM Agent na GitHub](#github)
+ [Entendendo a hibernação de SSM Agent](#ssm-agent-hibernation)
## Comportamento da credencial do SSM Agent versão 3.2.x.x
O SSM Agent armazena um conjunto de credenciais temporárias em `/var/lib/amazon/ssm/credentials` (para Linux e macOS) ou em `%PROGRAMFILES%\Amazon\SSM\credentials` (para Windows Server) quando uma instância é integrada usando a configuração de gerenciamento do host padrão na Quick Setup. As credenciais temporárias têm as permissões que você especifica para o perfil do IAM escolhido para a configuração de gerenciamento do host padrão. No Linux, só a conta raiz pode acessar essas credenciais. No Windows Server, somente a conta SYSTEM e os administradores locais podem acessar essas credenciais.
## SSM AgentPrecedência de credenciais do
Este tópico descreve informações importantes sobre como o SSM Agent recebe permissão para executar ações em seus recursos.
**nota**
A compatibilidade com dispositivos de borda é um pouco diferente. Você deve configurar seus dispositivos de borda para usar o software principal do AWS IoT Greengrass, configurar um perfil de serviço do AWS Identity and Access Management (IAM) e implantar o SSM Agent para seus dispositivos usando o AWS IoT Greengrass. Para obter mais informações, consulte [Gerenciar dispositivos de borda com o Systems Manager](systems-manager-setting-up-edge-devices.md).
Quando o SSM Agent está instalado em uma máquina, ele requer permissões para se comunicar com o serviço do Systems Manager. Nas instâncias do Amazon Elastic Compute Cloud (Amazon EC2), essas permissões são fornecidas em um perfil de instância que está anexado à instância. Em uma máquina que não é do EC2, o SSM Agent normalmente obtém as permissões necessárias do arquivo de credenciais compartilhadas, localizado em `/root/.aws/credentials` (Linux e macOS) ou em `%USERPROFILE%\.aws\credentials` (Windows Server). As permissões necessárias são adicionadas a este arquivo durante o processo de [ativação híbrida](activations.md). Se um nó ativado por híbrido for retirado do registro, o atendente pode entrar no modo de hibernação. Para obter mais informações, consulte [Entendendo a hibernação de SSM Agent](#ssm-agent-hibernation).
Porém, em casos raros, uma máquina pode acabar com permissões adicionadas a mais de um dos locais em que o SSM Agent verifica se há permissões para executar suas tarefas.
Por exemplo, digamos que você tenha configurado uma instância do EC2 para ser gerenciada pelo Systems Manager. Essa configuração inclui anexar um perfil de instância. Mas então você também decide usar essa instância para tarefas de desenvolvedor ou usuário final e instalar o AWS Command Line Interface (AWS CLI) nele. Esta instalação resulta em permissões adicionais sendo adicionadas a um arquivo de credenciais na instância.
Quando você executa um comando do Systems Manager na instância, o SSM Agent pode tentar usar credenciais diferentes daquelas que você espera que ele use, como de um arquivo de credenciais em vez de um perfil de instância. Isto é porque o SSM Agent procura credenciais na ordem prescrita para a *Cadeia de fornecedores de credenciais padrão*.
**nota**
No Linux e no macOS, o SSM Agent é executado como usuário raiz. Portanto, as variáveis de ambiente e o arquivo de credenciais que o SSM Agent procura neste processo são somente do usuário raiz (`/root/.aws/credentials`). O SSM Agent não verifica as variáveis de ambiente ou o arquivo de credenciais para quaisquer outros usuários na instância durante a pesquisa de credenciais.
A cadeia de fornecedores procura e usa credenciais nesta ordem:
1. Variáveis de ambiente, se configuradas (`AWS_ACCESS_KEY_ID` e `AWS_SECRET_ACCESS_KEY`).
1. Arquivo de credenciais compartilhado (`$HOME/.aws/credentials` para Linux e macOS ou `%USERPROFILE%\.aws\credentials` para Windows Server) com permissões fornecidas por, por exemplo, uma ativação híbrida ou uma instalação da AWS CLI.
1. Uma função do AWS Identity and Access Management (IAM) para tarefas se houver uma aplicação que usa uma definição de tarefa do Amazon Elastic Container Service (Amazon ECS) ou operação da API **RunTask**.
1. Um perfil de instância anexado a uma instância do Amazon EC2.
1. O perfil do IAM escolhido para a configuração de gerenciamento do host padrão.
Para obter informações mais detalhadas, consulte os seguintes tópicos relacionados:
+ Perfis de instância para instâncias do EC2: [Configurar permissões de instância obrigatórias para o Systems Manager](setup-instance-permissions.md)
+ Ativações híbridas: [crie uma ativação híbrida para registrar nós no Systems Manager](hybrid-activation-managed-nodes.md)
+ Credenciais da AWS CLI: [Configuração e definições do arquivo de credenciais](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) no *Guia do usuário do AWS Command Line Interface*
+ Cadeia de provedores de credenciais padrão – [Especificação de credenciais](https://docs.aws.amazon.com/sdk-for-go/latest/developer-guide/configuring-sdk.html#specifying-credentials) no *Manual do desenvolvedor do AWS SDK para Go*
**nota**
Este tópico no *Guia do desenvolvedor do AWS SDK para Go* descreve a cadeia de provedores padrão em termos do SDK para Go. No entanto, os mesmos princípios se aplicam à avaliação de credenciais para o SSM Agent.
## Configurar o SSM Agent para usar com o Federal Information Processing Standard (FIPS, Padrão federal de processamento de informações)
Se precisar usar o Systems Manager com módulos criptográficos validados pelo Federal Information Processing Standard (FIPS) 140-3, você pode configurar o AWS Systems Manager Agent (SSM Agent) para usar os endpoints FIPS nas regiões compatíveis.
**Para configurar o SSM Agent para se conectar aos endpoints FIPS 140-3**
1. Conecte-se ao seu nó gerenciado.
1. Navegue até o diretório que contém o arquivo `amazon-ssm-agent.json`:
+ Linux: `/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM\`
1. Abra o arquivo chamado `amazon-ssm-agent.json` para edição.
**dica**
Se ainda não existir nenhum arquivo `amazon-ssm-agent.json`, copie o conteúdo de `amazon-ssm-agent.json.template` para um novo arquivo chamado `amazon-ssm-agent.json`. Salve o `amazon-ssm-agent.json` no mesmo diretório em que `amazon-ssm-agent.json.template` está localizado.
1. Adicione o conteúdo a seguir ao arquivo. Substitua os valores do espaço reservado de {{region}} pelo código de região apropriado para sua partição:
```
{
---Existing file content, if any---
"Mds": {
"Endpoint": "ec2messages-fips.{{region}}.amazonaws.com",
},
"Ssm": {
"Endpoint": "ssm-fips.{{region}}.amazonaws.com",
},
"Mgs": {
"Endpoint": "ssmmessages-fips.{{region}}.amazonaws.com",
"Region": "{{region}}"
},
"S3": {
"Endpoint": "s3-fips.dualstack.{{region}}.amazonaws.com",
"Region": {{region}}"
},
"Kms": {
"Endpoint": "kms-fips.{{region}}.amazonaws.com"
}
}
```
As regiões compatíveis incluem:
+ `us-east-1` para a região Leste dos EUA (Norte da Virgínia)
+ `us-east-2` para a região Leste dos EUA (Ohio)
+ `us-west-1` para a região Oeste dos EUA (Norte da Califórnia)
+ `us-west-2` para a região Oeste dos EUA (Oregon)
+ `ca-west-1` para a região Oeste do Canadá (Calgary)
1. Salve o arquivo e reinicie o SSM Agent.
Toda vez que você alterar a configuração, reinicie o SSM Agent.
Você pode personalizar outros recursos do SSM Agent usando o mesmo procedimento. Para obter uma lista atualizada das propriedades de configuração disponíveis e seus valores padrão, consulte [Config Property Definitions](https://github.com/aws/amazon-ssm-agent#config-property-definitions) no repositório `amazon-ssm-agent` no GitHub.
Para obter mais informações sobre suporte da AWS para FIPS, consulte [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
## Sobre a conta local ssm-user
Começando na versão 2.3.50.0 do SSM Agent, o agente cria uma conta de usuário local chamada `ssm-user` e a adiciona ao diretório `/etc/sudoers.d` (Linux e macOS) ou ao grupo de Administradores (Windows Server). Em versões do agente anteriores a 2.3.612.0, a conta é criada na primeira vez que o SSM Agent é iniciado ou reiniciado após a instalação. Na versão 2.3.612.0 e posteriores, a conta `ssm-user` é criada na primeira vez que uma sessão é iniciada em uma instância. Esse `ssm-user` é o usuário padrão do sistema operacional quando uma sessão do é iniciada no Session Manager, uma ferramenta do AWS Systems Manager. É possível alterar as permissões movendo `ssm-user` para um grupo com menos privilégios ou alterando o arquivo `sudoers`. A conta `ssm-user` não é removida do sistema quando o SSM Agent é desinstalado.
No Windows Server, o SSM Agent lida com a configuração de uma nova senha para a conta `ssm-user` quando cada sessão começa. Nenhuma senha é definida para `ssm-user` em instâncias gerenciadas do Linux.
Começando com o SSM Agent versão 2.3.612.0, a conta `ssm-user` não é criada automaticamente em máquinas Windows Server usadas como controladores de domínio. Para usar o Session Manager em um controlador de domínio do Windows Server, crie a conta `ssm-user` manualmente, caso ela ainda não esteja presente, e atribua permissões de Administrador do Domínio ao usuário.
**Importante**
Para que a conta `ssm-user` seja criada, o perfil de instância anexado à instância deve fornecer as permissões necessárias. Para obter informações, consulte [Etapa 2: verificar ou adicionar permissões de instância para o Session Manager](session-manager-getting-started-instance-profile.md).
## SSM Agent e Instance Metadata Service (IMDS)
O agente do Systems Manager depende dos metadados da instância do EC2 para funcionar corretamente. O Systems Manager pode acessar metadados de instância usando a versão 1 ou a versão 2 do Instance Metadata Service (IMDSv1 e IMDSv2). Sua instância deve poder acessar o endereço IPv4 do serviço de metadados da instância: 169.254.169.254. Para obter mais informações, consulte [Metadados da instância e dados do usuário](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) no *Manual do usuário do Amazon EC2*.
## Manter o SSM Agent atualizado
Uma versão atualizada do SSM Agent é lançada sempre que novas ferramentas são adicionadas ao Systems Manager ou sempre que atualizações são feitas nas ferramentas existentes. Deixar de usar a versão mais recente do atendente pode impedir que seu nó gerenciado use várias ferramentas do Systems Manager. Por isso, recomendamos automatizar o processo de manter o SSM Agent atualizado em suas máquinas. Para mais informações, consulte [Automatizar atualizações do SSM Agent](ssm-agent-automatic-updates.md). Inscreva-se na página [Notas de versão do SSM Agent](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) no GitHub para receber notificações sobre atualizações do SSM Agent.
**nota**
Uma versão atualizada do SSM Agent é lançada sempre que novas ferramentas são adicionadas ao Systems Manager ou sempre que atualizações são feitas nas ferramentas existentes. Deixar de usar a versão mais recente do atendente pode impedir que seu nó gerenciado use várias ferramentas do Systems Manager. Por isso, recomendamos automatizar o processo de manter o SSM Agent atualizado em suas máquinas. Para mais informações, consulte [Automatizar atualizações do SSM Agent](ssm-agent-automatic-updates.md). Inscreva-se na página [Notas de versão do SSM Agent](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) no GitHub para receber notificações sobre atualizações do SSM Agent.
As Amazon Machine Images (AMIs), que incluem o SSM Agent por padrão, podem demorar até duas semanas para serem atualizadas com a versão mais recente do SSM Agent. Recomendamos que você configure atualizações automatizadas ainda mais frequentes para o SSM Agent.
## Garantir que o diretório de instalação do SSM Agent não seja modificado, movido ou excluído
O SSM Agent está instalado em `/var/lib/amazon/ssm/` (Linux e macOS) e em `%PROGRAMFILES%\Amazon\SSM\` (Windows Server). Esses diretórios de instalação contêm arquivos e pastas essenciais usados pelo SSM Agent, como um arquivo de credenciais, recursos para comunicação entre processos (IPC) e pastas de orquestração. Nada no diretório de instalação deve ser modificado, movido ou excluído. Caso contrário, o SSM Agent poderá parar de funcionar corretamente.
## SSM Agent Atualizações contínuas do nas Regiões da AWS
Quando uma atualização do SSM Agent estiver disponível em seu repositório do GitHub, até duas semanas poderão ser necessárias para que a versão atualizada seja lançada para todos as Regiões da AWS em momentos diferentes. Por esse motivo, você pode receber o erro “Não compatível com a plataforma atual” ou “atualizando o amazon-ssm-agent para uma versão mais antiga, ative a permissão de downgrade para continuar” ao tentar implantar uma nova versão do SSM Agent em uma região.
Para determinar a versão do SSM Agent disponível para você, você pode executar um comando `curl`.
Para visualizar a versão do agente disponível no bucket de download global, execute o comando a seguir.
```
curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/VERSION
```
Para visualizar a versão do agente disponível em uma região específica, execute o comando a seguir, substituindo {{region}} pela região em que você está trabalhando, como `us-east-2` para a região Leste dos EUA (Ohio).
```
curl https://s3.{{region}}.amazonaws.com/amazon-ssm-{{region}}/latest/VERSION
```
Também é possível abrir o arquivo `VERSION` diretamente no seu navegador sem um comando `curl`.
## SSM Agent Comunicações do AWS com os buckets do S3 gerenciados pela
Durante a execução de várias operações do Systems Manager, o AWS Systems Manager Agent (SSM Agent) acessa uma série de buckets do Amazon Simple Storage Service (Amazon S3). Esses buckets do S3 são acessíveis publicamente e, por padrão, SSM Agent se conecta a eles usando chamadas `HTTP`.
No entanto, se você estiver usando um endpoint da nuvem privada virtual (VPC) nas operações do Systems Manager, deverá fornecer permissão explícita em um perfil de instância do Amazon Elastic Compute Cloud (Amazon EC2) para o Systems Manager ou em um perfil de serviço para máquinas que não são do EC2 em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types). Caso contrário, seus recursos não poderão acessar esses buckets públicos.
Para conceder acesso dos nós gerenciados a esses buckets quando você estiver usando um endpoint da VPC, crie uma política de permissões personalizada do Amazon S3 e anexe-a ao perfil de instância (para instâncias do EC2) ou aos perfil de serviço (para servidores nós gerenciados que não são do EC2).
Para obter informações sobre como usar um endpoint da nuvem privada virtual (VPC) em suas operações do Systems Manager, consulte [Melhorar a segurança das instâncias do EC2 usando endpoints da VPC para o Systems Manager](setup-create-vpc.md).
**nota**
Essas permissões fornecem acesso somente aos buckets gerenciados da AWS exigidos pelo SSM Agent. Elas não fornecem as permissões que são necessárias para outras operações do Amazon S3. Elas também não fornecem permissão para seus próprios buckets do S3.
Para saber mais, consulte os seguintes tópicos:
+ [Configurar permissões de instância obrigatórias para o Systems Manager](setup-instance-permissions.md)
+ [Criar o perfil de serviço do IAM obrigatório para o Systems Manager em ambientes híbridos e multinuvem](hybrid-multicloud-service-role.md)
+ [Referência: buckets do Amazon S3 para operações de aplicação de patches](patch-operations-s3-buckets.md)
**Topics**
+ [Permissões obrigatórias do bucket](#ssm-agent-minimum-s3-permissions-required)
+ [Exemplo](#ssm-agent-minimum-s3-permissions-example)
+ [Validar máquinas ativadas para ambiente híbrido usando uma impressão digital do hardware](#fingerprint-validation)
### Permissões obrigatórias do bucket
A tabela a seguir descreve cada um dos S3 que o SSM Agent pode precisar acessar as operações do Systems Manager.
**nota**
A {{região}} representa o identificador da região para uma região da Região da AWS compatível com o AWS Systems Manager, como `us-east-2` para a região Leste dos EUA (Ohio). Para ver uma lista dos valores de {{região}} com suporte, consulte a coluna **Region** em [Systems Manager service endpoints](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) no *Referência geral da Amazon Web Services*.
Permissões do Amazon S3 exigidas pelo SSM Agent
| ARN do bucket do S3 | Descrição |
| --- | --- |
| `arn:aws:s3:::aws-windows-downloads-{{region}}/*` | Obrigatório para alguns documentos SSM que oferecem suporte somente a sistemas operacionais Windows Server, além de alguns para suporte multiplataforma, como `AWSEC2-ConfigureSTIG`. |
| `arn:aws:s3:::amazon-ssm-{{region}}/*` | Obrigatório para atualizar instalações do SSM Agent. Esses buckets contêm os pacotes de instalação do SSM Agent e os manifestos de instalação referenciados pelo documento e plugin do AWS-UpdateSSMAgent. Se essas permissões não forem fornecidas, o SSM Agent fará uma chamada HTTP para fazer download da atualização. |
| arn:aws:s3:::aws-ssm-{{region}}/\* | Fornece acesso ao bucket do S3 que contém os módulos necessários para uso com documentos do Systems Manager (documentos do Command SSM), inclusive operações de aplicação de patches e sem patches. Por exemplo: arn:aws:s3:::aws-ssm-us-east-2/\*. Veja a seguir alguns documentos do SSM comumente usados que usam módulos desses buckets. [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/ssm-agent-technical-details.html) |
| `arn:aws:s3:::patch-baseline-snapshot-{{region}}/*`
- ou -
`arn:aws:s3:::patch-baseline-snapshot-{{region}}-{{unique-suffix}}/*` | Fornece acesso ao bucket do S3 que contém snapshots de linha de base de patches. Isso será necessário se você usar qualquer um dos seguintes documentos do Command SSM:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/ssm-agent-technical-details.html)
Os buckets para a maioria das Regiões da AWS compatíveis usam o seguinte formato:
`arn:aws:s3:::patch-baseline-snapshot-{{region}}`
Para algumas regiões, um sufixo exclusivo adicional é incluído no nome do bucket. Por exemplo, o nome do bucket para a região Oriente Médio (Bahrein) (me-south-1) é o seguinte:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/ssm-agent-technical-details.html)
Para obter uma lista completa dos nomes de buckets de snapshot da lista de referência de patches, consulte [Buckets contendo snapshots da lista de referência de patches gerenciadas pela AWS](patch-operations-s3-buckets.md#aws-patch-manager-buckets-baseline-snapshots). Se você usar um firewall on-premises e planeja usar o Patch Manager, esse firewall também deverá permitir o acesso ao endpoint da lista de referência de patches apropriado. |
| Para nós gerenciados do Linux e do Windows Server: `arn:aws:s3:::aws-patch-manager-{{region}}-{{unique-suffix}}/*`
Em instâncias do Amazon EC2 para macOS: `arn:aws:s3:::aws-patchmanager-macos-{{region}}-{{unique-suffix}}/*` | Fornece acesso ao bucket do S3 que contém módulos usados pelos documentos do SSM Command para operações de aplicação de patches no Patch Manager. Cada nome de bucket inclui um sufixo exclusivo, como `552881074` para buckets na região Leste dos EUA (Ohio) (us-east-2): [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/ssm-agent-technical-details.html) Documentos do SSM Veja a seguir alguns documentos do SSM comumente usados que usam módulos desses buckets. [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/ssm-agent-technical-details.html)
Para obter listas completas de buckets do S3 gerenciados pela AWS para operações de aplicação de patches, consulte os seguintes tópicos:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/systems-manager/latest/userguide/ssm-agent-technical-details.html) |
| `arn:aws:s3:::{{region}}-birdwatcher-prod/*` | Obrigatório para operações do Distributor. Esse bucket contém manifestos de pacotes usados pelo plug-in `aws:configurePackage` ao instalar ou atualizar pacotes do Distributor usando documentos como `AWS-ConfigureAWSPackage`. Se você estiver usando endpoint da VPC, sua política de endpoint da VPC S3 deve incluir acesso a esse bucket. |
### Exemplo
O exemplo a seguir ilustra como fornecer acesso aos buckets do S3 necessários para as operações do Systems Manager na região Leste dos EUA (Ohio) (us-east-2). Na maioria dos casos, você precisa fornecer essas permissões explicitamente em um perfil de instância ou função de serviço somente ao usar um endpoint da VPC.
**Importante**
Recomendamos que você evite usar caracteres curinga (\*) no lugar das regiões específicas nessa política. Por exemplo, use `arn:aws:s3:::aws-ssm-us-east-2/*` e não use `arn:aws:s3:::aws-ssm-*/*`. O uso de curingas pode fornecer acesso a buckets do S3 aos quais você não pretende conceder acesso. Se você quiser usar o perfil de instância para mais de uma região, recomendamos repetir o primeiro bloco `Statement` para cada região.
------
#### [ JSON ]
****
```
{
"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:::aws-ssm-us-east-2/*",
"arn:aws:s3:::us-east-2-birdwatcher-prod/*",
"arn:aws:s3:::patch-baseline-snapshot-us-east-2/*",
"arn:aws:s3:::aws-patch-manager-us-east-2-552881074/*",
"arn:aws:s3:::aws-patchmanager-macos-us-east-2-552881074/*"
]
}
]
}
```
------
### Validar máquinas ativadas para ambiente híbrido usando uma impressão digital do hardware
Quando há máquinas que não são EC2 em um ambiente [híbrido e multinuvem](operating-systems-and-machine-types.md#supported-machine-types), o SSM Agent reúne uma série de atributos do sistema (referidos como *hash de hardware*) e usa esses atributos para computar uma *impressão digital*. A impressão digital é uma string opaca que o agente passa para determinadas APIs do Systems Manager. Essa impressão digital exclusiva associa o chamador a um nó gerenciado ativado para ambientes híbridos específico. O agente armazena a impressão digital e o hash de hardware no disco local em um local chamado *Cofre*.
O agente calcula o hash de hardware e a impressão digital quando a máquina é registrada para uso com o Systems Manager. Em seguida, a impressão digital é passada de volta para o serviço Systems Manager quando o agente envia um comando `RegisterManagedInstance`.
Posteriormente, ao enviar um `RequestManagedInstanceRoleToken`, o agente verifica a impressão digital e o hash de hardware no Cofre para se certificar de que os atributos de máquina atuais correspondam ao hash de hardware armazenado. Se os atributos atuais da máquina corresponderem ao hash de hardware armazenado no Vault, o agente passa a impressão digital do Vault para `RegisterManagedInstance`, resultando em uma chamada bem-sucedida.
Se os atributos de máquina atuais não corresponderem ao hash de hardware armazenado, o SSM Agent calcula uma nova impressão digital, armazena o novo hash de hardware e a impressão digital no Vault e passa a nova impressão digital para `RequestManagedInstanceRoleToken`.* Isso faz `RequestManagedInstanceRoleToken` falhar e o agente não poderá obter um token de função para se conectar ao serviço do Systems Manager.*
Esta falha ocorre intencionalmente e é usada como uma etapa de verificação para impedir que vários nós gerenciados se comuniquem com o serviço do Systems Manager como o mesmo nó gerenciado.
Ao comparar os atributos da máquina atual com o hash de hardware armazenado no Cofre, o agente usa a seguinte lógica para determinar se os hashes antigos e novos correspondem:
+ Se o SID (ID do sistema/máquina) for diferente, não haverá nenhuma correspondência.
+ Caso contrário, se o endereço IP for o mesmo, então correspondem.
+ Caso contrário, a porcentagem de atributos de máquina correspondentes é calculada e comparada com o limite de similaridade configurado pelo usuário para determinar se há uma correspondência.
O limite de similaridade é armazenado no Cofre, como parte do hash de hardware.
O limite de similaridade pode ser definido depois que uma instância é registrada usando um comando como o seguinte.
Em máquinas Linux:
```
sudo amazon-ssm-agent -fingerprint -similarityThreshold 1
```
Em máquinas Windows Server que usam o PowerShell:
```
cd "C:\Program Files\Amazon\SSM\" `
.\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1
```
**Importante**
Se um dos componentes usados para calcular a impressão digital mudar, isso pode fazer com que o agente hiberne. Para ajudar a evitar essa hibernação, defina o limite de similaridade para um valor baixo, como **1**. Para obter mais informações sobre hibernação, consulte [Entendendo a hibernação de SSM Agent](#ssm-agent-hibernation).
## SSM Agent na GitHub
O código-fonte para o SSM Agent está disponível no [https://github.com/aws/amazon-ssm-agent](https://github.com/aws/amazon-ssm-agent) para que você possa adaptar o agente de acordo com suas necessidades. Incentivamos você a enviar [solicitações pull](https://github.com/aws/amazon-ssm-agent/blob/mainline/CONTRIBUTING.md) sobre alterações que gostaria que fosse incluídas. Porém, a Amazon Web Services não oferece suporte à execução de cópias modificadas desse software.
## Entendendo a hibernação de SSM Agent
A hibernação do atendente AWS Systems Manager (SSM Agent) é um modo operacional que ocorre quando o atendente não consegue manter a comunicação adequada com o serviço Systems Manager. Durante a hibernação, o atendente reduz sua frequência de comunicação e entra em estado de espera.
**Quando ocorre a hibernação de SSM Agent**
A hibernação de SSM Agent pode ocorrer nos seguintes cenários:
Nós híbridos com registro cancelado
Quando você cancela o registro de um [nó ativado por híbrido ](hybrid-activation-managed-nodes.md) no Systems Manager, o SSM Agent naquele nó não pode atualizar seu token de autorização. Isso faz com que o atendente entre no modo de hibernação porque não consegue se autenticar com o serviço.
Alterações na impressão digital do hardware
SSM Agent usa uma impressão digital do hardware para validar as máquinas ativadas em modo híbrido. Se um dos componentes usados para calcular esta impressão digital mudar, o atendente pode hibernar como uma medida de segurança. Isso ocorre intencionalmente para impedir que vários nós gerenciados se comuniquem com o Systems Manager como se fossem o mesmo nó. Para obter mais informações, consulte [Validar máquinas ativadas para ambiente híbrido usando uma impressão digital do hardware](#fingerprint-validation).
Hibernação de SSM Agent em instâncias do Amazon EC2
A hibernação também pode ocorrer em instâncias do Amazon EC2 sob certas condições, como quando há problemas de conectividade ou problemas de autenticação com o serviço Systems Manager.
**Comportamento de comunicação de hibernação**
QuandoSSM Agent entra no modo de hibernação, seu padrão de comunicação com o serviço Systems Manager muda:
+ **Operação normal**: o atendente se comunica regularmente com o Systems Manager (normalmente a cada poucos minutos) para verificar novos comandos e relatar o status.
+ **Modo de hibernação**: a frequência de ping começa em 5 minutos e aumenta gradualmente para uma vez por hora por padrão (configurável em até 24 horas). Essa frequência de comunicação reduzida ajuda a minimizar o tráfego de rede desnecessário e ainda permite que o atendente se recupere se as condições mudarem.
Durante a hibernação, o atendente continua com as tentativas de autenticação e conexão com a frequência reduzida, mas não consegue processar novos comandos nem relatar informações detalhadas de status até que a hibernação seja resolvida.
**Opções de configuração para evitar a hibernação em instâncias híbridas**
A principal opção de configuração para ajudar a evitar a hibernação causada por alterações na impressão digital do hardware é ajustar o limite de similaridade:
Em máquinas Linux:
```
sudo amazon-ssm-agent -fingerprint -similarityThreshold 1
```
Em máquinas Windows Server que usam PowerShell:
```
cd "C:\Program Files\Amazon\SSM\" `
.\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1
```
O limite de similaridade determina com que rigor o atendente compara os atributos atuais da máquina com o hash de hardware armazenado:
+ Valores mais altos exigem mais atributos correspondentes
+ Valores mais baixos (como **1**) são mais tolerantes e podem ajudar a evitar a hibernação causada por pequenas alterações de hardware
**Registro em log e monitoramento da hibernação**
QuandoSSM Agent entra no modo de hibernação, cria entradas de log que podem ajudá-lo a identificar e solucionar problemas do estado de hibernação:
+ **Arquivos de log do atendente**: os eventos de hibernação são registrados nos arquivos de log padrão SSM Agent. Para obter mais informações sobre localizações de arquivos de log, consulte [Solucionar problemas usando arquivos de log do SSM Agent](troubleshooting-ssm-agent.md#systems-manager-ssm-agent-log-files).
+ **Registro do console Amazon EC2**: para instâncias do EC2, as mensagens de hibernação agora são registradas nos logs do sistema do console Amazon EC2, fornecendo visibilidade adicional sobre o status do atendente. Para selecionar os logs, selecione a instância no console do EC2 e escolha **Ações**, **Monitorar e solucionar problemas**, **Obter log do sistema**.
+ **Arquivos de log específicos**: quando a hibernação começa, são criados arquivos de log específicos que contêm informações detalhadas sobre o gatilho e o status da hibernação.
Monitore essas fontes de log para detectar precocemente os eventos de hibernação e tomar medidas corretivas para restaurar a operação normal do atendente.
**Recuperação da hibernação**
Para se recuperar da hibernação, resolva a causa subjacente:
+ **Para nós híbridos com registro cancelado**: registre novamente o nó no Systems Manager usando um novo código de ativação e ID, conforme descrito em [Cancele o registro e registre um nó gerenciado novamente (Linux)](hybrid-multicloud-ssm-agent-install-linux.md#systems-manager-install-managed-linux-deregister-reregister) e [Cancelar o registro e registrar um nó gerenciado novamente (Windows Server)](hybrid-multicloud-ssm-agent-install-windows.md#systems-manager-install-managed-win-deregister-reregister).
+ **Para problemas de impressão digital de hardware**: ajuste o limite de similaridade conforme descrito acima em **Opções de configuração para evitar a hibernação em instâncias híbridas** ou registre novamente o nó se as alterações de hardware forem significativas.
+ **Para problemas de conectividade**: verifique a conectividade da rede e certifique-se de que os endpoints necessários estejam acessíveis. Para obter mais informações, consulte [Solucionar problemas de disponibilidade do nó gerenciado usando a `ssm-cli`](troubleshooting-managed-nodes-using-ssm-cli.md).
Depois de resolver o problema subjacente, o atendente deve sair automaticamente do modo de hibernação e retomar a operação normal na próxima tentativa de comunicação.