SSL-Fehler (Man in the middle attack)

Bastelecke > Proxmox VE > Knowledge Base > SSL-Fehler

In seltenen Fällen kann es zu einem SSL-Fehler in der Kommunikation zwischen einzelnen Nodes kommen. Ihr bekommt dann beim Aufrufen der Shell des entsprechenden Nodes, sowie in den Logs der Replikationsprozesse, sowas in der Art angezeigt:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:Qql4P+9wXymrawXn/kHZpjrTnsbkwciPUGhp7l5HSmU.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending RSA key in /etc/ssh/ssh_known_hosts:
  remove with:
  ssh-keygen -f "/etc/ssh/ssh_known_hosts" -R "pve4"
Host key for pve4 has changed and you have requested strict checking.
Host key verification failed.

 

Fehlerursache:

Es hat ein wenig gedauert um heraus zu finden was hier passiert ist. 

Ich hatte einen Proxmox Node in Verbund testweise kurz in VMware laufen lassen. Später, als dieser längst nicht mehr in Verwendung war, meldete ich unter eben der selben IP-Adresse einen neuen Node an. Anscheinend erkennt der SSH-Client von Proxmox jedoch nicht das es sich um einen neuen Node handelt, oder er wird aus sicherheitstechnischen Gründen nicht selbstständig tätig, so dass immer noch der alte SSH-Key zur Kommunikation der Nodes untereinander, auf den einzelnen Nodes, hinterlegt ist. Neuer Key aber alte IP führt somit unweigerlich zu diesem Fehler.

Das Selbe kann auch passieren wenn ihr versehentlich zwei Nodes, bei der Installation, die selbe IP-Adresse gebt.

 

Lösung:

Kurz vorweg: Es gibt einen Proxmox-Befehl zum Update des Zertifikates auf dem entsprechenden Node. Auf diesen werde ich hier nicht näher eingehen, da er nur kurzzeitig Abhilfe schafft. Der fehler kommt dann nach kurzer Zeit wieder. Dauerhaft Abhilfe schafft nur der Austausch der fehlerhaften Zertifikate auf den einzelnen Nodes.

Interessanterweise liefert die Fehlermeldung oben einen Teil der Lösung direkt mit. Wer lesen kann ist hier klar im Vorteil. ;) Hierzu öffnet ihr die Shell-Konsolen der ordnungsgemäß funktionierenden Nodes und gebt folgenden Befehl ein:

ssh-keygen -f "/etc/ssh/ssh_known_hosts" -R "pve4"

Das "pve4" steht hierbei für den Namen des Nodes, welcher den Fehler verursacht. Also eben der, dessen Shell-Konnsole diesen Fehler zurück gibt. Bei mir hieß er eben PVE4.

Der Befehl führt dazu das der hinterlegte Key verworfen wird. Anschließend müsst ihr noch den richtigen Key neu anfordern. Dieses geschieht mit dem Befehl:

ssh -o 'HostKeyAlias=pve4' root@192.168.179.14

Auch hier wieder, pve4 steht für den ursprünglich fehlerhaften Node und hinter dem @-Zeichen folgt dessen IP-Adresse.

Ihr werdet nun gefragt ob ihr den neuen "Fingerprint" speichern möchtet. Bestätigt dieses durch schreiben von "yes". ("Y" + "Enter" reicht nicht aus)

Dieser Schritt muss auf jedem einzelnen Node eures Clusters wiederholt werden, da jeder einzelne Node für sich die SSH-Keys der anderen Nodes speichert.