Le workflow le plus fluide pour gérer les erreurs de vérification des hôtes SSH?

C’est un problème simple auquel nous sommes tous confrontés et que nous résolvons probablement manuellement sans trop y penser.

Lorsque les serveurs changent, sont réapprovisionnés ou que les adresses IP sont réaffectées, nous recevons le message de vérification d'hôte SSH ci-dessous. Je suis intéressé par la rationalisation du flux de travail pour résoudre ces erreurs d'identification SSH.

Compte tenu du message suivant, je vi /root/.ssh/known_hosts +434supprime généralement ( dd) la ligne incriminée.

J'ai vu des développeurs / utilisateurs d'autres organisations supprimer tout leur known_hostsfichier, frustrés de voir ce message. Bien que je n’aille pas aussi loin, je sais qu’il existe un moyen plus élégant de gérer cela.

Conseils?

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

Vous pouvez utiliser la ssh-keygencommande pour supprimer des entrées spécifiques par hôte:

ssh-keygen -R las-db1

Si vous n'avez pas cette commande, vous pouvez toujours utiliser sed:

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

En tant qu’utilisateur de marionnettes, ma méthode pour résoudre ce problème consiste à demander à mon serveur de marionnettes de collecter mes clés d’hôte SSH et de les publier sur tous les systèmes qui établissent des connexions SSH.

De cette façon, je n'ai pas à craindre de les enlever. Quatre-vingt-dix-neuf pour cent du temps, marionnette a fonctionné et mis à jour les clés pour moi depuis que mes agents sont en cours d'exécution toutes les trente minutes. Les exceptions pour moi sont très rares, et donc je ne crains pas une édition rapide de l’hôte connu des hôtes connus si je ne suis pas disposé à attendre.

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,
  }

}

Je voudrais ajouter une suggestion qui peut vous aider dans des cas très spécifiques où la sécurité est moins préoccupante.

J'ai un environnement de laboratoire avec des machines qui sont souvent réinstallées. Chaque fois que cela se produit, de nouvelles clés d’hôte sont générées (je pourrais probablement sauvegarder la clé d’hôte quelque part et la définir dans le script de post-installation).

Étant donné que la sécurité ne me pose pas de problème dans cet environnement de laboratoire et que les clés changent si souvent, mon fichier .ssh / config contient les éléments suivants:

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

Cela garantit que la connexion à mes machines de laboratoire ne causera plus jamais cette erreur et que mon client ssh se connectera simplement sans vérifier la clé de l'hôte.

C’est quelque chose que vous ne devriez faire que si la sécurité ne vous concerne pas du tout, car cela vous place dans une position vulnérable face à une attaque interceptée.

Selon la note de version de openssh 5.6 , il n’est plus nécessaire d’utiliser les clés d’hôtes:

L'authentification basée sur l'hôte peut désormais utiliser des clés d'hôte de certificat. Les clés de l'autorité de certification doivent être spécifiées dans un fichier known_hosts à l'aide du marqueur @ cert-Authority, comme décrit dans sshd (8).

Avertissement : je n’ai jamais entendu parler de l’utilisation de cette fonctionnalité en production à ce jour. Utilisez-le à vos risques et périls (mais je crois que les développeurs opensh sont suffisamment paranoïaques pour ne pas proposer une telle fonctionnalité si sans beaucoup de tests et d'audit de code).

Le registre de ressources DNS SSHFP peut aider en fonction des avantages dont bénéficie votre client ssh. Stockez toutes vos empreintes digitales de clé publique ssh avec le nom d’hôte.

Implémentez au préalable DNSSEC ou DNS sur SSL.
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.org gère la gestion des clés des hôtes et des utilisateurs, ainsi que les certificats PKI. Il télécharge également automatiquement les enregistrements DNS SSHFP lorsque de nouvelles clés sont créées.

Le démon de services de sécurité système (SSSD) peut être configuré pour mettre en cache et récupérer les clés SSH de l'hôte, de sorte que les applications et les services ne doivent rechercher dans un seul emplacement les clés de l'hôte. SSSD pouvant utiliser FreeIPA comme l’un de ses fournisseurs d’informations d’identité, FreeIPA fournit un référentiel universel et centralisé de clés. Les administrateurs n'ont pas besoin de s'inquiéter de la distribution, de la mise à jour ou de la vérification des clés SSH de l'hôte.

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