SSH Tunnel conecta 2 servidores via terceiro servidor

Question

Eu tenho 3 servidores, Um é um servidor público acessível na Internet. B Hospeda um Webservice que desejo acessar. C tem direitos de acesso para se conectar a A e B.

Agora eu quero que, se um cliente D tentar acessar uma porta especial em A que ele seja encaminhado para B.

IP's e Portas

A:

• 1.0.0.1:22 Servidor SSHD
• 1.0.0.1:443 Porta pública que eu quero usar

B:

• 1.0.0.2:23 Servidor SSHD
• 1.0.0.2:444 Webservice Desejo acessar

C:

• 1.0.0.3

D:

• 1.0.0.4

Diagrama:

  +------------+        +------------+
  | Client (D) +--------> Public (A) |
  +------------+        +-----^------+
                              |
  +----------------+    +-----------+
  | Webservice (B) <----+ Proxy (C) |
  +----------------+    +-----------+

Pergunta:

Quais comandos de túnel ssh eu preciso executar em C para que, se eu tentar abrir 1.0.0.1:443 em D , eu receba o serviço hospedado em 1.0. 0,2: 444?

    

Answer 1

Em C você pode correr

ssh -fNR 1.0.0.1:443:1.0.0.2:444 [email protected]

Ele só funcionará se você fizer login como root user porque 443 é uma porta privilegiada. Além disso, só funciona se sshd em A estiver configurado com GatewayPorts definido como yes ou clientspecified . (O padrão é no e usar yes não pode ser recomendado, portanto, se você quiser fazer dessa maneira, eu recomendo clientspecified ).

    

Answer 2

Não é bem assim que os túneis SSH funcionam. Você pode chegar perto do que descreve, mas não exatamente da maneira como você o desenha.

2 opções estão disponíveis para você:

1. use Local port forwarding
2. use Dynamic port forwarding

1) Encaminhamento de porta local

Isso requer que você mude sua abordagem: o túnel precisa ser aberto a partir do cliente, de D em seu diagrama. é fácil de conseguir, no cliente (D) basta fazer um

ssh -L 443:1.0.0.2:444 [email protected]

é claro que isso exige que você:

• tem acesso ao shell ou um cliente de massa em D
• tem um usuário no proxy (C) que D pode fazer login em
• conseguir conectar de D a C via ssh
• ter o X11Forwarding e o AllowTcpForwarding definidos como sim na configuração do servidor em C

Vou explicar o encaminhamento de porta dinâmica em um momento

    

Answer 3

Editar:

@kasperd mencionou que você pode configurar o GatewayPorts para o usuário, pois não é necessário usar o nginx. Deixo a solução aqui para os outros.

Adicione isso a /etc/ssh/sshd_config

Match User <username>
   GatewayPorts yes

Resposta original:

Eu encontrei uma solução para isso com ssh e nginx. Não é perfeito porque eu tenho que instalar um servidor nginx em um com um proxy. Eu tive que ativar SSL e dar a esta instância nginx um certificado SSL próprio.

A solução será assim: C irá executar o seguinte comando para criar um Relay entre A e B:

ssh -R 445:1.0.0.2:444 [email protected] -p 22

Isso fará com que qualquer entrada na porta 445 em 1.0.0.1 seja redirecionada para 1.0.0.2:444. Portanto, um usuário local em A agora pode executar wget https://localhost:445 --no-check-certificate para obter a página de índice do seu serviço da web. No entanto, ainda não está disponível publicamente. (no caso de você se perguntar: a porta 445 está correta, preciso usar uma porta não utilizada ainda para a próxima parte)

Então eu criei um servidor nginx em A que redirecionará qualquer tráfego da porta 443 para a porta 445. E usou a seguinte configuração:

server {
        listen 443 ssl default_server;
        listen [::]:443 ssl default_server;
        ssl on;

        ssl_certificate /etc/nginx/ssl/server.crt;
        ssl_certificate_key /etc/nginx/ssl/server.key;

        server_name proxy.<your-domain>.com;

        location / {
          proxy_pass        https://127.0.0.1:445;
          proxy_set_header  X-Real-IP  $remote_addr;
          proxy_set_header  Host $host;
        }
}

Agora você pode usar seu navegador (no modo de navegação anônima no Firefox para evitar problemas com o certificado) para acessar o link .com: 443 e obter o resultado de seu Webservice. O IP de proxy..com deve ser 1.0.0.1.

O que eu não gosto aqui é que eu tenho que criar um novo servidor que irá criar uma nova sessão criptografada em vez de apenas redirecionar o meu webservice localizado em B . No entanto, esta é uma boa solução até encontrar uma solução melhor.