Frage Schnellster Workflow für SSH-Host-Verifizierungsfehler


Dies ist ein einfaches Problem, dem wir uns alle stellen und das wir wahrscheinlich manuell lösen, ohne uns viele Gedanken zu machen.

Wenn Server sich ändern, neu bereitgestellt oder IP-Adressen neu zugewiesen werden, erhalten wir unten die SSH-Hostverifizierungsnachricht. Ich bin daran interessiert, den Workflow zu optimieren, um diese SSH-Identifikationsfehler zu beheben.

Angesichts der folgenden Nachricht, ich normalerweise vi /root/.ssh/known_hosts +434 und entfernen (dd) die beanstandete Linie.

Ich habe gesehen, dass Entwickler / Benutzer in anderen Organisationen ihre löschen ganz  known_hosts Datei aus Frustration, diese Nachricht zu sehen. Obwohl ich nicht so weit gehe, weiß ich, dass es einen eleganteren Weg gibt, damit umzugehen.

Tipps?

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

39
2017-08-12 20:54


Ursprung


Wir haben das gleiche Problem. Ich habe keine Erfahrung mit dem Netz der NASA ti.arc.nasa.gov/opensource/projects/mesh aber es steht auf meiner Liste der zu überprüfenden Technologien. - Andrew Gilmartin
Warum nicht den alten Schlüssel bei der Neuinstallation eines Servers kopieren? - Random832
@ Random832 Es skaliert nicht in einer Situation, in der Sie viele Server haben ... Oder wenn Sie eine Labor- / Testumgebung haben, in der Sie häufig IP-Adressen recyceln. Oder ein anderer Fall; ein ungeplanter Serveraustausch, bei dem der ursprüngliche Server nicht verfügbar ist ... - ewwhite
Die große Frage, die ich habe, ist: Wie kommst du in diese Situation? Wenn Sie Hostnamen erneut verwenden, sollten Sie Ihren Host-Namensstandard (tools.ietf.org/html/rfc1178). Wenn Sie IP-Adressen erneut verwenden, sollten Sie die SSH-Schlüssel außer Betrieb nehmen, genauso wie Sie den vorherigen Server für diese IP-Adresse außer Betrieb genommen haben. Wenn Sie in einer "Webscale" -Umgebung arbeiten, in der IP-Wiederverwendung auf einer automatisierten Basis stattfindet und semi-bedeutungslose Hostnamen obligatorisch sind, dann sollten Sie einen ausreichend automatisierten Server-Lebenszyklusprozess haben, der die SSH-Schlüssel korrigiert - Paul Gear


Antworten:


Du kannst den ... benutzen ssh-keygen Befehl zum Entfernen bestimmter Einträge nach Host:

ssh-keygen -R las-db1

Wenn Sie diesen Befehl nicht haben, können Sie immer sed verwenden:

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

46
2017-08-12 20:57



Die Verwendung von ssh-keygen -R, um das Problem mit in Konflikt stehenden Schlüsseln zu lösen, ist auch das, was der ssh-Client in Ubuntu in der Fehlermeldung vorschlägt, wenn dieses Problem auftritt. - Kenny Rasschaert
Ich war mir dieser Umstellung nicht bewusst ssh-keygen Befehl. Gut! - ewwhite
Denken Sie daran, zu überprüfen und sicher zu sein, dass jemand nicht wirklich "etwas ETWAS MACHT!" - Michael Hampton♦
Stellen Sie sicher, dass Sie dies nicht bei einer Konferenz tun! - Paul Gear
@ewwhite Sie bevölkern die /etc/ssh/known_hosts Datei in Ihrem Netzwerk mit geeigneten Host-Keys (verwaltet mit Puppet, etc.), oder Sie füllen Ihre persönliche ~ / .ssh / known_hosts Datei (um beide zu tun, können Sie ausführen ssh-keyscan über eine bekannte gute / sichere Verbindung). Abgesehen davon (und vorausgesetzt, Sie kümmern sich überhaupt nicht um Sicherheit) UserKnownHostsFile=/dev/null und StrictHostKeyChecking=no in deiner ~/.ssh/config file (Oder übergeben Sie die Optionen an ssh mit -o) - voretaq7


Als Puppet-Benutzer besteht meine Methode zur Lösung darin, dass mein Puppet-Server meine SSH-Host-Schlüssel tatsächlich sammelt und sie auf allen meinen Systemen veröffentlicht, die SSH-Verbindungen herstellen.

Auf diese Weise muss ich mich nicht darum kümmern, sie zu entfernen. Neunundneunzig Prozent der Zeit Marionette hat laufen und aktualisiert die Schlüssel für mich, da ich meine Agenten alle 30 Minuten laufen lassen. Die Ausnahmen sind für mich sehr selten und so macht es mir nichts aus eine schnelle Bearbeitung der systemweit bekannten_Hosts vorzunehmen, wenn ich nicht warten will.

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

}

25
2017-08-12 21:02



+1 Gute Bewegung für die Integration von Konfigurationsverwaltungstools. - ewwhite


Ich möchte einen Vorschlag hinzufügen, der Ihnen in ganz bestimmten Fällen helfen kann, in denen Sicherheit weniger wichtig ist.

Ich habe eine Laborumgebung mit Maschinen, die oft neu installiert werden. Jedes Mal, wenn das passiert, werden neue Host-Schlüssel generiert (ich könnte den Host-Schlüssel wahrscheinlich irgendwo speichern und im Nachinstallations-Skript einstellen).

Da Sicherheit in dieser Testumgebung für mich kein Problem darstellt und sich die Schlüssel so häufig ändern, habe ich Folgendes in meiner .ssh / config-Datei:

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

Dadurch wird sichergestellt, dass die Verbindung zu meinen Laborgeräten diesen Fehler nie wieder verursacht, und mein ssh-Client verbindet sich nur, ohne den Host-Schlüssel zu überprüfen.

Das ist etwas, was du nur tun solltest, wenn Sicherheit dich überhaupt nicht interessiert, weil du dadurch in eine verletzliche Position für einen Man-in-the-Middle-Angriff gerätst.


4
2017-08-12 21:09



Scheint riskant. Ich möchte die Host-Überprüfung beibehalten, da es sich bei einigen um öffentlich zugängliche Systeme handelt. - ewwhite
Dies ist der Grund, warum er erwähnte, dass diese Methode nur für "wo Sicherheit ist weniger / keine Sorge" ist. Private Netzwerke / Laborumgebungen sind perfekt für diese Konfiguration. Multi-Machine-Auto-Scaling-Produktion / Public-Facing-Systeme, nicht so sehr. - dannosaur


Gemäß openssh 5.6 Release Note , müssen Sie keine Hosts-Keys mehr verwenden:

Die hostbasierte Authentifizierung kann jetzt Zertifikatshostschlüssel verwenden. CA-Schlüssel müssen in einer known_hosts-Datei mit dem @ cert-authority-Marker angegeben werden, wie in sshd (8) beschrieben.

Warnung : Ich habe noch nie von jemandem gehört, der dieses Feature in der Produktion verwendet. Verwenden Sie auf eigene Gefahr (aber ich glaube, openssh Entwickler sind paranoid genug, um eine solche Killer-Funktion ohne viel Test-und Code-Auditing zu veröffentlichen).


4
2017-08-22 12:31





SSHFP DNS ResourceRecord kann helfen, abhängig davon, wie viel Ihr ssh Client davon ausnutzt. Speichern Sie alle Ihre Fingerabdrücke für den öffentlichen ssh-Schlüssel dort oben mit dem Hostnamen.

Implementieren Sie zuvor DNSSEC oder DNS über SSL.
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.org behandelt Host- und Benutzerschlüsselverwaltung sowie PKI-Zertifikate. Es lädt auch automatisch SSHFP-DNS-Einträge, wenn neue Schlüssel erstellt werden.

Der System Security Services Daemon (SSSD) kann zum Zwischenspeichern konfiguriert werden   und Host-SSH-Schlüssel abrufen, so dass Anwendungen und Dienste nur haben   an einem Speicherort nach Hostschlüsseln suchen. Weil SSSD FreeIPA als verwenden kann   Einer seiner Identitätsinformationsanbieter bietet FreeIPA ein   universelles und zentrales Repository von Schlüsseln Administratoren nicht   Sie müssen sich darum sorgen, Host-SSH zu verteilen, zu aktualisieren oder zu verifizieren   Schlüssel.

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


2
2017-08-12 21:38