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

Temos um servidor no qual um de nossos engenheiros configurou mal a sub-rede e agora estamos bloqueados neste servidor e o único acesso que eu sei que funcionaria é um console serial da IDC (isso significa pedir a um engenheiro da IDC que nos ajude com isso) .

O que foi configurado incorretamente:

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 ligar para a IDC e de alguma forma conectar-se a esse host pelo SSH (então podemos corrigir a configuração)?

Você precisa fazer logon 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 a necessidade de raiz no host intermediário.

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

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

Os seguintes valores de exemplo em necessidade comando acima para ser substituído com os valores corretos para o 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 pode abrir uma conexão TCP diretamente no host de destino. O argumento to 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 ao stdin / stdout. Isso se encaixa muito bem com ProxyCommand.

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

O uso de endereços locais de link IPv6 para essa finalidade geralmente é a maneira mais fácil, pois é ativado por padrão em todos os sistemas modernos, e os endereços locais de link continuam funcionando mesmo se as pilhas IPv4 e IPv6 estiverem severamente mal configuradas.

Voltando ao IPv4

Se o IPv6 estiver completamente desativado no host configurado incorretamente (absolutamente não recomendado), talvez seja necessário recorrer ao IPv4. Como o IPv4 não possui endereços locais de link, da mesma forma que o IPv6, o acesso ao host configurado incorretamente usando o IPv4 fica mais complicado e precisa de acesso root no host intermediário.

Se o host mal configurado ainda pudesse usar seu gateway padrão, você poderia acessá-lo de fora. Possivelmente, a máscara de rede mal configurada 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 esse for realmente o caso, o host configurado incorretamente somente poderá se comunicar com 192.168.1.8 porque esse é o único outro endereço IP na sub-rede atualmente acessível a esse host configurado incorretamente.

Se você tiver um logon em 192.168.1.8, poderá ser capaz de ssh de lá para 192.168.1.9. Se 192.168.1.8 não estiver atribuído no momento, você poderá atribuí-lo temporariamente a qualquer host no segmento em que você tiver acesso root.

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

1. SSH para servidor na mesma rede física
2. Usando arp -aou ip neighbor listcomo rootencontrar o endereço MAC do servidor configurado incorretamente.
3. Usando o MAC para converter o link-local, encontre o link-local para o servidor configurado incorretamente
4. Agora o SSH pode ser servidor como qualquer usuário via ssh user@link-local%devonde:
   • user - 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 é uma interface física da qual este servidor pode ser acessado (por exemplo, eth0)

Você precisa carregar um endereço IP na 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 .220 está WAAY fora da sub-rede 255.255.255.248, .2 precisa enviar a resposta ao gateway padrão.

Portanto, se você pode carregar um endereço IP na mesma sub-rede que .2, por exemplo. 10.0.0.3, então ele funcionará.

No seu caso específico, para 10.0.0.9, a sub-rede 255.255.255.254 possui apenas 1 endereço IP adicional , ou seja, 10.0.0.8. Portanto, se você puder carregar esse endereço IP, poderá fazer o SSH.