Proxy SSH para ocultar endpoints [duplicados]

Question

Alguém fez o proxy do SSH que é transparente para o usuário, mas o host final para o qual ele é roteado é determinado por qualquer um dos seguintes: nome de usuário, chave de identidade, nome de host DNS. Eu acho que o nome do host DNS não é possível com o protocolo, mas poderia usar a chave de identidade.

Por exemplo, quero que os usuários possam usar todos os SSH na mesma máquina, mas eles acabam em diferentes nós VPS: ssh -i identity_rsa [email protected].

Existem alguns recursos muito interessantes para fazer isso:

1. A chave do host RSA é a mesma, não importa em qual VPS você está usando o SSH.
2. O nome do host pode ser o mesmo ou (duvidoso) poder rotear em nomes de subdomínios. Não tenho certeza se isso está no protocolo ou apenas usa o endereço IP para se conectar a um soquete TCP.
3. Configuração zero no lado do cliente (comandos de proxy, vários túneis ssh, etc)
4. Todo o tráfego é canalizado através de um gateway.

Estou preocupado que isso exija um servidor SSM MitM personalizado (legítimo), porque desejo uma conexão SSH de ponta a ponta normal que possa fazer o encaminhamento de agente e de SCP.

O encaminhamento de agentes pode funcionar com comandos forçados? Eu poderia criar comandos forçados com base na chave pública, chamar SSH -A para o host interno?

    

Answer 1

Ainda tenho dúvidas sobre isso (veja minha resposta anterior). Você não pode fazer proxies reversos aqui, a menos que você tenha um proxy reverso que entenda como fazer a autenticação ssh e, mesmo assim, seu proxy seja um ponto de extremidade para a conexão ssh, portanto, ele terá acesso aos dados e terá o chaves ssh para as conexões do usuário e conexões com os servidores por trás dele. Se alguém tiver acesso a esse sistema, é mais provável que o jogo acabe atrás de tudo.

Você pode evitar alguns desses riscos se estiver preparado para fazer com que os usuários façam login duas vezes, com a segunda conexão sendo sintonizada na primeira conexão ao host bastion, mas você disse que não é isso que está procurando.

Então, você realmente precisa bloquear seu host bastion.

Seu host bastion precisará ter várias contas de usuário, cada uma com chaves privadas ssh em suas pastas .ssh para fazer login nos hosts por trás delas. Eles também manterão as chaves públicas com as quais os usuários fazem login.

Você precisa ter certeza de que os usuários não podem executar nada no bastião, exceto o ssh, para o host na rede. Configure o comando ssh no arquivo ssh authorized_keys, portanto, o login com a chave pública executa automaticamente o comando ssh para se conectar ao host atrás do bastião. Veja a seção AUTHORIZED KEYS em man sshd , particularmente o 'command =' bit.

• Mantenha ao mínimo o número de usuários que podem fazer qualquer coisa no bastião que não seja o comando ssh. Talvez apenas o acesso root. Talvez um usuário administrador ou dois.
• Certifique-se de que o usuário não possa adicionar argumentos ao comando ssh.
• Sem acesso por senha. Apenas chaves SSH.
• Desativar AllowTcpForwarding, PermitTunnel, X11Forwarding
• Tenha muito cuidado se você estiver configurando o encaminhamento do Agente SSH. Desativar se não for necessário.
• Considere configurar diretórios chroots por usuário com quase nada neles.

Answer 2

Estou tendo problemas para pensar em um bom motivo para querer fazer o que você está descrevendo. ou seja, as possibilidades que eu pensei são principalmente desaconselháveis.

Eu sugiro que você dê mais informações sobre o problema subjacente que você está tentando resolver e que a resposta pode levá-lo em uma direção diferente, de qualquer maneira.

com base em mais informações:

1. Minha primeira sugestão seria que você configurasse várias portas de encaminhamento no host bastion, cada um encaminhando para o ssh em uma máquina diferente. Se seus usuários armazenam a porta em seus arquivos .ssh / config ou configuração de massa, então não é um inconveniente significativo.

2. Você pode ter contas ssh no host bastion com comandos especificados no arquivo authorized_keys para se conectar aos hosts apropriados via ssh. Você acabaria com dois processos de login ssh, o que é um pouco lento, mas se você usar um agente ssh e um agente de encaminhamento, não será muito doloroso. O encaminhamento de agentes significa que, se o host do bastião foi comprometido, as chaves ssh de qualquer pessoa que tenha efetuado login no momento poderão sofrer abuso, enquanto permanecerem conectadas.

A opção 2 está mais próxima do que você pediu, mas a opção 1 é melhor IMHO.

NB (Adicionado muito depois)

Observe que a opção 2 teria sido afetada pelos Shell Shock explora o bash. Eu espero que as pessoas tenham corrigido isso há muito tempo, mas é um exemplo de como terminar o acesso ssh em um host que passa a conexão através de uma segunda conexão ssh é potencialmente vulnerável de uma forma que uma solução baseada em encaminhamento de porta não é. / p>