Conectar na EC2 pelo navegador, sem chave PEM e sem abrir SSH

Dá para abrir um terminal dentro de uma EC2 direto do navegador, sem chave PEM e sem liberar entrada de SSH no security group. Você faz isso com o Session Manager, a partir do AWS CloudShell. Aqui estão a role da instância, a policy do usuário e o comando de conexão que usei.

O problema do acesso tradicional por SSH

O jeito de sempre é gerar uma chave PEM, autorizá-la na instância e criar uma regra no security group com entrada de SSH. A chave fica guardada na sua máquina.

Se você não sabe o IP de quem vai conectar, o provável é liberar 0.0.0.0/0: libera geral. A exceção é quem tem IP fixo, caso em que você coloca só aquele IP.

Esse acesso é permissivo e depende de chave compartilhada. A AWS, por sua vez, desencoraja cada vez mais compartilhar credenciais e guardá-las na máquina local.

O que muda com o Session Manager

O Session Manager é um recurso do AWS Systems Manager. A EC2 sobe com o agente dele dentro, e a conexão acontece de forma privada: sem chave PEM e sem liberar SSH na instância.

As instâncias novas já trazem o agente; o Amazon Linux 2023, que usei, é um exemplo. Falta dar permissão ao agente, e isso se faz com uma role. Do outro lado, o usuário que vai conectar precisa de permissão para iniciar a sessão.

Do lado do usuário, usei o AWS CloudShell, o terminal do próprio console, que fica na nuvem: não guardo credencial na minha máquina.

1Lançar a EC2 sem chave e sem regra de SSH

No console do EC2, lance uma instância comum. Estas foram as minhas escolhas:

• AMI: Amazon Linux 2023, que já tem o agente do Session Manager.
• Tipo: t3.micro.
• Key pair: nenhum. Escolha prosseguir sem key pair.
• Rede (VPC): sem mexer.
• Security group: o default, sem nenhuma regra nova.
• Volume: 8 GB, que é suficiente.

Clique em Launch instance. A instância sobe sem chave e sem entrada de SSH.

2Criar a role que dá permissão ao agente

O agente do SSM só trabalha se a EC2 tiver permissão. No IAM, crie uma role:

1. Em Roles, crie a role e escolha AWS service, com o caso de uso EC2.
2. Em permissões, escolha a policy existente AmazonSSMManagedInstanceCore, que já traz as permissões necessárias.
3. Dê um nome à role (a minha foi role-acesso-ssm-aula-youtube) e crie.

Volte ao EC2, selecione a instância e vá em Security, Modify IAM role. Escolha a role que acabou de criar e clique em Update IAM role. Com a role anexada, a instância está pronta.

3Dar ao usuário permissão para iniciar a sessão

Agora o lado de quem conecta. Usei outro usuário do IAM, o modulo2, que eu já usava nas aulas do meu treinamento, e abri o CloudShell na mesma região da instância (Ohio, no meu caso).

Esse usuário precisa de uma policy que permita a ação ssm:StartSession. Crie uma policy pelo editor JSON:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ssm:StartSession",
      "Resource": ["*"]
    }
  ]
}

O Resource com asterisco vale para todos os recursos; usei assim para não especificar uma instância. Dei o nome policy-acesso-ssm-yt e criei a policy.

Depois, no usuário, vá em Add permissions, Attach policies directly, escolha a policy nova e adicione.

4Conectar pelo CloudShell

Com o usuário logado e o CloudShell aberto, copie o ID da instância no console do EC2 e rode:

aws ssm start-session --target <id-da-instancia>

Troque <id-da-instancia> pelo ID da sua EC2. Você já está dentro dela. Para provar, testei lá dentro: sem sudo, o mkdir teste e o touch teste2 foram negados; com sudo touch teste2, o arquivo foi criado e apareceu no ls. Ao rodar exit, a sessão termina e você volta ao CloudShell.

Dali você faz o que faria numa sessão SSH normal: instalar pacote, criar diretório, o que precisar. A diferença é o que você não precisou fazer.

Conferir que nenhuma porta foi aberta

Abri o security group da instância, o default: na entrada, ele não libera nada para o meu IP. Também não precisei da chave PEM, e o meu IP ali é o do próprio CloudShell, que fica na nuvem.

O acesso funcionou mesmo assim. Foi mais seguro e, no fim, mais simples: o gerenciamento que eu tive que fazer foi bem menor.

Para terminar o laboratório, encerre a instância (terminate).

Checklist

• Lançar a EC2 com Amazon Linux 2023, sem key pair e sem regra de SSH no security group.
• Criar uma role de EC2 com a policy AmazonSSMManagedInstanceCore e anexar à instância.
• Criar uma policy com ssm:StartSession e anexar ao usuário que vai conectar.
• Abrir o CloudShell na mesma região da instância.
• Conectar com aws ssm start-session --target <id-da-instancia>.
• Conferir que o security group não tem entrada de SSH liberada.
• Encerrar a instância ao terminar o teste.

O Session Manager resolve as chaves compartilhadas e o SSH aberto de uma vez. Se você quer revisar como as suas instâncias são acessadas hoje, é uma boa conversa para termos.