¿El flujo de trabajo más fluido para manejar los errores de verificación del host SSH?

Este es un problema simple que todos enfrentamos y que probablemente resolvamos manualmente sin pensarlo demasiado.

A medida que los servidores cambian, se reaprovisionan o se reasignan las direcciones IP, recibimos el siguiente mensaje de verificación de host SSH. Estoy interesado en simplificar el flujo de trabajo para resolver estos errores de identificación ssh.

Dado el siguiente mensaje, normalmente vi /root/.ssh/known_hosts +434elimino ( dd) la línea ofensiva.

He visto a desarrolladores / usuarios en otras organizaciones eliminar todo su known_hostsarchivo por frustración al ver este mensaje. Si bien no voy tan lejos, sé que hay una manera más elegante de manejar esto.

¿Consejos?

[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.

Puede usar el ssh-keygencomando para eliminar entradas específicas por host:

ssh-keygen -R las-db1

Si no tiene ese comando, siempre puede usar sed:

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

Como usuario puppet, mi método para resolver esto es hacer que mi servidor puppet recopile mis claves de host SSH y las publique en todos mis sistemas que hacen conexiones SSH.

De esta manera no tengo que preocuparme por eliminarlos. El noventa y nueve por ciento del tiempo que Puppet ha ejecutado y actualizado las claves para mí ya que tengo a mis agentes ejecutándose cada treinta minutos. Las excepciones para mí son muy raras, por lo que no me importa una edición rápida de todo el sistema conocido_hosts si no estoy dispuesto 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,
  }

}

Me gustaría agregar una sugerencia que pueda ayudarlo en casos muy específicos en los que la seguridad es menos preocupante.

Tengo un entorno de laboratorio con máquinas que se reinstalan con frecuencia. Cada vez que sucede, se generan nuevas claves de host (probablemente podría guardar la clave de host en algún lugar y configurarla en el script posterior a la instalación).

Como la seguridad no es un problema para mí en este entorno de laboratorio, y las claves cambian con tanta frecuencia, tengo lo siguiente en mi archivo .ssh / config:

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

Esto asegura que conectarse a las máquinas de mi laboratorio nunca volverá a causar ese error y mi cliente ssh simplemente se conectará sin verificar la clave del host.

Esto es algo que solo debe hacer si la seguridad no le preocupa en absoluto, porque lo coloca en una posición vulnerable para un ataque de hombre en el medio.

De acuerdo con la nota de lanzamiento de openssh 5.6 , ya no necesita usar claves de host:

La autenticación basada en host ahora puede usar claves de host de certificado. Las claves de CA deben especificarse en un archivo conocido_hosts utilizando el marcador @ cert-Authority como se describe en sshd (8).

Advertencia : hasta ahora nunca he oído hablar de nadie que use esta función en producción. Úselo bajo su propio riesgo (pero creo que los desarrolladores de openssh son lo suficientemente paranoicos como para no lanzar una función tan asesina sin muchas pruebas y auditorías de código).

SSHFP DNS ResourceRecord puede ayudar dependiendo de cuánto lo aproveche su cliente ssh. Almacene todas sus huellas digitales de clave pública ssh con el nombre del host.

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

FreeIPA.org maneja la administración de claves de host y usuario, así como los Certificados PKI. También carga automáticamente registros DNS SSHFP cuando se crean nuevas claves.

El Daemon de servicios de seguridad del sistema (SSSD) se puede configurar para almacenar en caché y recuperar claves SSH del host de modo que las aplicaciones y los servicios solo tengan que buscar claves de host en una ubicación. Dado que SSSD puede usar FreeIPA como uno de sus proveedores de información de identidad, FreeIPA proporciona un depósito de claves universal y centralizado. Los administradores no necesitan preocuparse por distribuir, actualizar o verificar las claves SSH del host.

http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/host-keys.html