Do servidor Y, o usuário A tenta fazer ssh para o servidor X e obtém conexão recusada. Do servidor Y, o usuário B tenta fazer ssh para o servidor X e tem permissão para passar. Do servidor Y, o root tenta fazer o ssh e obtém a conexão recusada. O problema é 100% repetível e 100% consistente.
Os dois primeiros sugeririam um problema com a ACL, mas me disseram que as configurações são as mesmas para ambos os usuários, embora eu não tenha permissão para visualizá-las. Eles também foram excluídos e lidos sem sucesso. No entanto, o root não é afetado pela ACL e também não consegue se conectar.
Existem dois servidores com este problema, e muitos outros servidores com configurações idênticas no ifconfig (exceto endereços IP, etc.) e tabelas de roteamento que não sofrem esse problema.
Um tcpdump no servidor X procurando conexões do servidor Y não mostra nada quando o usuário A tenta se conectar, mas produz muitas informações quando o usuário B tenta se conectar. Isso mostra que o servidor X não está recebendo nada quando o usuário A está tentando fazer ssh.
Todos os servidores estão executando RedHat
Presumo que o problema esteja no servidor Y, mas o que devo procurar? Poderia um problema de conectividade baseado em nome de usuário aparecer em firewalls entre os servidores ou esses firewalls não são baseados em nome de usuário?
Editar - Os usuários A e B podem fazer ssh do servidor Y para muitos outros servidores do grupo. É apenas o servidor X que tem o problema. Ssh-ing não usa RSA, embora o login no servidor Y o faça.
Responder1
.ssh/configVerifique o arquivo do usuário A. Ele pode ter uma Hostentrada nesse arquivo para o nome do host em questão, o que está fazendo com que você sshtente uma porta ou endereço IP diferente para esse nome do host. Por exemplo, se .ssh/configtivesse estas linhas:
Host a.example.com
Hostname b.example.com
Port 42
Em seguida, executar "ssh a.example.com" tentaria conectar-se à porta 42 de b.example.com.
Outra possibilidade (improvável) é que o usuário A esteja executando um programa "ssh" diferente por algum motivo, por exemplo, porque seu caminho de comando é diferente e o programa alternativo não está se comportando conforme o esperado.
Editar: Outra possibilidade improvável é que você tenha dois hosts na rede respondendo ao mesmo endereço IP. As solicitações de conexão com falha serão atendidas pelo servidor errado. Isso faria com que as conexões falhassem aleatoriamente, em vez de consistentemente por usuário, portanto, não corresponde ao comportamento que você descreve.
Responder2
Isso foi resolvido.
Havia DUAS listas de acesso - a primeira que era comumente conhecida (ACL), que lista os servidores aos quais um usuário pode se conectar, e a segunda lista anteriormente desconhecida de servidores que só têm acesso permitido a determinados usuários, ou seja, o inverso de uma ACL . Com os servidores retirados desta lista de restrições, o acesso foi permitido a todos os usuários.
Obrigado por todos os seus comentários e orientações.