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

Esse é um problema simples que todos enfrentamos e provavelmente resolvemos manualmente, sem pensar muito.

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

Dada a seguinte mensagem, normalmente vi /root/.ssh/known_hosts +434removo ( dd) a linha incorreta.

Vi desenvolvedores / usuários em outras organizações excluírem seu 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.

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

ssh-keygen -R las-db1

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

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

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

Dessa forma, não preciso me preocupar em removê-los. Noventa e nove por cento das vezes, as marionetes correm e atualizam as chaves para mim desde que tenho meus agentes funcionando a cada trinta minutos. As exceções para mim são muito raras e, portanto, não me importo com uma edição rápida do sistema conhecido_hosts se 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,
  }

}

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. Sempre 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 pós-instalação).

Como a segurança não é um problema para mim neste ambiente de laboratório, e as chaves mudam com 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 minhas máquinas de laboratório nunca mais cause esse erro e meu cliente ssh apenas se conectará sem verificar a chave do host.

Isso é algo que você deve fazer apenas se a segurança não lhe interessar, porque isso o coloca em uma posição vulnerável para um ataque do tipo intermediário.

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

A autenticação baseada em host agora pode usar chaves de host de certificado. As chaves da CA devem ser especificadas em um arquivo known_hosts usando o marcador @ cert-Authority, conforme descrito em sshd (8).

Aviso : nunca ouvi falar de ninguém usando esse recurso na produção até agora. Use por sua conta e risco (mas acredito que os desenvolvedores do opensh são paranóicos o suficiente para não liberar um recurso tão matador sem muitos testes e auditoria de código).

O SSHFP DNS ResourceRecord pode ajudar dependendo de quanto o seu cliente ssh tira vantagem disso. Armazene todas as suas impressões digitais de chave pública ssh lá em cima com o nome do host.

Implemente DNSSEC ou DNS sobre SSL de antemão.
http://www.ietf.org/rfc/rfc4255.txt

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

O SSSD (System Security Services Daemon) pode ser configurado para armazenar em cache e recuperar chaves SSH do host, para que aplicativos e serviços tenham apenas que procurar em um local por chaves do host. Como o SSSD pode usar o FreeIPA como um de seus provedores de informações de identidade, o FreeIPA fornece um repositório universal e centralizado de chaves. Os administradores não precisam se preocupar em distribuir, atualizar ou verificar as chaves SSH do host.

http://docs.fedoraproject.org/pt-BR/Fedora/17/html/FreeIPA_Guide/host-keys.html