Permitir túnel SSH reverso, mas não simples SSH

Question

Eu tenho um computador (vamos chamá-lo de A) por trás de um NAT, e eu preciso de uma conexão SSH para ele de outro computador (vamos chamá-lo de B).

Eu vi que precisava de um túnel reverso do SSH, tentei e funciona.

Para fazer o túnel reverso funcionar, tive que adicionar a chave pública de A no arquivo authorized_keys de B.

O problema é que (por questões de segurança) eu não quero que o computador A seja capaz de ssh no computador B e veja / modifique os arquivos nele (A é uma espécie de escravo de B). / p>

É possível evitar isso?

    

Answer 1

a computer (let's name it A) […] another computer (let's name it B). […] I had to add the public key of A in the authorized_keys file of B.

Uma situação comum é adicionar a chave pública do usuário particular de A no arquivo auhorized_keys do usuário de B. Não é a chave que representa o todo computador A; da mesma forma, o arquivo authorized_keys não pertence ao todo B.

Você provavelmente adicionou a chave pública de algum usuário alpha de A no arquivo authorized_keys de algum usuário beta de B (os dois usuários podem usar o mesmo login, ainda assim eles estão em máquinas diferentes, então vamos mantenha nomes distintos alpha e beta ).

Minha solução: defina o shell de login de beta em B para /bin/false . Você pode fazer isso (em B) com sudo usermod -s /bin/false beta .

Isso causaria as seguintes restrições:

• beta normalmente não pode logar em B; em particular ssh beta@B de A não dará shell a ninguém, apesar do sucesso da autenticação SSH;
• comandos como ssh beta@B whatever não serão bem-sucedidos;
• nem o SCP nem o SFTP tentando acessar a conta de beta não funcionarão (consulte este comentário ).

Parece que não há como alpha em A ver ou modificar os arquivos em B. No entanto, ao mesmo tempo:

• qualquer pessoa capaz de autorizar como beta pode usar ssh -N para estabelecer conexão SSH a B sem executar nenhum comando lá; este é um exemplo de comando alpha deve invocar em A:

  ssh -N -R 1234:127.0.0.1:22 beta@B
  

• você não precisa ser beta para usar o encapsulamento (embora -R sem especificar um endereço de encadernação seja vinculado apenas à interface de loopback de B, então você precisa estar em B para usar o túnel, veja também man 5 sshd_config , GatewayPorts option).

Além disso, verifique as opções MaxSessions e PermitOpen em man 5 sshd_config . Eu acho que se você usá-los corretamente, um possível invasor usando a chave privada de alpha não será capaz de "capturar" muitas portas em B.