É possível o SSH acessar um servidor com uma sub-rede configurada incorretamente?

17

Temos um servidor onde um de nossos engenheiros configurou mal a sub-rede e agora estamos bloqueados neste servidor e o único acesso que conheço é um console serial da IDC (significa pedir a um engenheiro da IDC para nos ajudar com isso).

O que foi mal configurado:

address 192.168.1.9 # Original address there was
netmask 255.255.255.254 # Misconfigured, originally should've been .240

Por curiosidade - existe uma maneira de evitar chamar o IDC e de alguma forma se conectar a este host através do SSH (então podemos corrigir a configuração)?

    
por Alexey Kamenskiy 15.04.2015 / 08:01

3 respostas

24

Você precisa fazer login em outro host no mesmo segmento de rede. Algumas das maneiras de obter acesso ao host configurado incorretamente requerem raiz no host intermediário, mas também há uma maneira fácil de obter acesso sem precisar de raiz no host intermediário.

A maneira fácil de acessar o host usando o IPv6

ssh -o ProxyCommand='ssh -W [fe80::42:ff:fe:42%%eth0]:%p user@intermediate-host' root@target-server

Os seguintes valores de exemplo no comando acima precisam ser substituídos pelos valores corretos para seu caso de uso: fe80::42:ff:fe:42 , eth0 , user , intermediate-host e target-server .

Explicação detalhada de como funciona

ProxyCommand é um recurso ssh a ser usado quando você não consegue abrir uma conexão TCP diretamente no host de destino. O argumento para ProxyCommand é um comando cujo stdin / stdout deve ser usado em vez de uma conexão TCP.

-W é usado para abrir um único encaminhamento de porta e conectá-lo a stdin / stdout. Isso se encaixa bem com ProxyCommand .

fe80::42:ff:fe:42%%eth0 é o endereço de link local do host de destino. Observe que, devido a ProxyCommand usando % como caractere de escape, o comando ssh digitado deve usar %% nesse local. Você pode encontrar todos os endereços locais de link no segmento executando ssh user@intermediate-host ping6 -nc2 ff02::1%eth0 .

O uso de endereços locais de vínculo IPv6 para essa finalidade geralmente é a maneira mais fácil, pois é habilitado por padrão em todos os sistemas modernos, e os endereços locais de link continuam funcionando, mesmo que as pilhas IPv4 e IPv6 estejam gravemente configuradas incorretamente.

Voltando ao IPv4

Se o IPv6 estiver completamente desativado no host mal configurado (absolutamente não recomendado), talvez seja necessário recorrer ao uso do IPv4. Como o IPv4 não possui endereços locais vinculados, a maneira como o IPv6 acessa o host configurado incorretamente usando IPv4 fica mais complicado e precisa de acesso root no host intermediário.

Se o host configurado incorretamente ainda puder usar seu gateway padrão, você poderá acessá-lo de fora. Possivelmente, a máscara de rede configurada incorretamente também quebrou o gateway padrão devido à pilha se recusar a usar um gateway fora do prefixo coberto pela máscara de rede. Se este é realmente o caso, o host configurado incorretamente só será capaz de se comunicar com 192.168.1.8 porque esse é o único outro endereço IP na sub-rede atualmente acessível para este host mal configurado.

Se você tem um login em 192.168.1.8, você pode simplesmente fazer o ssh de lá para 192.168.1.9. Se 192.168.1.8 estiver atualmente desassinado, você poderá atribuí-lo temporariamente a qualquer host no segmento no qual você tem acesso root.

    
por 15.04.2015 / 08:41
9

kasperd postou uma ótima resposta detalhada o suficiente para eu aprender como posso me recuperar da situação na pergunta. Esta resposta é o passo-a-passo exato de como eu fiz isso.

  1. SSH para servidor na mesma rede física
  2. Usando arp -a ou ip neighbor list como root , localize o endereço MAC do servidor mal configurado.
  3. Usando o MAC para o conversor de link local encontre o link-local para o servidor mal configurado
  4. Agora, o SSH pode ser servidor como qualquer usuário via ssh user@link-local%dev , onde:
    • usuário - nome de usuário para o qual temos permissão para SSH
    • link-local - endereço IPv6 auto-atribuído recuperado na etapa 3
    • dev é a interface física em que esse servidor pode ser acessado (por exemplo, eth0)
por 15.04.2015 / 09:40
2

Você precisa carregar um endereço IP dentro da sub-rede configurada do seu destino, não apenas dentro do intervalo que você realmente deseja.

Se você enviar um pacote para 10.0.0.2 com a sub-rede 255.255.255.248 de, por exemplo, 10.0.0.220, 10.0.0.2 examinará sua máscara de sub-rede para descobrir como responder. Como 0,220 é WAAY fora da sub-rede 255.255.255.248, o .2 tem que enviar a resposta para o gateway padrão.

Então, se você pode carregar um endereço IP dentro da mesma sub-rede como .2, por exemplo. 10.0.0.3, então funcionará.

No seu caso específico, para 10.0.0.9, a sub-rede 255.255.255.254 tem apenas 1 endereço IP adicional , a saber, 10.0.0.8. Então, se você pode carregar esse endereço IP, você deve ser capaz de SSH.

    
por 15.04.2015 / 09:18