Weiteren bekannten Host hinzufügen

  • Hallo zusammen,

    Als absoluter Newbie ohne viel Ahnung in Linux und Debian habe ich ein paar Fragen...

    Ich habe einen Raspberry Pi4, welchen ich neu aufsetzen möchte - Grund dafür ist, dass ich mir irgendwie was eingefangen hab, was die Fritz!Box extrem langsam macht, und was wohl nur mit einer frischen Installation zu beseitigen ist (so in einem anderen Forum gelesen). Gleichzeitig auch Update von 32 auf 64 Bit.

    Gestartet wurde das System von einer Festplatte. Ich habe jetzt eine zweite identische Festplatte gekauft, damit ich die alte behalten und dann von dort Backups erstellen und auf die neue Platte einspielen kann. Soweit die Idee. An der praktischen Ausführung scheitert es nun aber... Auf der neuen Platte ist jetzt ein Debian lite 64Bit installiert.

    Wenn ich die alte Platte abziehe und den Raspi mit der neuen Platte boote, dann komme ich per SSH nicht auf das System. Wie zu erwarten kommt

    Code
    Host key for 192.168.188.92 has changed and you have requested strict checking.
    Host key verification failed.

    Nun möchte ich den "alten" Host Key behalten (damit ich auch weiterhin von der alten Platte starten kann) und die neue Platte hinzufügen - kann mir jemand helfen wie ich das machen muss? Hab diverse Anleitungen gelesen, aber funktioniert hat nichts davon.

    Kann man eigentlich überhaupt Backups von einer 32-Bit Installation auf die neue 64-Bit Installation übertragen damit die Systeme dann wieder laufen (ioBroker, Homebridge, Phoscon, OpenVPN)?

    Danke schon mal vorab für die Hilfe!

  • Wenn ich die alte Platte abziehe und den Raspi mit der neuen Platte boote, dann komme ich per SSH nicht auf das System. Wie zu erwarten kommt

    Code
    Host key for 192.168.188.92 has changed and you have requested strict checking.
    Host key verification failed.

    Teste mal temporär mit:

    Code
    StrictModes no

    in der sshd_config und poste mit und ohne "StrictModes no", die Ausgaben von:

    Code
    ssh -v <Host>

    (Host anpassen und ohne spitze Klammern).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Einmal ohne StrictModes no:

    Wo finde ich die sshd_config?

    EDIT: gefunden - aber wie kann ich die bearbeiten?

    Einmal editiert, zuletzt von guitardoc (4. März 2023 um 13:26)

  • Beitrag von Leroy Cemoi (4. März 2023 um 13:23)

    Dieser Beitrag wurde gelöscht, Informationen über den Löschvorgang sind nicht verfügbar.
  • Hmm, die Datei liegt aber auf dem Mac, ...

    Warum auf dem Mac? Es geht doch um die sshd_config des sshd (openssh-server) auf deinem PI, oder?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • guitardoc

    StrictHostKeyChecking ist eine Client-Option, zu setzen z.B. userabhängig in der ~/.ssh/config, systemweit in /etc/ssh/ssh_config

    Du müsstest also auf deinem Mac nach der ssh_config suchen, oder

    ssh -o StrictHostKeyChecking=no user@host zum Verbinden nutzen.


    rpi444

    StrictModes ist eine Daemon-Option, die aber nichts mit Hostkeycheck zu tun hat.

    Zitat von man sshd_config

    StrictModes

    Specifies whether sshd(8) should check file modes and ownership of the user's files and home directory before accepting lo‐

    gin. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. The

    default is yes. Note that this does not apply to ChrootDirectory, whose permissions and ownership are checked uncondition‐

    ally.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    2 Mal editiert, zuletzt von llutz (4. März 2023 um 15:08)

  • Ahh - OK. Ich vermute, du meinst aber die sshd_config? Ich hab dort mal no eingetragen und das kommt dann als Result:

  • du meinst aber die sshd_config

    Nein, meine ich nicht. Lies bitte was ich in #8 schrieb.

    PS: Mal kurz die 1€-Frage:

    Wie wahrscheinlich ist es wohl bei einer SecureShell, dass der Server über eine Option dem Clienten untersagen kann, den serverseitigen Hostkey zu prüfen?

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (4. März 2023 um 15:31)

  • Hmm, vermutlich nicht sehr wahrscheinlich?

    Aber nun weiß ich gar nicht mehr was ich machen muss. Eigentlich wollte ich ja von Anfang an nichts weiter, als mich wie immer per SSH mit dem Raspi verbinden, egal welche der beiden Platten ich nun gerade angeschlossen hab…

    Ich hatte vermutet, dass man da nur einen weiteren Schlüssel generieren muss welcher dann bekannt gegeben wird und schon verstehen die Clients dass es ein anderer Server ist der unter der gleichen IP angesprochen wird.

  • Ein "macht-man-eigentlich-nicht"-Weg wäre, den bekannten Hostkey des einen RPi (aus /etc/ssh/ ) einfach auf den anderen zu kopieren.

    Dann nutzen beiden den gleichen Hostkey und der ssh-Client meckert trotz StrictHostKeyChecking nicht.

    Wenn du nichts zu sagen hast, sag einfach nichts.

  • Hmm, wenn es keinen anderen Weg gibt?

    Dann muss ich das so machen. Allerdings ergibt sich da schon die nächste Frage - auf die eine Platte komme ich ja per SSH drauf - auf die andere ja aber nicht? Würde es denn für die Übertragung des Schlüssels gehen, wenn man die eine Platte zusätzlich mountet? Und welche Dateien muss ich dann kopieren?

  • Hmm, wenn es keinen anderen Weg gibt?

    Ein anderer wurde dir oben aufgezeigt (StrictHostKeyChecking=no), aber den wolltest du anscheinend nicht nutzen.

    Update:

    Neueres OpenSSH würde anscheinend auch ohne HostkeyCheck meutern und den Connect verweigern. Also bleibt wahrscheinlich nur die Hostkey-Kopieren-Lösung.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    2 Mal editiert, zuletzt von llutz (4. März 2023 um 17:07)

  • Das hat nicht funktioniert.

    Es kommt immer noch eine Fehlermeldung:

    5 Mal editiert, zuletzt von guitardoc (4. März 2023 um 17:01)

  • Update:

    Neueres OpenSSH würde anscheinend auch ohne HostkeyCheck meutern und den Connect verweigern. Also bleibt wahrscheinlich nur die Hostkey-Kopieren-Lösung.

    Ahhh, deswegen hat es nicht funktioniert.

    Bleibt die Frage, wie auf die neue Platte zugegriffen werden kann und welche Dateien wohin kopiert werden müssen…

    (und ich hatte mir das alles so einfach vorgestellt…)

  • Niemand mehr ...

    Füge ein Kommentarzeichen ("#") an den Anfang der 3. Zeile in der ".ssh/known_hosts"-Datei.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!