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

174

Bem, voltando a esta pergunta, estou executando o comando

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

em um Mac. No entanto, o porto que está sendo encapsulado não está funcionando publicamente. Estou executando esse comando para torná-lo de forma 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 no meu computador local, a porta não parece estar aberta. Como tornaria o túnel público no IP para alguém acessar?

EDIT: Parece que o lado remoto liga apenas no host local em vez de a todas as interfaces.

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

ssh ip openssh ssh-tunnel

— Trevor Rudolph
fonte

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

— harrymc

351

Se você verificar a página de manual para ssh, verá que a sintaxe para -Rlê:

-R [ bind_address :] porta : host : hostport

Quando bind_addressé omitido (como no seu exemplo), a porta é vinculada apenas à 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 apenas para 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 ::, 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 aspas, pois [::]poderia ser interpretado como um globo.)

Observe que, se você usar o sshdservidor OpenSSH , a GatewayPortsopção do servidor precisará ser ativada (configurada como yesou clientspecified) para que isso funcione (verifique o arquivo /etc/ssh/sshd_configno 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.

— Stefan Seidel
fonte

12

OH MEU DEUS TRABALHOU !!!!! Eu fiz exatamente isso 1 milhão de vezes !! Eu só esqueceu que *em bash dará arquivos e eu precisava\*

— Trevor Rudolph

4

Sim, isso é exatamente por isso que eu sempre prefiro 0.0.0.0- é apenas IPv4, mas ele vai fazer a maior parte do tempo :)

— Stefan Seidel

34

GatewayPorts sim resolveu meu problema.

— Sunry 25/10/16

4

GatewayPorts = yes (na configuração remota do sshd) também foi corrigido para mim #

— Phil_1984_

3

"GatewayPorts yes" fez o meu dia, obrigado @StefanSeidel

— karser 27/10

37

Editar:

-g funciona para portas encaminhadas locais, mas o que você deseja é uma porta encaminhada reversa / remota, que é diferente.

O que você quer é isso .

Essencialmente, em example.com, jogo GatewayPorts=clientspecifiedem /etc/ssh/sshd_config.

--- resposta anterior (incorreta) ---

Use a opção -g. Na página de manual do ssh:

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

— snapshoe
fonte

não parece estar funcionando ... ele é iniciado, mas não consigo conectar remotamente

— Trevor Rudolph

2

Tente executar a netstat -elnptpartir de um tty separado para descobrir quais portas estão vinculadas a qual endereço. Sem -g, uma porta deve estar vinculada a 127.0.0.1:PORT. Com -g, ele deve estar vinculado a 0.0.0.0:PORT, o que o torna acessível remotamente.

— snapshoe

pastebin.com/q6f4kJyd

— Trevor Rudolph

2

GatewayPorts=clientspecifiedouGatewayPorts clientspecified

— Trevor Rudolph

e eu adiciono isso ao cliente ou remoto?

— Trevor Rudolph

14

Aqui está a minha resposta para conclusão:

Acabei usando ssh -R ...para tunelamento, e socatalém 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 acho isso muito mais lento

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

— Miguel Ping
fonte

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

— BrutusCat

+ você vai bem senhor. Eu tentei dizer ao ssh para ligar para 0.0.0.0 sem sucesso .. então vi a sintaxe *, tentei isso, sem dados. Eu imagino que pode ser algum tipo de recurso de segurança na configuração do sshd ou algo que não está permitindo isso. Finalmente vi este post e socatfuncionou incrível. Super útil, colocando isso no meu bolso de trás;]

— Jaime

10

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

Primeiro encaminhe para a porta temporária (por exemplo, 10080) no dispositivo de loopback na máquina remota e use o encaminhamento 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"

— panticz.de
fonte

1

Isso realmente funciona para ignorar as regras de encaminhamento!

— Michael Schubert

Adoro esta solução. Grande solução alternativa quando você não quer que a mudança da configuração da máquina

— Grezzo

8

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

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

Para usar isso, você provavelmente precisará adicionar " GatewayPorts yes" aos seus servidores /etc/ssh/sshd_config.

— Raúl Salinas-Monteagudo
fonte

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

— ET

1

Os hosts de salto são uma adição relativamente recente ao OpenSSH. Isso requer acesso SSH ao intermediário, mas deve funcionar sem configuração adicional.

ssh -J root@example.com remoteuser@localhost -p 8080

Este comando instrui o SSH a primeiro conectar-se root@example.come, a partir dessa máquina, iniciar uma conexão com a porta 8080 na localhost(ou seja, a porta que é encapsulada do host de salto para o host remoto) sob o remoteusernome do usuário.

— krlmlr
fonte

0

Se você deseja colocar a configuração em você, em ~/.ssh/configvez de usar parâmetros de linha de comando, tente algo como

Host REMOTE_HOST_NAME RemoteForward \*:8080 127.0.0.1:80

Lembre-se de fazer com que o firewall do host remoto permita conexões ao 8080 e verifique se a GatewayPortsopção da sua /etc/ssh/sshdconfiguração não está definida comono

— Brad Mostert
fonte