Questão Como tornar o túnel ssh aberto ao público?


Bem, referindo-se a esta pergunta, eu estou executando o comando

ssh -R 8080:localhost:80 -N root@example.com

em um Mac. No entanto, o porto que está sendo tunelado não está funcionando publicamente. Estou executando um comando para que a porta local possa ser aberta no computador remoto. E funciona ao abrir a porta no host local no computador remoto, mas quando tento acessar o endereço IP público do computador remoto do meu computador local, a porta não parece estar aberta. Como eu tornaria o túnel público no IP para qualquer um acessar?

EDIT: Parece como se o lado remoto se liga apenas no localhost em vez de para todas as interfaces.

EDIT 2: O cliente é o Mac OS X 10.6 e o ​​servidor é o Linux Mint, mas ambos são OpenSSH.


137


origem


O que significa IP público? Se você estiver tentando se conectar a um computador local através do roteador e através da Internet, a maioria dos roteadores não permitirá esse loopback. - harrymc


Respostas:


Se você verificar a página man do ssh, verá que a sintaxe para -R lê:

-Rbind_address:]porta:hospedeiro:hostport

Quando bind_address é omitido (como no seu exemplo), a porta é ligada apenas na interface de loopback. Para torná-lo vinculado a todas as interfaces, use

ssh -R \*:8080:localhost:80 -N root@example.com

ou

ssh -R 0.0.0.0:8080:localhost:80 -N root@example.com

ou

ssh -R "[::]:8080:localhost:80" -N root@example.com

A primeira versão se liga a todas as interfaces individualmente. A segunda versão cria uma ligação geral somente IPv4, o que significa que a porta está acessível em todas as interfaces via IPv4. A terceira versão é provavelmente tecnicamente equivalente à primeira, mas novamente cria apenas uma ligação para ::, o que significa que a porta é acessível via IPv6 nativamente e via IPv4 através de Endereços IPv6 mapeados para IPv4 (não funciona no Windows, OpenBSD). (Você precisa das citações porque [::] poderia ser interpretado como um glob de outra forma.)

Observe que se você usa o OpenSSH sshd servidor, o servidor GatewayPorts opção precisa ser ativada (definido como yes ou clientspecified) para que isso funcione (verifique o arquivo /etc/ssh/sshd_config no servidor). Caso contrário (o valor padrão para esta opção é no), o servidor sempre forçará a porta a ser ligada apenas na interface de loopback.


281



OH MEU DEUS FUNCIONOU !!!!! Eu fiz exatamente isso 1 milhão de vezes !! Eu esqueci que * no bash vai dar arquivos e eu precisava \* - Trevor Rudolph
Sim, é exatamente por isso que eu sempre prefiro 0.0.0.0 - é apenas IPv4, mas vai fazer a maior parte do tempo :) - Stefan Seidel
GatewayPorts sim resolveu meu problema. - Sunry
GatewayPorts = sim (na configuração do sshd remoto) consertou para mim também - Phil_1984_
"GatewayPorts sim" fez o meu dia, obrigado @StefanSeidel - karser


Editar:

-g funciona para portas encaminhadas locais, mas o que você quer é uma porta de encaminhamento inversa / remota, que é diferente.

O que você quer é esta.

Essencialmente, em example.comconjunto GatewayPorts=clientspecified dentro /etc/ssh/sshd_config.

--- resposta anterior (incorreta) ---

Use a opção -g. Da página man do ssh:

-g     Allows remote hosts to connect to local forwarded ports.

32



não parece estar funcionando ... ele inicia, mas eu não consigo conectar remotamente - Trevor Rudolph
Tente correr netstat -elnpt de um tty separado para descobrir quais portas estão vinculadas a qual endereço. Sem -g, uma porta deve ser obrigada a 127.0.0.1:PORT. Com -g, deve ser obrigado a 0.0.0.0:PORT, o que torna acessível remotamente. - snapshoe
pastebin.com/q6f4kJyd - Trevor Rudolph
GatewayPorts=clientspecified ou GatewayPorts clientspecified - Trevor Rudolph
e adiciono isso ao cliente ou ao controle remoto? - Trevor Rudolph


Aqui está minha resposta para conclusão:

Acabei usando ssh -R ... para tunelamento e usando socat em cima disso para redirecionar o tráfego de rede para 127.0.0.1:

túnel ligado a 127.0.0.1: ssh -R mitm:9999:<my.ip>:8084 me@mitm

socat: mitm$ socat TCP-LISTEN:9090,fork TCP:127.0.0.1:9999

Outra opção é fazer um túnel somente local em cima disso, mas eu acho isso Muito de Mais devagar

mitm$ ssh -L<mitm.ip.address>:9090:localhost:9999 localhost


10



Eu gosto do fato de que eu não tenho que lidar com a configuração do sshd e que eu posso fazer tudo isso sem o sudo. Além disso, eu aprendo que socat existe. Obrigado! - BrutusCat


Você também pode usar um forward duplo se não quiser ou pode alterar o / etc / ssh / sshd_config.

Primeiro encaminhar para a porta temporária (por exemplo, 10080) no dispositivo de loopback na máquina remota e, em seguida, usar o redirecionamento local para redirecionar a porta 10080 para 80 em todas as interfaces:

ssh -A -R 10080:localhost_or_machine_from:80 user@remote.tld "ssh -g -N -L 80:localhost:10080 localhost"

8



Isso realmente funciona para contornar as regras de encaminhamento! - Michael Schubert
Amo essa solução. Ótima solução alternativa quando você não quer que a configuração seja alterada na máquina - Grezzo


Use a opção "portas de gateway".

ssh -g -R REMOTE_PORT:HOST:PORT ...

Para usar isso, você provavelmente precisará adicionar "GatewayPorts yes"para o seu servidor /etc/ssh/sshd_config.


6



Na verdade isso funcionou. O que faço é usar uma instância do EC2 como um encaminhador para meu servidor REST. Dessa forma, não preciso colocar meu servidor na DMZ e não preciso de um IP público. Engraçado, com a primeira instância do EC2 que eu criei, ssh -R remote_port: localhost: port xxx @ ec2xxx funcionou muito bem, mas eu tive que criar outra instância mais tarde por algum motivo e daquele ponto em diante, eu estava sempre recebendo: conexão recusou. Usei o tcpdump para ver o que eu estava recebendo e não havia muita informação. -g plus GatewayPorts sim fez o truque. - E.T