Probleme bei der Überprüfung des SSH-Hostschlüssels mit VIP

Wir haben 2 Produktionsserver auf einem VIP, von denen jeweils nur einer verwendet wird, zum Beispiel:

myservice.mycompany.uk zeigt normalerweise auf server1. Falls server1 ausfällt, wird auf server2 geändert.

Es gibt einige andere Server, die Dateien über SFTP an myservice.mycompany.uk senden müssen, und es sollte für sie völlig transparent sein, wenn wir ein Failover auf Server2 durchführen.

Das Problem ist, dass während die Schlüssel sowohl auf Server1 als auch auf Server2 installiert sind, die anderen Server Probleme mit der Überprüfung des Hostschlüssels haben, da sich der Hostschlüssel von Server2 vom Hostschlüssel von Server1 unterscheidet. Dies führt zu einem Sicherheitsfehler (da die strikte Überprüfung aktiviert ist), und eine Zeile muss aus bekannten_Hosts entfernt werden, damit dies funktioniert.

Unser IT-Mitarbeiter hat vorgeschlagen, dass wir zwei Einträge in bekannten_Hosts erstellen können, einen mit dem Schlüssel für Server1 und einen mit Server2, beide mit dem Host myservice.mycompany.uk.

Wird das wahrscheinlich funktionieren? Wie geht das mit Putty / Psftp unter Windows? Da der Hostschlüssel in der Registrierung gespeichert ist und doppelte Namen nicht zulässig sind. Gibt es eine bessere Möglichkeit, können wir beispielsweise die Server dazu zwingen, denselben Hostschlüssel zu haben?

ssh cluster sftp

— Paul Creasey
quelle

Antworten:

Um es den Clients zu erleichtern, würde ich auf beiden Computern nur denselben Hostschlüssel verwenden. Kopieren Sie einfach einen der Schlüssel (den des aktuell verwendeten Servers) auf den zweiten Computer. Die Schlüssel sind drin /etc/ssh/ssh_host_*.

Eine weitere Option ist das Deaktivieren der Hostschlüsselprüfung auf Clients. Dies kann durch Abstimmung ihrer ssh_configVerwendung erfolgen:

Host myservice.mycompany.uk
    StrictHostKeyChecking

— ℝaphink
quelle

Das Deaktivieren der Hostschlüsselprüfung untergräbt eher die Verwendung von SSH zum Übertragen dieser Dateien. Das Duplizieren des Hostschlüssels ist wahrscheinlich die beste Lösung.

— James Yale

Das Deaktivieren der Hostschlüsselprüfung bedeutet nicht, dass die Kommunikation nicht ordnungsgemäß verschlüsselt ist. Dies ist der Hauptpunkt von SSH. Trotzdem bevorzuge ich, wie gesagt, die erste Lösung selbst.

— inkaphink

In der Client-Version (mit verschiedenen Serverschlüsseln) der Lösung müssen Sie auch hinzufügen, UserKnownHostsFile=/dev/nullsonst geht der erste Schlüssel in die bekannten Hosts und der zweite führt zu einer Warnung "Mann in der Mitte".

— Nils

@Nils das ist nicht nötig; Durch diese Einstellung StrictHostKeyChecking yeswird die UserKnownHosts-Datei zugunsten der vom System bekannten Hosts-Datei ignoriert. Alles, was die UserKnownHosts ändert, ist also ziemlich sinnlos.

— Michael Lowman

Ok - ich muss das weiter klären: Ich spreche über den Fall, dass Sie zwei verschiedene Serverschlüssel haben. Dort müssen Sie angeben StrictHostKeyChecking nound zusätzlich UserKnownHostsFileauf / dev / null setzen. In diesem Fall werden alle Hostschlüssel akzeptiert (was diese Sicherheitsstufe natürlich unbrauchbar macht).

— Nils

Ich habe dies auf diese Weise archiviert. Der Benutzer root führt um 23:00 Uhr ein Skript aus, das eine Verbindung zur logischen IP-Adresse des Linux-Clusters herstellt. Im Falle eines Failovers der IP-Adresse ändert sich also mein SSH-Fingerabdruck

echo "StrictHostKeyChecking no" >> /root/.ssh/config 
echo "UserKnownHostsFile /dev/null" >> /root/.ssh/config

Auf diese Weise gilt die Einstellung nur für root

— c4f4t0r
quelle