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.
fe80::42:ff:fe:42é o endereço de ...? meu servidor mal configurado, eu acho?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.arp -aouip neighbor listcomorootencontrar o endereço MAC do servidor configurado incorretamente.ssh user@link-local%devonde:fonte
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.
fonte