A chave do host SSH parece estar mudando inesperadamente

Question

Eu lancei um novo /etc/ssh/sshd_config com o Puppet em um servidor de teste do Ubuntu 12.04. A configuração era exatamente igual à configuração anterior, exceto pela remoção da seguinte linha:

HostKey /etc/ssh/ssh_host_ecdsa_key

Percebi que estava obtendo muitos erros semelhantes, mas variando tentando conectar-se à caixa inicial, como: "A chave do host RSA para % hostname% foi alterada, e a chave para o endereço IP correspondente % ipaddress% é inalterado. "

Presumi que isso ocorreu porque meu computador estava usando a chave ECDSA anteriormente por padrão e que estava indisponível agora. Então, adicionei essa linha de volta a sshd_config e reiniciei o SSH.

Ele não resolveu a questão completamente, e eu estou encontrando problemas constantes desde então. Eu serei capaz de me conectar ao servidor muito bem várias vezes, talvez até por vários dias seguidos. Então, de repente, eu começo a receber erros que a chave do host mudou e o servidor para de aceitar minha chave pública para autenticação.

Parece sempre que, depois de mexer um pouco com ele e me conectar de um local diferente, de repente poderei me conectar novamente com a minha chave pública e não receber mais o erro sobre um possível ataque do meio-ataque.

Eu tentei regenerar todas as 3 chaves de host há vários dias (removi-as e executei dpkg-reconfigure openssh-server , que as regenerou). Como esperado, tive que remover as chaves antigas e aceitar as novas antes de poder me conectar. Eu pensei que talvez fosse consertado então, mas o problema agora está de volta.

Nada modificou nenhuma das chaves do host em /etc/ssh/ desde que as regenerou pela última vez - então, o que poderia me fazer frequentemente não conseguir se conectar, fazer com que minha chave pública não funcione e, eventualmente, aceitar a nova chave as coisas começam a funcionar bem por um tempo?

Quando as coisas não estão funcionando (quando recebo o erro sobre a alteração da chave do host e, em seguida, o servidor para de aceitar minha chave pública), nada é gravado no /var/log/auth.log do servidor. Isso me leva a pensar que talvez seja de alguma forma acertar uma máquina diferente às vezes, mas eu não sei como isso é possível, já que a entrada do DNS está correta e sempre retorna o mesmo endereço IP.

    

Answer 1

Existem três motivos comuns para receber essa mensagem.
Em uma ordem aproximada de probabilidade, eles são:

1. Você mesmo alterou as chaves do host e não as limpou ou atualizou nas máquinas clientes.
   Esta é a situação mais comum. Verifique a chave dos arquivos e esteja ABSOLUTAMENTE CERTAIS eles não mudaram.

2. Você alterou sua configuração de SSH para apresentar (ou solicitar) um tipo de chave diferente da anterior.
   por exemplo. você queria anteriormente chaves RSA ou DSA, agora você usa ECDSA - isso é uma "mudança fundamental". Se esse for o caso, verifique e aceite as novas chaves (ou, se não for o que você queria, desfaça a alteração).
   (Parece que você está na situação # 2 - Desfaça suas alterações, reinicie o sshd e verifique se as coisas funcionam como esperado. Se você não aceitou as novas chaves em nenhum lugar, desfazer a alteração deverá fazer com que o erro desapareça.) / p>

3. ALGUÉM ESTÁ FAZENDO ALGO NASTY
   O ataque Man-in-the-Middle contra o qual o SSH te avisa criou sua cabeça feia. Alguém está ativamente tentando interceptar sua comunicação para roubar sua chave privada ou fazer outra coisa que você quase certamente não quer que ela faça.

Se você eliminou 1 e tem certeza de que não fez 2, cabe a você assumir 3 até conseguir provar o contrário. Isso significa que Não faça login . - Toda a segurança do SSH no mundo não ajuda quando os usuários ignoram o grande banner de aviso gigante e entregam suas chaves para os invasores.

Investigue o canal entre você e seu servidor, verifique os logs de conexão do servidor (a partir de um bom terminal conhecido) enquanto você tenta efetuar login, etc. - há tantas maneiras de executar um ataque aqui que não posso enumerar todas as possíveis contramedidas e estratégias de detecção, mas o pessoal da Segurança de TI certamente teria algumas idéias.