Como faço corretamente o SSH em um servidor atrás de um NAT, mantendo a segurança mais rígida possível?

Question

Eu tenho um VPC no Amazon AWS. Há um servidor NAT em execução em uma sub-rede pública que se conecta a um gateway da Internet. Eu tenho um monte de servidores em execução em várias sub-redes privadas dentro do VPC. Eu gostaria de SSH nos servidores que estão na sub-rede privada. Todos os meus servidores estão executando o AWS Linux (CentOS).

Atualmente, posso usar o SSH no servidor NAT usando minha chave privada. O servidor NAT permite conexões SSH apenas do meu IP de desenvolvimento atual. Então eu posso SSH nos servidores nas sub-redes privadas somente se eu configurar SSH Login nesses servidores, ou se eu colocar um arquivo de chave no servidor NAT e, em seguida, usá-los para SSH. Por segurança, parece que eu não deveria fazer nenhuma dessas coisas.

Existe uma maneira preferencial de praticar essa conexão? Parece que deve haver uma maneira de se conectar com uma única chamada SSH da minha máquina de desenvolvimento em casa executando o Apple OSX.

    

Answer 1

Você não deve colocar sua chave secreta no gateway, e você não precisa: -)

configure sua configuração SSH local para que você possa usar o gateway NAT para o encaminhamento de porta quando precisar:

crie uma entrada no seu ~/.ssh/config que configura encaminhamento local para os hosts aos quais você deseja se conectar:

Host natgw-fwd
        User ec2-user
        HostKeyAlias natgw-fwd.my.domain
        HostName 54.182.32.11
        LocalForward 1025 10.0.2.1:22

adicione uma entrada por host encaminhada com HostKeyAlias :

Host internal-one
        User ec2-user
        HostKeyAlias internal-one.ec2.internal
        HostName localhost
        Port 1025

traga o túnel em um único shell:

ssh -C -v natgw-fwd

e conecte-se aos hosts internos em outro shell:

ssh internal-one

Ao usar muitas conexões "rápidas + curtas" além de um shell ou dois, como com uma ferramenta como dsh, a latência para configuração e desmontagem de conexões únicas fica mais perceptível, e eu uso ControlMaster e ControlPath para ativar o compartilhamento de conexão. As limitações não me incomodam porque eu raramente uso agente ou X11 nesse cenário.

    

Answer 2

Fiz algumas pesquisas e encontrei um artigo que parece estar relacionado ao que você está perguntando.

SSH and bastion servers

By default, Linux instances in EC2 use SSH key files for authentication instead of SSH usernames and passwords. Using key files can reduce the chance of somebody trying to guess the password to gain access to the instance. But using key pairs with a bastion host can present a challenge—connecting to instances in the private subnets requires a private key, but you should never store private keys on the bastion.

One solution is to use SSH agent forwarding (ssh-agent) on the client. This allows an administrator to connect from the bastion to another instance without storing the private key on the bastion. That's the approach I'll discuss in this post.

link

Espero que você encontre a solução para criar um servidor de bastiões e usar o encaminhamento de agentes SSH em seu cliente, conforme o artigo recomenda.

    

Answer 3

A resposta do @Don King foi muito útil e aqui está o tutorial ele sugeriu. Tem instruções para o OSX e o Windows.

Aqui está o resumo do que eu fiz ao fazer o login de uma máquina OSX local. Isso pressupõe que a infraestrutura básica já esteja correta em seu VPC. Veja este tutorial para obter detalhes.

1. Abra uma conexão SSH de saída no grupo de segurança NAT que permita conexões com o grupo de segurança do servidor na sub-rede privada.

2. Abra uma conexão SSH de entrada no grupo de segurança do servidor na sub-rede privada que permite uma conexão do grupo de segurança NAT.

3. No OSX, adicione seu public_key.pem ao seu chaveiro local: ssh-add -K .aws/public_key.pem

4. SSH da sua máquina local para o NAT usando -A (ssh-agent): ssh -A ec2-user@ip_of_nat

5. SSH do NAT para o servidor na sub-rede pública: ssh ec2-user@ip_of_private_server

Problemas potenciais:

• verifique se o ForwardAgent está definido como yes no arquivo OSX / etc / ssh_config. Deve ser sim por padrão.