☰

SSH-Anmeldung mit derselben IP-Adresse, aber anderem Betriebssystem?

tag-icon • tag-icon ssh
SSH-Anmeldung mit derselben IP-Adresse, aber anderem Betriebssystem?

Ich habe Raspberry Pi mit Raspbian OS an das lokale Netzwerk angeschlossen und die SSH-Anmeldung mit SSH-Schlüsseln eingerichtet. Ich konnte mich erfolgreich anmelden, indem ich Raspberry Pi eine statische IP zugewiesen habe.ssh [email protected]

Ich habe jetzt das Raspbian-Betriebssystem entfernt und eine SD-Karte mit Ubuntu Server (headless) eingelegt.

Ich habe den Raspberry Pi eingeschaltet und versucht, mich anzumelden, aber es trat folgende Fehlermeldung auf:

ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
ERROR: Someone could be eavesdropping on you right now (man-in-the-middle attack)!
ERROR: It is also possible that a host key has just been changed.
ERROR: The fingerprint for the ECDSA key sent by the remote host is
ERROR: SHA256:asfasfdasdfasfdasfdasdfasdfasdfasdfasfasdf.
ERROR: Please contact your system administrator.
ERROR: Add correct host key in /home/joedoe/.ssh/known_hosts to get rid of this message.
ERROR: Offending ECDSA key in /home/joedoe/.ssh/known_hosts:13
ERROR:   remove with:
ERROR:   ssh-keygen -f "/home/joedoe/.ssh/known_hosts" -R "192.168.5.163"
ERROR: ECDSA host key for 192.168.5.163 has changed and you have requested strict checking.
ERROR: Host key verification failed.

Ich fuhr fort und fügte hinzu .ssh/config:

host 192.168.5.163
    StrictHostKeyChecking no

aber jetzt bekomme ich

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 ECDSA key sent by the remote host is
SHA256:asdfasdfasdfasdfasdfasdfasdfasdfasdf.
Please contact your system administrator.
Add correct host key in /home/joedoe/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/joedoe/.ssh/known_hosts:13
  remove with:
  ssh-keygen -f "/home/joedoe/.ssh/known_hosts" -R "192.168.5.163"
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
[email protected]: Permission denied (publickey,password).

Das Problem besteht offensichtlich darin, dass ich mich mit derselben IP-Adresse bei zwei verschiedenen Betriebssystemen anmelden möchte, das neue Ubuntu-Betriebssystem die Einrichtung der SSH-Anmeldung jedoch nicht unterstützt und mir keinerlei Anmeldung erlaubt.

Wie muss ich vorgehen, um beide Betriebssysteme wechselseitig nutzen zu können?

Antwort1

Es gibt mehrere mögliche Lösungen.

Die einfachste Lösung ist die, die davidgo in seiner Antwort vorgeschlagen hat. Wie er erwähnt, macht sie Sie anfällig für einen MitM-Angriff (unwahrscheinlich, aber es ist gut, auch in privaten Situationen auf gute Sicherheit zu achten).

  Host 192.168.5.163
      StrictHostKeyChecking no
      UserKnownHostsFile /dev/null

Eine etwas bessere Lösung wäre, wie Eugen Rieck vorgeschlagen hat, die /etc/ssh/ssh_host_*key*Dateien zwischen beiden Zielbetriebssystemen zu synchronisieren.

Eine zuverlässigere Methode wäre, sich speziell für das zu verbindende Betriebssystem zu entscheiden, sodass Sie einen Fehler erhalten, wenn Sie sich mit dem falschen Betriebssystem verbinden. Dies würde beispielsweise dazu führen, dass Skripte, die SSH verwenden, fehlschlagen, wenn sie auf das falsche Betriebssystem abzielen.
Sie können dies erreichen, indem Sie effektiv einen Alias ​​in verwenden ~/.ssh/ssh_config.

Host raspbian-pi
  Hostname 192.168.5.163
  UserKnownHostsFile ~/.ssh/known_hosts_raspbian

Host centos-pi
  Hostname 192.168.5.163
  UserKnownHostsFile ~/.ssh/known_hosts_centos

Sie können sich dann mit verbinden, ssh <your_user>@raspbian-pium den Raspbian-Betriebssystemschlüssel abzurufen, dann auf Ihrem Raspberry Pi zu CentOS wechseln und dasselbe mit tun, ssh <your_user>@centos-pium den CentOS-Schlüssel abzurufen. Wenn Sie sich dann in Zukunft mit dem falschen Betriebssystem verbinden, wird der Hostschlüsselfehler angezeigt. Stellen Sie sicher, dass Sie beim ersten Verwenden des SSH-Befehls das richtige Betriebssystem verwenden, damit Sie den CentOS-Hostschlüssel nicht versehentlich in der Datei mit den bekannten Hosts von Raspbian speichern.

Haftungsausschluss: Ich habe diese Lösung noch nie verwendet und bin nicht in der Lage, sie zu testen, aber nach meinem Verständnis und der Dokumentation von SSH sollte sie ordnungsgemäß funktionieren.

Antwort2

Sie können das unmittelbare Problem beheben, indem Sie den Anweisungen in der Fehlermeldung folgen (dies müssen Sie bei jedem Boxwechsel tun) -

ssh-keygen -f "/home/joedoe/.ssh/known_hosts" -R "192.168.5.163"

Das Problem, auf das Sie stoßen, besteht darin, dass Ihr Computer erkannt hat, dass es sich bei dem System, bei dem er sich anmeldet, um ein anderes als das zuvor angezeigte handelt. Die Warnung dient dazu, Man-In-The-Middle-Angriffe zu verhindern.

Es gibt eine Reihe von Möglichkeiten, damit richtig umzugehen. Dazu gehören:

  1. Richten Sie Namen für jede Box ein /etc/hostsund verweisen Sie dann mit Namen auf die SSH-Verbindung, nicht mit IP. Auf diese Weise verknüpft SSH mit jedem Namen unterschiedliche Server-Fingerabdrücke.

  2. Ignorieren der Prüfung (dadurch werden Sie anfällig für Mitm-Angriffe. Tun Sie dies also nur, wenn Sie die Risiken verstehen und sich damit wohl fühlen.) Sie können diese Prüfung ignorieren, indem Sie -o UserKnownHostsFile=/dev/nullzu Ihrem SSH-Befehl hinzufügen oder-o StrictHostKeyChecking=no

    2a. Sie können eine Konfiguration erstellen, die nur die Schlüsselprüfung für die eine IP ignoriert, indem Sie Folgendes in~/.ssh/config

    Host 192.168.5.163 StrictHostKeyChecking kein UserKnownHostsFile=/dev/null

  3. Ich würde das nicht empfehlen, es sei denn, die Maschinen erfüllen dieselbe Rolle, aber Sie könnten die Hostschlüssel /etc/sshauf beiden Servern (und auf dem, den Sie geändert haben) gleich machen restart sshd. Auf diese Weise erscheinen beide Server dem Client gleich.

Antwort3

Am einfachsten geht das durch Kopieren /etc/ssh/ssh_host_*_key*von einer Installation auf die andere – dadurch erhalten beide Betriebssysteme die gleichen Hostschlüssel und damit den gleichen Fingerabdruck.

Antwort4

Ich persönlich verwende eine OpenSSH-Zertifizierungsstelle für alle meine Linux-Server. Das erspart mir viel Aufwand beim Einrichten einer neuen Zertifizierungsstelle und beim Orchestrieren meiner Endgeräte (Desktops, Laptops und Jump-Hosts), was ich zuvorgebloggt über.

Obwohl diese Funktion ursprünglich nicht für diesen (ungewöhnlichen) Anwendungsfall entwickelt wurde, bietet sie eine alternative Lösung für das Problem. Signieren Sie einfach beide Hostschlüssel mit dem privaten Schlüssel Ihrer Zertifizierungsstelle und fügen Sie den öffentlichen Teil Ihrer known_hostsDatei hinzu. Ihr SSH-Client wird dann automatisch beiden Hostschlüsselsätzen vertrauen, ohne Sie wegen der Diskrepanzen anzuschreien. Sie müssen ssh-keygen -Rjedoch möglicherweise vorher alle gespeicherten Hostschlüssel löschen.

Dies hat den Vorteil, dass beide Systeme ihre Hostschlüssel getrennt und unterschiedlich halten können, was Ihnen die Möglichkeit bietet, sie anhand der Hostschlüssel (und Zertifikate – es gibt ein „Identitäts“-Feld, das Sie beim Signieren der Zertifikate anpassen können) zu unterscheiden. Dies ist auch insofern sicher, als dass Sie einem beliebigen Host, der unter dieser bestimmten IP-Adresse angezeigt wird, nicht blind vertrauen müssen.

Auch wenn Sie sich vor geleakten Schlüsseln schützen möchten, können Sie beim Signieren der Zertifikate „erlaubte Namen/IP-Adressen“ als „Principals“ hinzufügen, zum Beispiel:

ssh-keygen -s my_ca -I "RaspOS on RPi" -h -n 192.0.2.0 ssh_host_rsa_key.pub

Das Zertifikat wirdnichtvertrauenswürdig sein, es sei denn, sie werden vom Host unter bereitgestellt 192.0.2.0, es sei denn, ein Angreifer kapert irgendwie Ihren Datenverkehrzusätzlich zudie Hostschlüssel und Zertifikate.

Nun, ich muss zugeben, dass es einfacher ist, die Host-Schlüssel zwischen beiden Betriebssystemen zu kopieren, da sie sich schließlich auf derselben physischen Maschine befinden.

verwandte Informationen