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

41

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.
ewwhite
la source
Nous avons le meme probleme. Je n'ai pas d'expérience avec le Mesh ti.arc.nasa.gov/opensource/projects/mesh de la NASA, mais il fait partie de ma liste de technologies à examiner.
Andrew Gilmartin
1
Pourquoi ne pas copier l'ancienne clé lors de la réinstallation / réaffectation d'un serveur?
Random832
@ Random832 Cela ne s'adapte pas dans une situation où vous avez beaucoup de serveurs ... Ou si vous avez un environnement de laboratoire / test où vous recyclez souvent les adresses IP. Ou un autre cas; un remplacement de serveur imprévu où le serveur d'origine est indisponible ...
ewwhite
3
La grande question que je me pose est la suivante: comment entrez-vous dans cette situation? Si vous réutilisez des noms d'hôte, vous voudrez peut-être reconsidérer la norme de dénomination de l'hôte ( tools.ietf.org/html/rfc1178 ). Si vous réutilisez des adresses IP, vous devez procéder à la mise hors service des clés ssh dans le cadre de la même procédure que pour la mise hors service du serveur précédent sur cette adresse IP. Si vous travaillez dans un environnement "webscale" où la réutilisation IP se fait de manière automatisée et où les noms d'hôte semi-illogiques sont obligatoires, vous devez disposer d'un processus de cycle de vie du serveur suffisamment automatisé pour que la réparation des clés ssh soit effectuée
Paul Gear

Réponses:

47

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
Kyle Brandt
la source
3
Utiliser ssh-keygen -R pour résoudre le problème des clés en conflit est également ce que le client ssh d’Ubuntu suggère dans le message d’erreur lorsque ce problème se produit.
Kenny Rasschaert
Je n'étais pas au courant de ce passage à la ssh-keygencommande. Bien!
ewwhite
10
N'oubliez pas de vérifier et de vous assurer que quelqu'un n'est pas réellement "FAIRE QUELQUE CHOSE DE MAUVAIS!"
Michael Hampton
1
Assurez-vous de ne pas faire cela lors d'une conférence!
Paul Gear
2
@ewwhite Vous remplissez le /etc/ssh/known_hostsfichier sur votre réseau avec les clés d’hôte appropriées (géré avec puppet, etc.), ou vous remplissez votre fichier personnel ~ / .ssh / known_hosts (pour cela, vous pouvez exécuter ssh-keyscanune recherche sur un disque connexion). Sauf si (et en supposant que vous ne vous souciez pas du tout de la sécurité) UserKnownHostsFile=/dev/nullet StrictHostKeyChecking=nodans votre ~/.ssh/config file(ou passez les options à ssh avec -o)
voretaq7
25

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

}
Zoredache
la source
+1 Bon choix pour intégrer des outils de gestion de la configuration.
ewwhite
4

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.

Kenny Rasschaert
la source
1
Cela semble risqué. J'aimerais conserver la vérification de l'hôte, car certains d'entre eux sont des systèmes ouverts au public.
ewwhite
1
Ce sera pour cette raison qu'il a mentionné que cette méthode est uniquement pour "où la sécurité est peu / pas préoccupante". Les réseaux privés / environnements de laboratoire sont parfaits pour cette configuration. Systèmes de production / publics multi-machines à mise à l'échelle automatique, pas tellement.
dannosaur
4

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


la source
2

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

rjt
la source