Fluxo de trabalho mais suave para lidar com erros de verificação de host SSH?

Question

Esta é uma questão simples que todos enfrentamos e, provavelmente, resolver manualmente, sem dar muita atenção.

À medida que os servidores mudam, são reprovisionados ou os endereços IP são realocados, recebemos a mensagem de verificação do host SSH abaixo. Estou interessado em simplificar o fluxo de trabalho para resolver esses erros de identificação ssh.

Dada a seguinte mensagem, normalmente eu uso vi /root/.ssh/known_hosts +434 e removo ( dd ) a linha ofensiva.

Eu vi desenvolvedores / usuários em outras organizações excluírem o arquivo inteiro known_hosts por frustração ao ver esta mensagem. Embora eu não vá tão longe, sei que há uma maneira mais elegante de lidar com isso.

Dicas?

[root@xt ~]# ssh las-db1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
ed:86:a2:c4:cd:9b:c5:7a:b1:2b:cc:42:15:76:8c:56.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:434
RSA host key for las-db1 has changed and you have requested strict checking.
Host key verification failed.

    

Answer 1

Você pode usar o comando ssh-keygen para remover entradas específicas por host:

ssh-keygen -R las-db1

Se você não tiver esse comando, poderá usar o sed:

sed -i '/las-db1/d' /root/.ssh/known_hosts

    

Answer 2

Como um usuário fantoche, meu método para resolver isso é fazer com que meu servidor de marionetes colete minhas chaves de host SSH e as publique em todos os meus sistemas que fazem conexões SSH.

Desta forma, não tenho que me preocupar em removê-los. Noventa e nove por cento do tempo que o fantoche executou e atualizou as chaves para mim, pois tenho meus agentes trabalhando a cada trinta minutos. As exceções para mim são muito raras, e por isso não me importo de uma edição rápida do sistema wide known_hosts se eu não estiver disposto a esperar.

class ssh::hostkeys {

  @@sshkey { "${::clientcert}_rsa":
    type => rsa,
    key => $sshrsakey,
    tag => 'rsa_key',
  }

  if 'true' == $common::params::sshclient {
    Sshkey <<| tag == 'rsa_key' |>> {
      ensure => present
    }
  }

  file {'/etc/ssh/ssh_known_hosts':
    ensure => present,
    owner => 'root',
    group => 'root',
    mode => 0644,
  }

}

    

Answer 3

Gostaria de adicionar uma sugestão que pode ajudá-lo em casos muito específicos em que a segurança é menos preocupante.

Eu tenho um ambiente de laboratório com máquinas que são reinstaladas frequentemente. Toda vez que isso acontece, novas chaves de host são geradas (eu provavelmente poderia salvar a chave do host em algum lugar e configurá-la no script de pós-instalação).

Como a segurança não é um problema para mim neste ambiente de laboratório, e as chaves mudam com tanta frequência, tenho o seguinte no meu arquivo .ssh / config:

Host lab-*
  User kenny
  IdentityFile ~/.ssh/lab_id_rsa
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

Isso garante que a conexão com as minhas máquinas de laboratório nunca mais cause esse erro e meu cliente ssh se conecte sem verificar a chave do host.

Isso é algo que você deve fazer somente se a segurança não lhe interessar, porque isso o coloca em uma posição vulnerável para um ataque man-in-the-middle.

    

Answer 4

De acordo com a nota de lançamento do openssh 5.6 , você não precisa mais usar as chaves dos hosts:

Hostbased authentication may now use certificate host keys. CA keys must be specified in a known_hosts file using the @cert-authority marker as described in sshd(8).

Aviso : nunca ouvi falar de ninguém usando esse recurso em produção até o momento. Use a seu próprio risco (mas acredito que os desenvolvedores do openssh são paranóicos o suficiente para não liberar esse recurso matador sem muitos testes e auditoria de código).

    

Answer 5

O SSHFP DNS ResourceRecord pode ajudar dependendo de quanto o seu cliente ssh aproveita. Armazene todas as suas impressões digitais de chave pública ssh com o nome do host.

Implemente o DNSSEC ou o DNS sobre SSL antecipadamente.
link

O FreeIPA.org lida com o gerenciamento de chaves do host e do usuário, bem como com Certificados PKI. Ele também carrega automaticamente os registros DNS do SSHFP quando novas chaves são criadas.

The System Security Services Daemon (SSSD) can be configured to cache and retrieve host SSH keys so that applications and services only have to look in one location for host keys. Because SSSD can use FreeIPA as one of its identity information providers, FreeIPA provides a universal and centralized repository of keys. Administrators do not need to worry about distributing, updating, or verifying host SSH keys.

link