ssh singularidade de tunelamento

Question

Este exemplo está relacionado ao MongoDB, mas o problema principal é com o tunelamento SSH, o material do MongoDB deve agregar valor embora

Oi,

Estou tentando criar um nó MongoDB local que faz parte de um ReplicaSet com base em um datacenter. O TCP / IP será encapsulado por SSH de local para data center.

Todas as caixas, local e data center, estão rodando o CentOS.

Isso funciona bem ao criar um túnel na caixa 1 do data center para o nó local usando:

ssh -v -4 -f -N -o TCPKeepAlive=no -o ServerAliveInterval=15 -L27017:127.0.0.1:27017 -g a_user@server_i_have_ssh_access_to

box1 pode acessar o nó local do shell Mongo com o comando ( cmd 1 ):

mongo --host localhost --port 27017

box2 também pode acessar o nó local do shell Mongo com o comando ( cmd 2 ):

mongo --host box1 --port 27017

box2 no datacenter também pode se conectar à caixa1: 27017, a porta encaminhada do meu nó local.

no entanto, seria muito preferível, mais simples, e deveria ser possível configurar um avanço inverso entre o nó local e o box1 nas mesmas portas acima. Usando o comando:

ssh -v -4 -f -N -o TCPKeepAlive=no -o ServerAliveInterval=15 -R27017:127.0.0.1:27017 -g a_user@box1

agora posso conectar-me da caixa 1 ao nó local usando cmd 1 acima, no entanto, cmd 2 falha com:

Error: couldn't connect to server box1:27017} (anon):1139 exception: connect failed

Alguma idéia?

    

Answer 1

Por padrão, -R apenas escuta na interface de loopback (o padrão para -L é todas as interfaces). Portanto, o cmd1 funciona porque está sendo executado localmente na caixa1, mas o cmd2 falha porque está sendo executado na caixa2. A correção é alterar -R para um dos seguintes:

-R:27017:127.0.0.1:27017
-R'*:27017:127.0.0.1:27017'

    

Answer 2

Tudo o que posso pensar é que o TCP Wrappers ou alguma outra autenticação está falhando. Qualquer coisa em /var/log/auth.log se é um sistema operacional baseado em Debian ou similar?