42 votos

Más suave flujo de trabajo para controlar SSH host de verificación de errores?

Esta es una simple cuestión de que todos nos enfrentamos y, probablemente, de resolver de forma manual, sin pensar demasiado.

Como servidores cambio, son re-creado, o direcciones IP reasignados, recibimos el SSH host mensaje de verificación a continuación. Estoy interesado en la simplificación del flujo de trabajo para resolver estos ssh errores de identificación.

Dado el siguiente mensaje, me típicamente vi /root/.ssh/known_hosts +434 y quitar (dd) de los infractores de la línea.

He visto a desarrolladores/usuarios de otras organizaciones eliminar su totalidad known_hosts de archivo de la frustración de ver este mensaje. Mientras no me vaya tan lejos, yo sé que hay una forma 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.

47voto

Kyle Brandt Puntos 50907

Usted puede utilizar el ssh-keygen comando para eliminar las entradas de host:

ssh-keygen -R las-db1

Si usted no tiene ese comando, siempre se puede usar sed:

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

25voto

Zoredache Puntos 84524

Como un títere de usuario, mi método para resolver esto es realmente para tener mi títere servidor recoger mi SSH claves de host y publicarlos a todos mis sistemas que hacen conexiones SSH.

De esta manera no tengo que preocuparse acerca de la eliminación de ellos. El noventa y nueve por ciento del tiempo de títeres se ha ejecutado y que actualiza las claves para mí desde que tengo mi los agentes de ejecución de cada treinta minutos. Las excepciones para mí son muy raros, y así que no me importa una edición rápida de todo el sistema en known_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,
  }

}

4voto

Kenny Rasschaert Puntos 5933

Me gustaría añadir una sugerencia que puede ayudar en casos muy específicos donde la seguridad es lo de menos preocupación.

Tengo un entorno de laboratorio con máquinas que conseguir reinstalado a menudo. Cada vez que eso pasa, nuevas claves de host obtener generado (yo probablemente podría guardar la clave de host en algún lugar y ponerlo en el post-script de instalación).

Ya que la seguridad no es un problema para mí en este entorno de laboratorio, y las teclas cambian tan a menudo, tengo el siguiente en mi .ssh/config archivo:

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

Esto se asegura de que la conexión a mi laboratorio de máquinas nunca va a causar ese error de nuevo y mi cliente ssh se acaba de conectar sin la comprobación de la clave de host.

Esto es algo que sólo se debe hacer si la seguridad no es asunto de preocupación para usted en todo, porque esto lo pone en una posición vulnerable para un hombre en el ataque medio.

2voto

rjt Puntos 364

SSHFP DNS ResourceRecord puede ayudar dependiendo de cuánto de su cliente ssh se aprovecha de ella. Almacenar toda su clave pública ssh huellas dactilares hasta allí con el nombre de host.

Implementar DNSSEC o DNS a través de SSL de antemano.
http://www.ietf.org/rfc/rfc4255.txt

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

El Sistema Demonio de Servicios de Seguridad (SSSD) puede ser configurado para almacenar en caché y recuperar host de claves SSH para que las aplicaciones y servicios sólo tienen para buscar en una ubicación para las claves de host. Porque SSSD puede utilizar como FreeIPA una de sus señas de identidad proveedores de información, FreeIPA proporciona un universal y repositorio centralizado de teclas. Los administradores no necesita preocuparse acerca de la distribución, actualización, o la verificación de host SSH teclas.

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

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: