Como funciona o tunelamento SSH reverso?

Adoro explicar esse tipo de coisa por meio da visualização. 🙂

Pense em suas conexões SSH como tubos. Tubos grandes. Normalmente, você alcançará esses tubos para executar um shell em um computador remoto. O shell é executado em um terminal virtual (tty). Mas você já conhece esta parte.

Pense no seu túnel como um tubo dentro de um tubo. Você ainda tem a grande conexão SSH, mas a opção -L ou -R permite que você configure um tubo menor dentro dele.

Cada tubo tem um começo e um fim. O tubo grande, sua conexão SSH, começa com seu cliente SSH e termina no servidor SSH ao qual você se conectou. Todos os tubos menores têm os mesmos pontos de extremidade, exceto que a função de “início” ou “fim” é determinada pelo fato de você usar -L ou -R (respectivamente) para criá-los.

(Você não disse, mas vou assumir que a máquina “remota” que você mencionou, aquela atrás do firewall, pode acessar a Internet usando Network Address Translation (NAT). Isso é importante, então corrija esta suposição se for falsa.)

Ao criar um túnel, você especifica um anúncio vestido e porta em que atenderá, e um endereço e porta em que será entregue. A opção -L diz ao túnel para responder no lado local do túnel (o host que está executando seu cliente). A opção -R diz ao túnel para responder no lado remoto (o servidor SSH).

Então … Para ser capaz de fazer SSH da Internet em uma máquina atrás de um firewall, você precisa que a máquina em questão abra uma conexão SSH com o mundo externo e inclua um -R túnel cujo ponto de” entrada “é o lado” remoto “de sua conexão.

Dos dois modelos mostrados acima, você quer o da direita.

Do host com firewall:

ssh -f -N -T -R22222:localhost:22 yourpublichost.example.com 

Isso diz ao seu cliente para estabelecer um túnel com uma -R entrada de emote ponto. Qualquer coisa que se conecte à porta 22222 na extremidade do túnel alcançará a “porta 22 do localhost”, onde “localhost” é da perspectiva do ponto de saída do túnel (ou seja, seu cliente SSH).

As outras opções são:

• -f diz ao ssh para o próprio segundo plano após a autenticação, para que você não precise ficar sentado executando algo no servidor remoto para que o túnel permaneça ativo.
• -N diz que você deseja uma conexão SSH, mas na verdade não deseja executar nenhum comando remoto. Se tudo o que você está criando for um túnel, incluir esta opção economiza recursos.
• -T desativa a alocação de pseudo-tty, o que é apropriado porque você não está tentando criar um shell interativo.

Haverá um desafio de senha, a menos que você tenha configurado as chaves DSA ou RSA para um login sem senha.

Observe que é FORTES recomendado que você use uma conta descartável (não seu próprio login) que você configurou apenas para este túnel / cliente / servidor.

Agora, do seu shell em yourpublichost , estabeleça uma conexão com o host protegido por firewall através do túnel:

ssh -p 22222 username@localhost 

Você “ll obtenha um desafio-chave de host, pois provavelmente você nunca atingiu esse host antes. Em seguida, você receberá um desafio de senha para a conta username (a menos que você tenha configurado chaves para login sem senha).

Se você vai acessar este host regularmente, também pode simplificar o acesso adicionando algumas linhas ao seu arquivo ~/.ssh/config:

host remotehostname User remoteusername Hostname localhost Port 22222 

Ajuste remotehostname e remoteusername para se adequar. O remoteusername o campo deve corresponder ao seu nome de usuário no servidor remoto, mas remotehostname pode ser qualquer nome de host adequado a você, não precisa corresponder a nada resolvível.

Veja também:

• Exponha o endpoint reverso em um non-localhost IP
• Dicas sobre como usar ControlMaster para manter seu túnel

Comentários

• e o ssh -D. Explique usando o mesmo método.
• Proxies SOCKS não são o mesmo que túneis. Se você tiver alguma dúvida sobre como usá-los, pergunte .
• Eu ‘ estou tendo muita dificuldade em seguir esta explicação devido ao uso vago dos termos: servidor, cliente, máquina local, máquina remota, host, yourpublichost, localhost, remotehostname. Com todos esses termos vagos e indefinidos, pode-se presumir que alguém precisaria de até 8 computadores para configurar isso. Afirmo isso porque em todos os outros aspectos parece uma explicação muito boa. Reduza e defina os termos.
• @ Rucent88, I ‘ m não tenho certeza de qual redução seria possível. Um cliente estabelece uma conexão com um servidor. Essa ‘ é a terminologia comum em todo o mundo das redes. Máquinas locais e remotas parecem bastante evidentes. Se você ‘ ficar confuso sobre SSH ou terminologia unix geral depois de ler a documentação, ‘ tenho certeza que ‘ Não terei problemas para encontrar pessoas aqui dispostas a responder a qualquer pergunta que você possa ter.
• @ghoti É ‘ realmente confuso, porque local e as máquinas remotas são relativas. Quando estou no local de trabalho, meu computador doméstico é o remoto; quando estou em casa, o computador do local de trabalho é remoto. Servidor e cliente também são confusos quando se fala em encapsulamento. Por exemplo, se eu me conectar a casa do trabalho com ssh -R. Eu me conecto ao meu trabalho a partir do computador doméstico, conectando o localhost. Portanto, da perspectiva dos soquetes, o servidor é o próprio computador doméstico. Mas logicamente me conectei ao meu computador de trabalho. Isso ‘ é confuso.

Eu desenhei alguns esboços

A máquina onde o comando de túnel ssh é digitado é chamada »seu host« .

Introdução

1. local: -L Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.

   ssh -L sourcePort:forwardToHost:onPort connectToHost significa: conectar com ssh a connectToHost e encaminhar todas as tentativas de conexão para o local sourcePort para a porta onPort na máquina chamada forwardToHost, que pode ser alcançado a partir da connectToHost máquina.

2. remoto: -R Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side.

   ssh -R sourcePort:forwardToHost:onPort connectToHost significa: conectar-se com ssh a connectToHost, e encaminhar todas as tentativas de conexão para o remoto sourcePort para a porta onPort na máquina chamada forwardToHost, que pode ser acessada em sua máquina local.

Opções adicionais

• -f diz ao ssh para se colocar em segundo plano após a autenticação, então você não precisa ficar sentado executando algo no servidor remoto para que o túnel permanecer vivo.
• -N diz que você deseja uma conexão SSH, mas na verdade não deseja executar nenhum comando remoto. Se tudo o que você está criando for um túnel, incluir esta opção economiza recursos.
• -T desativa a alocação de pseudo-tty, o que é apropriado porque você não está tentando criar um shell interativo.

Seu exemplo

A terceira imagem representa este túnel. Mas o computador azul chamado »seu host« representa o computador onde alguém inicia o túnel ssh, neste caso, a máquina com firewall.

Então, peça a alguém para iniciar uma conexão de túnel ssh para sua máquina. O comando deve ser basicamente semelhante a

ssh -R 12345:localhost:22 YOURIP 

Agora o túnel está aberto.Agora você pode se conectar via ssh à máquina com firewall através do túnel com o comando

ssh -p 12345 localhost 

que se conectará ao seu próprio localhost (sua máquina) na porta 12345, mas a porta 12345 é encaminhada através do túnel para a porta 22 do localhost do firewall computador (ou seja, o próprio computador com firewall).

Comentários

• @erik, Como você desenhou essas imagens?
• I usei a ferramenta de desenho vetorial de código aberto chamada Inkscape e meu mouse (bem, na verdade é um trackball: Marble FX da Logitech).
• @ghoti: Por padrão, o soquete de escuta no servidor (em minha imagem -R o host remoto amarelo) será vinculado apenas à interface de loopback. Isso pode ser substituído especificando um bind_address. Um bind_address vazio ou o endereço ‘*’ indica que o soquete remoto deve escutar em todas as interfaces. – Então, experimente: em um computador azul, inicie ssh -R 1234:localhost:8000 yellowcomputer. E também na máquina azul, inicie python -m SimpleHTTPServer (um servidor web simples na porta 8000). Então, em um navegador da web na máquina amarela, abra a URL http://localhost:1234 e você verá que funciona.
• @erik, ah, a parte confusa é porque meus olhos estão ruim – eu não estava ‘ vendo o espaço antes de remotehost em seus comandos. Após uma inspeção mais detalhada, vejo que seus diagramas não ‘ realmente abordam o bind_address opcional. Desculpe a confusão.
• @briankip Sim, claro. Pelo menos se você quiser fazer uma conexão ssh com o computador atrás do firewall (através do túnel ou diretamente, se o firewall permitir). Isto é: O comando ssh que você escreve no computador com firewall apenas abre um túnel, mas não inicia ou funciona como um ssh-daemon / -server. Sua próxima pergunta deve ser, como iniciar um sshd sem privilégios de root (se esse for o seu problema). 🙂

O tunelamento ssh funciona usando a conexão ssh já estabelecida para enviar tráfego adicional.

Quando você se conecta a um servidor remoto, geralmente tem apenas 1 canal para a interação normal do usuário (ou 3 canais se você considerar STDIN / STDOUT / STDERR separados). A qualquer momento, o processo ssh local ou remoto pode abrir canais adicionais na conexão existente. Esses canais então enviam / recebem o tráfego do túnel. Ao enviar ou receber qualquer tráfego, o processo ssh simplesmente diz “este tráfego é para o canal foobar”.

Funciona basicamente assim:

1. Você diz ao ssh para começar a escutar na porta XXXX e que qualquer tráfego recebido deve ser encapsulado e, em seguida, definido como YYYY na porta ZZZZ.
2. O ssh local começa a escutar na porta XXXX (geralmente em 127.0.0.1, mas pode ser alterado).
3. Alguns aplicativos abrem uma conexão para a porta XXXX na máquina local.
4. O ssh local abre um canal para o ssh remoto e diz “qualquer tráfego neste canal vai para YYYY: ZZZZ
5. O ssh remoto se conecta a YYYY: ZZZZ e envia de volta o “OK, o canal está aberto”
6. Agora, qualquer tráfego enviado ao longo da conexão para a porta XXXX na máquina local é proxy por ssh para YYYY: ZZZZ.

Este processo é exatamente o mesmo para o túnel direto e reverso (basta trocar as palavras “local” e “remoto” em o procedimento acima). Qualquer um dos lados pode iniciar o túnel. nem precisa ser quando você inicia o ssh. Você pode abrir túneis enquanto o ssh já está em execução (consulte ESCAPE CHARACTERS, especificamente ~C).

Para a função de -R, -f, -L e -N, você realmente deve apenas consultar a página de manual, ela lhe dá a melhor explicação possível. Mas vou mencionar -R e -L.
-R diz ao SSH remoto para ouvir as conexões e que o ssh local deve se conectar ao destino real. -L diz ao ssh local para ouvir as conexões e que o ssh remoto deve se conectar ao destino real.

Observe, esta é uma descrição muito rudimentar, mas deve fornecer informações suficientes para saber o que está acontecendo

Isso é explicado no manual SSH, especialmente as diferenças entre -L (local) e -R (remoto).

-L

-L [bind_address:]port:host:hostport

Especifica que a determinada porta no host local (cliente) deve ser encaminhada para o determinado host e porta no lado remoto .

Isso funciona alocando um soquete para ouvir a porta no lado local, opcionalmente vinculado ao bind_address especificado.

Sempre que uma conexão é feita a esta porta, a conexão é encaminhada pelo canal seguro e uma conexão é feita para host port hostport da máquina remota .

O exemplo a seguir canaliza uma sessão IRC da máquina cliente 127.0.0.1 (localhost) usando a porta 1234 para o servidor remoto server.example.com:

$ ssh -f -L 1234:localhost:6667 server.example.com sleep 10 

^{Observação: a opção -f backgrounds ssh e o comando remoto sleep 10 são especificados para permitir um certo tempo para iniciar o serviço que deve ser tunelado.}

Exemplo:

ssh `-N` -L 22000:localhost:11000 remote.server.com 

• -N Depois de se conectar, basta aguardar (você não receberá um prompt do shell)

  Não execute um comando remoto.

• -L 22000 A conexão será originada na porta 22000 do seu pessoal, L máquina ocal

• localhost:11000 – remote.server.com garantirá que a outra extremidade do túnel seja localhost, porta 11000

^{Fonte: Um guia ilustrado, tutorial e instruções sobre tunelamento ssh .}

-R

-R [bind_address:]port:host:hostport

Especifica que a porta fornecida no host remoto (servidor) deve ser encaminhada para o g host e porta do lado local .

Isso funciona alocando um soquete para ouvir port em o lado remoto, e sempre que uma conexão é feita a esta porta, a conexão é encaminhada pelo canal seguro e uma conexão é feito para host porta hostport da máquina local .

Exemplo:

ssh -N -R 22000:localhost:11000 remote.server.com 

• -N Depois de conectar, basta aguardar (você não receberá um prompt do shell)

  Não execute um comando remoto.

• -R 22000 A conexão será iniciada na porta 22000 do R computador emote (neste caso, remote.server.com)

• seu computador pessoal local garantirá que a outra extremidade do túnel seja localhost, porta 11000

^{Fonte: Um guia ilustrado, tutorial e instruções sobre tunelamento ssh .}

Comentários

• o ouvido e a boca deixam bem claro quem ‘ está falando e quem ‘ está ouvindo!
• Adoro suas ilustrações!

A vinculação às interfaces de rede ao estabelecer túneis SSH reversos é explicada nesta postagem . Aqui está um exemplo com 4 computadores residindo em duas redes diferentes: