Reinstalei uma VM (CentOS7) e agora recebo este erro. A VM possui dois adaptadores que estão em sub-redes diferentes.
Engraçado o suficientessh funcionou bem em uma sub-rededepois de corrigir o aviso MITM esperado.
ssh -v mostra:
OpenSSH_8.0p1, OpenSSL 1.1.1c 28 May 2019
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 6: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "foreman" port yy
debug2: ssh_connect_direct
debug1: Connecting to foreman [xxx.xxx.xxx.xxx] port yy.
debug1: Connection established.
debug1: identity file /home/sam/.ssh/id_rsa type 0
debug1: identity file /home/sam/.ssh/id_rsa-cert type -1
debug1: identity file /home/sam/.ssh/id_dsa type -1
debug1: identity file /home/sam/.ssh/id_dsa-cert type -1
debug1: identity file /home/sam/.ssh/id_ecdsa type -1
debug1: identity file /home/sam/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/sam/.ssh/id_ed25519 type -1
debug1: identity file /home/sam/.ssh/id_ed25519-cert type -1
debug1: identity file /home/sam/.ssh/id_xmss type -1
debug1: identity file /home/sam/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0
kex_exchange_identification: read: Connection reset by peer
eu tentei
- Reiniciando
- removendo o arquivoknown_hosts
- verificado /etc/ssh/ssh_config no cliente (sem desvio da versão do mantenedor)
- verificado /etc/ssh/sshd_config no servidor (sem desvio da versão do mantenedor)
- parando o firewalld
- verifiquei as permissões em .ssh/ eauthorized_keys
- lista negra e lista branca verificadas (nada lá, apenas comentários) (hosts.deny|hosts.allow)
Não tenho certeza se é relevante, mas o cliente está executando o arch linux
Então, novamente para esclarecer
O servidor tem dois endereços IP 172.xxx e 192.xxx ssh funciona para 172.xxx, mas não para 192.xxx
Responder1
Para mim, isso parece um problema de roteamento ou um problema com as máscaras de rede. Já vi casos com configuração semelhante, onde a pilha de rede tentou usar a interface errada para pacotes de saída, ou seja, onde os pacotes de saída paraambossub-redes foram roteadas pela interface para oprimeirosub-rede.
Portanto, a primeira coisa a testar é se você consegue executar ping em outra máquinacadadas sub-redes doservidor, e vice versa. Para tornar o processo de teste menos sujeito a erros, você deve configurar ooutromáquinas (clientes) para usar apenasumEndereço IP (caso contrário, o teste poderá falhar devido à configuração incorreta dooutromáquinas, o que seria enganoso).
A próxima coisa seria uma análise profunda da saída route -n
no servidor e nos clientes. Talvez isso já mostre a causa do problema. Você se importaria de publicar esse resultado?
Além disso, a saída de ifconfig -a
seria útil (novamente no servidor e nos clientes) - gostaríamos de entender suas máscaras de rede.
Ao publicar essas saídas, acho que você não precisa ofuscar os endereços IP, desde que sejam do intervalo privado. A ofuscação por si só pode ser propensa a erros, tornando a análise impossível.
Se você decidir publicar esses resultados (edite sua pergunta adequadamente, em vez de usar comentários para isso, porque os resultados podem ser longos), darei uma olhada e tentarei descobrir o que está acontecendo.
Responder2
Recebi esse erro em uma situação um pouco diferente. No meu caso, o servidor ssh não foi instalado em primeiro lugar, e a instalação direta e o serviço inicial resolveram o problema.
A mensagem principal é que esse tipo de erro acontece se nenhum ssh for servido na porta/ip/interface, seja devido à instalação ou configuração.