autossh não funciona para dois ou mais túneis - ou existe uma alternativa?

Question

Estou tentando usar um servidor SSH como um gateway para conectar a mais de um servidores internos. Interno neste contexto significa que eles não são acessíveis diretamente, eles não receberam nenhum IP público atribuído a eles.

Assim o cenário deve ficar assim (exemplo com 2 servidores, pode ser mais) com os gateways públicos IP 123.456.789.45 sendo o interno 10.12.40.13

+--------+                 +---------+                +----------+
| client |--> 2214/tcp --> |         | --> 22/tcp --> | Server 1 |
+--------+                 |         |                +----------+
                           | Gateway |
+--------+                 |         |                +----------+
| client |--> 2215/tcp --> |         | --> 22/tcp --> | Server 2 |
+--------+                 +---------+                +----------+

Minha primeira abordagem foi configurá-los do gateway para os servidores com algo como

ssh -N -L 123.456.789.45:2214:127.0.0.1:22 tunnel-user@server1
ssh -N -L 123.456.789.45:2215:127.0.0.1:22 tunnel-user@server2

Enquanto isso funciona, eu me deparei com o problema de os túneis não serem muito confiáveis, falhando em cada aqui e ali. O próximo passo lógico foi tentar obter autossh em execução. E aqui eu tenho um monte de problemas. O primeiro túnel pode ser estabelecido sem problemas usando

autossh -M 20000 -f -N -L 123.456.789.45:2214:127.0.0.1:22 tunnel-user@server1

Eu posso ter acesso ao servidor1 por conexão externa ao gateway na porta 2214. No entanto, não consigo fazer o segundo funcionar com o autossh. Batendo cabeça algumas horas agora eu decidi tentar, vice-versa. Então:

A segunda abordagem foi configurá-los dos servidores para o gateway . Novamente, enquanto a variante com o ssh puro funciona usando algo assim ...

ssh -R 123.456.789.45:2214:127.0.0.1:22 tunnel-user@gateway # <- init from server 1
ssh -R 123.456.789.45:2215:127.0.0.1:22 tunnel-user@gateway # <- init from server 2

... usando o autossh falha.

autossh -M 20000 -f -R 123.456.789.45:2214:127.0.0.1:22 tunnel-user@gateway

Os arquivos de log simplesmente não dizem nada. Syslog, pelo menos, vem com

ssh exited prematurely with status 0; autossh exiting

Agora alguém sabe como resolver o problema de autossh em qualquer abordagem? Existe algo semelhante a autossh que eu posso dar uma chance? Existe uma maneira de talvez conseguir algo como uma atualização na versão ssh pura mencionada acima?

Todos os servidores envolvidos estão executando as atualizações mais recentes no Ubuntu 10.04 LTS e no autossh 1.4b

    

Answer 1

Eu usei uma abordagem diferente para resolver esse problema. No começo eu consegui iniciar os túneis SSH dos clientes no momento da inicialização. Eu escrevi um script init.d para isso, fiz dele um serviço e deixei o fantoche lidar com isso.

No entanto, isso foi muito trabalhoso e decidi me virar e usar o NAT e o encaminhamento de porta pelo servidor gateway e sua configuração UFW. Mesmo que não seja uma resposta para o problema SSH em si, aqui está a solução que corrigiu o problema básico:

Em /etc/ufw/sysctl ativado net/ipv4/ip_forward=1 e em sysctl -p

Em /etc/ufw/before.rules

*nat
:POSTROUTING ACCEPT [0:0]

# forward traffic from eth1 through eth0
-A POSTROUTING -s 10.12.40.0/24 -o eth0 -j MASQUERADE

# some DNAT rules
-A PREROUTING -i eth0 -p tcp --dport 2214 -j DNAT --to-destination 10.12.40.14:22
-A PREROUTING -i eth0 -p tcp --dport 2215 -j DNAT --to-destination 10.12.40.15:22

#
COMMIT

e executou ufw disable && ufw enable . Tudo o que era necessário era verificar o roteamento correto no cliente.

Diferente abordagem, queria resultado. Obrigado a todos por lerem e pensarem sobre o meu problema e @assassi : darei sua sugestão com o OpenVPN no momento em que eu tiver mais tempo e a necessidade de mais do que a porta SSH.

    

Answer 2

Na documentação do autossh:

autossh uses ssh to construct a loop of ssh forwardings (one from local to remote, one from remote to local), and then sends test data that it expects to get back.

-M port[:echo_port] specifies the base monitoring port to use. Without the echo port, this port and the port immediately above it ( port + 1) should be something nothing else is using. autossh will send test data on the base monitoring port, and receive it back on the port above. For example, if you specify "-M 20000", autossh will set up forwards so that it can send data on port 20000 and receive it back on 20001.

se você estiver usando -M 20000 duas vezes, isso deve falhar. Use portas diferentes para isso (com um espaço de porta entre elas, então -M 20000 e -M 20002 funcionariam). Eu recomendo fazer um "man autossh" e ler a documentação do autossh, também disponível on-line: link . Se você estiver usando muitos túneis autossh, você pode configurar um serviço de eco dedicado (Da documentação do autossh novamente):

Alternatively, a port for a remote echo service may be specified. This should be port 7 if you wish to use the standard inetd echo service. When an echo port is specified, only the specified monitor port is used, and it carries the monitor message in both directions. This allows the autossh to verify the connection without blocking ports for each tunnel on the remote side.

Se você quiser usar o xinetd para isso, aqui está minha decleration de serviço de eco:

service echo
{
        flags                   = REUSE
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/bin/cat
        log_on_failure          += USERID
        only_from               = 127.0.0.1
        disable                 = no
}

você pode usar -M 20000: 7 em todos os túneis de máquinas diferentes. se você tiver vários tunnelns em uma máquina, use várias opções -L ou -R ou use uma porta diferente como -M 20002: 7

    

Answer 3

Você pode especificar os dois túneis no mesmo comando ssh.

ssh -R 123.456.789.45:2214:127.0.0.1:22 -R 123.456.789.45:2215:127.0.0.1:22 tunnel-user@gateway

Ou você pode tentar adicionar túneis em um .ssh / config assim, então a linha de comando não ficou muito lotada:

host server1
        RemoteForward 123.456.789.45:2214:127.0.0.1:22
        RemoteForward 123.456.789.45:2215:127.0.0.1:22

    

Answer 4

não sabe sobre o autossh ....

mas por que você não tenta a opção de configuração ssh ProxyCommand? ( link )

você precisaria configurar o .ssh / config nos clientes assim:

Host Server1
    HostName Server1
    ProxyCommand ssh gateway:2214 nc %h %p 2> /dev/null

boa sorte!

    

Answer 5

Você pode configurar vários túneis no arquivo de configuração do autossh . Infelizmente não está muito bem documentado. Para dois túneis, com seus dados e com base no PubkeyAuthentication, eu faria assim (SuSE 11 SP 4):

    In /etc/sysconfig/autossh

    # Number of autossh instances to spawn on start.
    AUTOSSH_SPAWNS="3"

    # All options except for the first must end with "_<number>"

    AUTOSSH_OPTIONS_1="tunnel-user1@server1 \
    -i /home/tunnel-user1/.ssh/id_rsa \
    -M 0 -f -N -L2214:127.0.0.1:22 -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=60 -o ServerAliveCountMax=3 
    -o StrictHostKeyChecking=no"

    AUTOSSH_OPTIONS_2="tunnel-user2@server2 \
    -i /home/tunnel-user2/.ssh/id_rsa \
    -M 0 -f -N -L2215:127.0.0.1:22 -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=60 -o ServerAliveCountMax=3
    -o StrictHostKeyChecking=no"

É claro que todo o resto relacionado a uma conexão ssh bem-sucedida com as chaves deve estar em vigor

• chaves de pub de usuários de encapsulamento nos servidores /home/tunnel-user[1|2]/.ssh/authorized_keys files
• o usuário do túnel deve existir nos gateways e servidores
• e ser configurado em /etc/ssh/sshd_config
• no sshd_config AllowTcpForwarding do gateway deve ser definido yes , bem como PermitTunnel