Acesso SSH ao host do office por trás do roteador NAT

Question

Eu gostaria de acessar a porta ssh do meu host linux office de casa. Infelizmente, o host está localizado atrás de um roteador NAT. Portanto, o endereço IP não está disponível publicamente. No entanto, há acesso a outro host da Internet (Servidor), que infelizmente é apenas o acesso não-root. Depois de um tempo de pesquisa, não encontro uma solução adequada.

Após a configuração:

• Office PC (linux, acesso root) por trás do NAT (IP não público), mas com acesso total à Internet.
• Servidor PC (linux, sem acesso root) IP estático e público e acesso total à Internet.
• PC doméstico (linux, acesso raiz) por trás do NAT (IP não público), mas com acesso total à Internet.

Possíveis conexões: PC do Office - > Servidor < - Home PC

Não é possível: Office PC < -X- Server -X- > PC em casa

Nem o Home PC nem o Server podem iniciar o acesso ao Office PC. Mas tanto o Office PC como o Home PC podem iniciar conexões com o servidor.

Túnel SSH reverso não é possível: Eu tentei um método chamado reverso ssh-tunnel. Infelizmente isso requer GatewayPorts no servidor definido como "yes" em / etc / ssh / sshd_config, onde não tenho acesso root.

Em princípio, deve ser possível:

0) No servidor eu inicio um programa de espaço do usuário que escuta em 2 portas (1 entrada, 1 saída)

1) No PC do meu escritório eu corro um outro programa que mantém uma conexão TCP aberta para a porta de saída no servidor.

2) A partir de casa, conecto-me à porta de entrada do servidor.

Deveria haver uma solução padrão para isso lá fora.

Qual é a solução mais rápida e mais limpa para resolver isso?

Frank

    

Answer 1

youatwork@officepc$ autossh -R 12345:localhost:22 notroot@serverpc

Mais tarde:

you@homepc$ autossh -L 23456:localhost:12345 notroot@serverpc

you@homepc$ ssh youatwork@localhost -p 23456

O que você pode fazer é: na etapa 1, encaminhar uma porta remota do PC do escritório para o servidor ( 12345 é usado como exemplo, qualquer porta > 1024 deve ser usada). Agora, conectar-se ao 12345 no servidor deve conectá-lo à porta 22 no officepc.

Na etapa 2, encaminhe a porta 23456 da sua máquina de casa para 12345 no servidor (de onde ela é encaminhada para o officepc: 22, como configurado na etapa 1)

No passo 3, você se conecta à porta local 23456 com seu login no PC do escritório . Isso é encaminhado pela etapa 2 para a porta 12345 em seu servidor e pela etapa 1 para o PC do escritório.

Note que estou usando o autossh para os encaminhamentos, já que é um wrapper ssh que reconecta automaticamente o túnel caso ele seja desconectado; no entanto, o ssh normal também funcionaria, desde que a conexão não caia.

Existe uma possível vulnerabilidade: qualquer um que pode se conectar ao localhost: 12345 no serverpc agora pode se conectar ao officepc: 22 e tentar invadir o servidor. (Note que se você estiver executando um servidor SSH, você deve protegê-lo acima das proteções básicas que estão ativadas por padrão; eu recomendo pelo menos desabilitar o login root e desabilitar a autenticação de senhas - veja por exemplo is )

Editar : verifiquei isso com a mesma configuração e funciona. GatewayPorts no afeta apenas as portas que estão abertas para o mundo em geral, não para os túneis locais. Isso é o que as portas encaminhadas são:

homepc:
  outgoing ssh to serverpc:22
  listening localhost:23456 forwarded through ssh tunnel
serverpc:
  listening ssh at *:22
  incoming localhost ssh tunnel (from homepc) forwarded to localhost:12345
  listening localhost ssh tunnel (from officepc) forwarded from localhost:12345
officepc:
  outgoing ssh to serverpc:22
  incoming localhost through ssh tunnel (from serverpc) forwarded to localhost:22

Portanto, no que diz respeito à pilha de rede, é todo o tráfego local nas respectivas interfaces de loopback (além de conexões ssh para serverpc); portanto, GatewayPorts não está verificado.

Existe, no entanto, a diretiva AllowTcpForwarding : se for no , essa configuração falhará, pois nenhum encaminhamento é permitido, nem mesmo na interface de loopback.

    

Answer 2

Se você puder ssh para o servidor interno a partir de casa e do servidor interno para a máquina Linux do seu escritório, em casa você pode usar o ssh ProxyCommand para saltar silenciosamente através do servidor para a máquina interna via nc ( netcat)

# ~/.ssh/config on your home machine:
Host internalpc 
   ForwardAgent yes 
   ProxyCommand ssh [email protected] exec nc internal.pc.example.com %p

Então você apenas ssh user@internalpc e você é silenciosamente encaminhado através da máquina do servidor, sem abertura de portas ou túneis necessários em ambas as extremidades.

    

Answer 3

Instale o Robo-TiTO no computador em que você deseja acessar o SSH remotamente.

• Isso permitirá que você acesse o SSH usando aplicativos do Google Talk Client em qualquer lugar.
• Não há necessidade de um endereço IP público ou configuração especial.
• É gratuito e de código aberto, não está mais pagando nenhum serviço de aplicativos.
• Não há necessidade de abrir a porta SSH (mantenha seu computador seguro).
• Não é necessário abrir nenhum túnel (por exemplo, VPN ou algo parecido)

As instruções de instalação a seguir estão obsoletas, conforme o site foi movido. O novo URL é o link

I made a script (tested on my Raspbian OS in Raspberry Pi) so you can easily install Robo-TiTO on Raspberry Pi, Debian or Ubuntu Box (Debian package distribution). this is the steps to get your Linux box remoteable:

1. Abra o Shell Command ou você pode chamá-lo de Terminal, vá para a sua pasta pessoal, Faça o download do script do instalador pelo comando:

   $ wget https://opengateway.googlecode.com/files/robotito
   

2. depois disso, execute o script digitando o comando:

   $ sudo ./robotito
   

3. e você pode editar o arquivo credentials.rb da pasta de configuração do Robo-TiTO usando sua conta do GTalk e salvá-lo pressionando Ctrl + X e Y . O padrão é usar o editor nano.

4. executando o Robo-TiTO da pasta Robo-TiTO por comando

   $ cd robotito
   $ ./jabbershd start
   

5. Agora que isso é feito, você pode usar o SSH em qualquer cliente de conversação do Google. Não se esqueça de adicionar a conta Robo-TiTO GTalk à sua conta de conversação do Google e testá-la conversando antes de usar a conta.

Answer 4

A solução da Piskvor funciona e é legal. No entanto, ele mantém terminais pendurados abertos com shells de login pendurados. Não é muito legal.

Eu sempre usei esse pequeno script que escrevi para conectar a um servidor e mantê-lo conectado, executando-o no cron:

#!/bin/bash
TARGET_HOST=${1:-myserver.example.com}
TARGET_PORT=${2:-7777}
TUNNEL_PORT=${3:-22}
T_USER="odin"

#Check that we have an active connection to the remote system
ACTIVE_PROCESS='ps -ef | \
    grep "ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT" | \
    grep -v grep | \
    wc -l'
if [ $ACTIVE_PROCESS -lt 1 ]; then
    echo "'date' : establishing connection to $TARGET_HOST on port $TARGET_PORT"
    screen -m -d ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT > /dev/null
fi

Aposto que poderíamos consertar a solução do Piskvor usando o mais elegante autossh ao lado de uma tela separada ou usar os argumentos -NT ssh para manter a conexão em segundo plano.

    

Answer 5

Para mim, parece que, em vez de um túnel SSH, você deve tentar uma VPN: o tipo que funciona usando um servidor do lado de fora para fazer proxy, como Hamachi . Existem outros softwares gratuitos como este, mas o Hamachi é meu fav.