Desativa a verificação estrita das chaves ssh

Question

Cada usuário cria e destrói 15+ VMs por dia. As VMs são criadas na nuvem interna do OpenStack da empresa.

Toda vez que um novo vm recebe um endereço IP que foi entregue anteriormente, o usuário recebe a falha na verificação da chave do host. Isso ocorre porque a chave ssh não corresponde ao endereço IP no arquivo known_hosts dos usuários.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
xxxxxxxxxxx
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

As duas soluções que consigo ver são:

• Desativar a verificação estrita - (risco de segurança)
• Os usuários executam ssh-keygen -R ipAddress - (os usuários estão ficando cansados dessa solução, desde então executam isso várias vezes por dia)

Existe alguma maneira de evitar essa mensagem de erro e, ao mesmo tempo, permanecer seguro? talvez desative a verificação de segurança para apenas uma sub-rede específica?

    

Answer 1

O ótimo recurso HostKeyAlias resolve seu problema:

ssh -o HostKeyAlias=hostkeyalias__vm_2013-05-11_07 user@host

cria uma entrada hostkeyalias__vm_2013-05-11_07 (sem IP) em known_hosts . Claro, você poderia escrever um script ou função de shell que define esse valor antes de cada chamada ssh. Ou você usa uma variável de shell:

HOSTKEYALIAS=hostkeyalias__vm_2013-05-11_07
ssh -o HostKeyAlias=$HOSTKEYALIAS user@host

e altere $HOSTKEYALIAS sempre que a VM for alterada. De tempos em tempos, as entradas antigas devem ser excluídas de known_hosts .

    

Answer 2

crie ~/.ssh/config com o conteúdo:

Host *
    StrictHostKeyChecking no

Como alternativa, você pode criar um alias para o ssh para:

ssh -o StrictHostKeyChecking=no

    

Answer 3

Você pode recuperar a nova chave do host no console da VM e atualizar o arquivo de hosts conhecidos depois que uma instância é inicializada.

    

Answer 4

O problema é que ssh pressupõe um mapeamento 1-para-1 entre endereços IP e hosts. Precisamos quebrar esse mapeamento somente para os endereços IP de seus servidores em nuvem.

A solução

Adicione a seguinte estrofe ao seu arquivo ~/.ssh/config .

# Disable HostKey checking for servers which frequently change keys
Host 172.16.24.32  172.16.24.33  172.16.24.34
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no

Basta alterar os endereços IP e pronto.¹

Opcional: uma alternativa para intervalos de endereços IP

Se quiser aplicar isso a um netblock, como 192.168 / 16, você pode usar curingas assim:

# Do not keep HostKeys for internal networks.
Host 10.?.?.?  192.168.?.?
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no

Opcional: usando nomes de host

A pergunta original mencionou endereços IP, mas você pode, claro, usar nomes de host. Por exemplo, isso corresponderia a ssh instance32.vm.yoyodyne.com :

Host *.vm.yoyodyne.com
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no

Se você quiser usar nomes de host e endereços IP, será necessário especificar explicitamente como o SSH não corresponde ao endereço IP resolvido . Por exemplo, se você tiver ssh ourvm.local como atalho para ssh 192.168.1.53 :

Host 192.168.1.53  ourvm.local
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no

Advertência

Seja cauteloso ao contornar o modelo de segurança de ssh . Em particular, verifique novamente se seus curingas não correspondem a nenhum servidor genuíno cujas HostKeys não estejam mudando.

¹ ^{Por que / dev / null? Estou lançando os dados KnownHosts no depósito de bits porque somente a configuração StrictHostChecking no remove o aviso, mas ainda se recusa a se conectar. Isso é bobagem, então presumo que o OpenSSH acabará alterando o comportamento ou adicionando uma nova opção. Se e quando uma solução melhor aparecer, atualizarei essa resposta.}