Acesso SSH ao host do escritório atrás do roteador NAT

Gostaria de acessar a porta ssh do meu host linux do escritório em casa. Infelizmente, o host está localizado atrás de um roteador NAT. Portanto, o endereço IP não está disponível ao público. No entanto, existe acesso a outro host da Internet (servidor), que infelizmente é apenas o acesso não raiz. Depois de um tempo pesquisando, não encontro uma solução adequada.

Após a instalação:

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

Conexões possíveis: PC do escritório -> Servidor <- PC doméstico

Não é possível: PC do escritório <-X- Server -X-> PC doméstico

Nem o PC doméstico, nem o servidor podem iniciar o acesso ao PC do escritório. Mas o PC do Office e o PC doméstico podem iniciar conexões com o servidor.

Túnel SSH reverso não é possível: tentei um método chamado túnel ssh reverso. 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, inicio um programa de espaço de usuário que escuta em 2 portas (1 de entrada e 1 de saída)

1) No PC do meu escritório, eu executo outro programa que mantém uma conexão TCP aberta na porta de saída do servidor.

2) Em casa, conecto à porta de entrada do servidor.

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

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

Frank

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 é o seguinte: na etapa 1, encaminhe uma porta remota do PC do escritório para o servidor ( 12345é usado como exemplo, qualquer porta> 1024 deve fazer). Agora, a conexão com o 12345 no servidor deve conectá-lo à porta 22 no officepc.

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

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

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

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

Edit : Eu verifiquei isso com a mesma configuração e funciona. GatewayPorts noafeta apenas as portas abertas ao mundo em geral, não os túneis locais. É isso 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 (mais conexões ssh ao serverpc); portanto, GatewayPortsnão está marcado.

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

Advertências :

• se estiver usando autossh e ssh recente, convém usar ssh's ServerAliveIntervale ServerAliveCountMaxmanter o túnel ativo . O Autossh tem uma verificação interna, mas aparentemente tem alguns problemas no Fedora. -M0desativa isso e -oServerAliveInterval=20 -oServerAliveCountMax=3verifica se a conexão está ativa - tenta a cada 20 s, se falha 3x em uma linha, interrompe o ssh (e o autossh cria um novo):

  autossh -M0 -R 12345:localhost:22 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
  
  autossh -M0 -L 23456:localhost:12345 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
  

• pode ser útil reiniciar o túnel ssh se o encaminhamento falhar, usando -oExitOnForwardFailure=yes- se a porta já estiver ligada, você poderá obter uma conexão SSH funcionando, mas nenhum encapsulamento encaminhado.

• usar ~/.ssh/configpara as opções (e portas) é aconselhável; caso contrário, as linhas de comando ficam muito detalhadas. Por exemplo:

  Host fwdserverpc
      Hostname serverpc
      User notroot
      ServerAliveInterval 20
      ServerAliveCountMax 3
      ExitOnForwardFailure yes
      LocalForward 23456 localhost:12345
  

Então você pode usar apenas o alias do servidor:

    autossh -M0 fwdserverpc

Se você pode ssh para o servidor interno de casa e do servidor interno para a máquina Linux do escritório, em casa, você pode usar o ssh ProxyCommandpara saltar silenciosamente pelo 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ê ssh user@internalpce você são encaminhados silenciosamente pela máquina servidor, sem necessidade de abertura de portas ou túneis em nenhuma das extremidades.

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

• Isso permitirá que você acesse o SSH usando o Google Talk Client Apps 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 pagando mais serviços de aplicativos.
• Não é necessário abrir a porta SSH (mantenha seu computador seguro).
• Não é necessário abrir nenhum túnel (por exemplo, VPN ou algo assim)

As instruções de instalação a seguir estão obsoletas, à medida que o site foi movido. O novo URL é https://github.com/formigarafa/robotito

Eu criei um script (testado no meu Raspbian OS no Raspberry Pi) para que você possa instalar facilmente o Robo-TiTO no Raspberry Pi, Debian ou Ubuntu Box (distribuição de pacotes Debian). estas são as etapas para obter sua caixa do Linux 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 por 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.rbda pasta de configuração do Robo-TiTO usando sua conta GTalk e salvá-lo pressionando Ctrl+ Xe 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 foi feito, você pode usar o SSH de qualquer cliente do Google Talk. Não se esqueça de adicionar a conta Robo-TiTO GTalk à sua conta do Google Talk e testá-la conversando entre si antes de usar a conta.

A solução de Piskvor funciona e é legal. No entanto, mantém os terminais abertos, com as conchas de login penduradas. Não é muito legal.

Eu sempre usei esse pequeno script que escrevi para conectar-se 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 de Piskvor usando a autossh mais elegante ao lado de uma tela separada ou usar os argumentos -NT ssh para manter a conexão em segundo plano.

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