[gelöst] Problem bei Backup über SSH
-
- Beiträge: 127
- Registriert: 26.12.2020 18:13:43
[gelöst] Problem bei Backup über SSH
Moin!
Ich habe einen Backup-Server mit einer Dyn-DNS-Adresse.
Auf diesen Backup-Server werden von den Linux-Clients täglich Backups über SSH auf den Backup-Server übertragen.
Das funktioniert auch längere Zeit (mehrere Wochen) sehr gut. Nur irgendwann taucht eine eine Fehlermeldung auf die besagt, dass sich die SSH-Keys unterscheiden.
Also zum Beistpiel die Keys von ssh [meine.dyn.dns.adresse] unterscheidet sich von ssh [123.456.789.000]
Ich lösche dann den "falschen" SSH-Key mit: ssh-keygen -R [123.456.789.000] und alles läuft wieder.
Aber warum taucht diese Fehlermeldung alle paar Wochen auf?
Wie kann ich das dauerhaft verhindern?
Ich habe einen Backup-Server mit einer Dyn-DNS-Adresse.
Auf diesen Backup-Server werden von den Linux-Clients täglich Backups über SSH auf den Backup-Server übertragen.
Das funktioniert auch längere Zeit (mehrere Wochen) sehr gut. Nur irgendwann taucht eine eine Fehlermeldung auf die besagt, dass sich die SSH-Keys unterscheiden.
Also zum Beistpiel die Keys von ssh [meine.dyn.dns.adresse] unterscheidet sich von ssh [123.456.789.000]
Ich lösche dann den "falschen" SSH-Key mit: ssh-keygen -R [123.456.789.000] und alles läuft wieder.
Aber warum taucht diese Fehlermeldung alle paar Wochen auf?
Wie kann ich das dauerhaft verhindern?
Zuletzt geändert von hobbyadmin am 09.06.2022 15:37:29, insgesamt 1-mal geändert.
Re: Problem bei Backup über SSH
Immer, wenn sich die IP-Adresse deines Servers ändert, wirst du mit dieser Meldng konfrontiert. SSH stellt halt fest, daß Hostname und IP-Adresse nicht mehr zueinander passen.hobbyadmin hat geschrieben:04.05.2022 09:38:17Aber warum taucht diese Fehlermeldung alle paar Wochen auf?
Indem du auf den Clients im Homeverzeichnis eine ".config " anlegst und dortWie kann ich das dauerhaft verhindern?
Code: Alles auswählen
Host *
StrictHostKeyChecking no
Das öffnet allerdings auch ein paar Gefahren. Mittels DNS-Spoophing könnte sich jemand deines Hostnamens bemächtigen und darüber einen modifizierten SSH-Server betreiben, der alle Anmeldungen zuläßt, egal ob mit falschem Paßwort oder falschem Schlüssel, ohne, daß du merkst, daß du mit dem falschen Host kommunizierst. Und schon gehören deine Daten jemand anderem.
-
- Beiträge: 127
- Registriert: 26.12.2020 18:13:43
Re: Problem bei Backup über SSH
Danke für die Lösung! Werde ich mal so umsetzten.
Aber warum taucht dieser Fehler dann nicht täglich auf?
Mein DSL-Anbieter macht täglich eine Zwangstrennung und die Fritzbox bekommt täglich eine neue IP-Adresse.
Die Dyn-DNS-Adresse bleibt natürlich immer gleich.
SSH müsste daher doch täglich diese Fehlermeldung liefern, weil sich die IP-Adresse täglich ändert. Oder mache ich einen Denkfehler?
Aber warum taucht dieser Fehler dann nicht täglich auf?
Mein DSL-Anbieter macht täglich eine Zwangstrennung und die Fritzbox bekommt täglich eine neue IP-Adresse.
Die Dyn-DNS-Adresse bleibt natürlich immer gleich.
SSH müsste daher doch täglich diese Fehlermeldung liefern, weil sich die IP-Adresse täglich ändert. Oder mache ich einen Denkfehler?
Re: Problem bei Backup über SSH
Bist du sicher?hobbyadmin hat geschrieben:04.05.2022 10:33:46Mein DSL-Anbieter macht täglich eine Zwangstrennung und die Fritzbox bekommt täglich eine neue IP-Adresse.
Viele Provider machen inzwischen keine Zwangstrennung mehr, weil das im Grunde unsinnig ist. Anfangs wollte man damit den knappen IPv4-Bereich gerechter verteilen, wer gerade nicht online ist, braucht auch keine IP-Adresse. In Zeilten von always online würfelt man mit der Zwangstrennung nur die Adressen durcheinander, die Anzahl genutzer Adressen bleibt jedoch gleich, somit kann der Provider auch auf die Zwangstrennung verzichten. Bei mir ist die IP normalerweise über Monate konstant und ändert sich nur, wenn der Provider am DSLAM Wartung oder Resets durchführt, bzw. wenn ich den Router rebooten muß.
Re: Problem bei Backup über SSH
@hobbyadmin
Kurze Verständnisfrage: Hat dein Server im Internet eine feste Adresse (z. B. Namen oder IP-Adresse)?
Wenn ja könnte vielleicht dein Backup-Server die Daten umgekehrt vom Server abholen.
Bzgl. Sicherheit brauchst du dir keine Gedanken machen, solange du nur SSH-Keys erlaubst.
Umgekehrt sparst du dir ja auch den Zugriff aus dem Internet nach Hause.
Kurze Verständnisfrage: Hat dein Server im Internet eine feste Adresse (z. B. Namen oder IP-Adresse)?
Wenn ja könnte vielleicht dein Backup-Server die Daten umgekehrt vom Server abholen.
Bzgl. Sicherheit brauchst du dir keine Gedanken machen, solange du nur SSH-Keys erlaubst.
Umgekehrt sparst du dir ja auch den Zugriff aus dem Internet nach Hause.
-
- Beiträge: 127
- Registriert: 26.12.2020 18:13:43
Re: Problem bei Backup über SSH
@MSfree:
Ja, leider gibt es bei meinem Provider jede Nacht eine Zwangstrennung. Ich habe nur nicht kontrolliert, ob es auch jede Nacht dann auch eine neue IP-Adresse gibt. Schaue ich nochmal.
@ uname:
Ja, der Server hat eine feste IP-Adresse. Ich möchte die Daten aber lieber nicht vom Backup-Server abholen lassen. Wenn möglich, soll der Server die Daten an den Backup-Server senden.
Was ich dabei grundsätzlich nicht verstehe ist, warum da überhaupt ein Problem besteht. Ich habe ja ganz bewußt eine Dyn-DNS-Adresse für den Backup-Server eingerichtet, weil ich die dauernd wechselnden IP-Adressen umgehen wollte. Warum reicht das denn immer noch nicht? Dann braucht man doch auch keine Dy-DNS-Adressen, oder?
Ja, leider gibt es bei meinem Provider jede Nacht eine Zwangstrennung. Ich habe nur nicht kontrolliert, ob es auch jede Nacht dann auch eine neue IP-Adresse gibt. Schaue ich nochmal.
@ uname:
Ja, der Server hat eine feste IP-Adresse. Ich möchte die Daten aber lieber nicht vom Backup-Server abholen lassen. Wenn möglich, soll der Server die Daten an den Backup-Server senden.
Was ich dabei grundsätzlich nicht verstehe ist, warum da überhaupt ein Problem besteht. Ich habe ja ganz bewußt eine Dyn-DNS-Adresse für den Backup-Server eingerichtet, weil ich die dauernd wechselnden IP-Adressen umgehen wollte. Warum reicht das denn immer noch nicht? Dann braucht man doch auch keine Dy-DNS-Adressen, oder?
Re: Problem bei Backup über SSH
@hobbyadmin
Also ich würde die Daten umgekehrt übertragen. Warum sollte der Backup-Server die Daten nicht einfach downloaden.
Dein Problem habe ich noch nicht ganz verstanden. Aber vielleicht irgendein Problem mit dem Host-Key, der sich ändert oder nicht mehr zum Namen/IP-Adresse passt.
Du kannst mal das ausprobieren:
Ja ist ein wenig unsicherer. Aber was solls.
Ich habe das mal hier verwendet.
Also ich würde die Daten umgekehrt übertragen. Warum sollte der Backup-Server die Daten nicht einfach downloaden.
Dein Problem habe ich noch nicht ganz verstanden. Aber vielleicht irgendein Problem mit dem Host-Key, der sich ändert oder nicht mehr zum Namen/IP-Adresse passt.
Du kannst mal das ausprobieren:
Code: Alles auswählen
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no meine.dyn.dns.adresse
Ich habe das mal hier verwendet.
-
- Beiträge: 127
- Registriert: 26.12.2020 18:13:43
Re: Problem bei Backup über SSH
OK, danke!
Das werde ich auch probieren.
Das Problem beim "abholen" der Daten, also wenn der Backup-Server die Daten vom Arbeits-Server abholt ist, dass der Arbeitsserver zwar eine feste IP hat aber hinter einer sehr strengen Firewall sitzt. Da will und kann ich nicht dran rum fummeln. Ausgehende SSH-Verbindungen sind aber möglich. Also möchte ich es gerne so lassen und die Daten vom Arbeits-Server über SSH auf den Backup-Server senden.
Das werde ich auch probieren.
Das Problem beim "abholen" der Daten, also wenn der Backup-Server die Daten vom Arbeits-Server abholt ist, dass der Arbeitsserver zwar eine feste IP hat aber hinter einer sehr strengen Firewall sitzt. Da will und kann ich nicht dran rum fummeln. Ausgehende SSH-Verbindungen sind aber möglich. Also möchte ich es gerne so lassen und die Daten vom Arbeits-Server über SSH auf den Backup-Server senden.
Re: Problem bei Backup über SSH
Der SSH-Client bekommt vom SSH-Server einen Hostkey übermittelt. Diesen Hostkey trägt der Client in die Datei ~/.ssh/known_hosts ein, und zwar inklusive Hostname und IP-Adresse. Wenn jetzt dein SSH-Server bei der nächsten SSH-Verbindung senen Hostkey erneut überträgt, wird der mit den gespeicherten Hostkeys verglichen. Wenn dann IP oder Hostname nicht mehr zum Hostkey passen, gibt es die oben genannte Meldung. Diese Prüfung kann man unterdrücken, was aber eben mit Risiken verbunden ist.hobbyadmin hat geschrieben:04.05.2022 13:27:54Was ich dabei grundsätzlich nicht verstehe ist, warum da überhaupt ein Problem besteht. ...Warum reicht das denn immer noch nicht? Dann braucht man doch auch keine Dy-DNS-Adressen, oder?
Das ist ja auch richtig so, und ohne den DNS-Eintrag würdest du den Rechner gar nicht erreichen können. Aber gerade über SSH ergibt sich dann eben das Problem, daß die sich ändernde IP dann nicht mehr zur gespeicherten Einheit aus Hostname, Hostkey und vorheriger IP-Adresse paßt.Ich habe ja ganz bewußt eine Dyn-DNS-Adresse für den Backup-Server eingerichtet, weil ich die dauernd wechselnden IP-Adressen umgehen wollte.
Re: Problem bei Backup über SSH
Falls du wirklich heute aus dem Internet für den Server kein SSH erlaubst (egal in welcher Form), dann wäre natürlich eine Kommunikationsumkehr bei SSH ein weiteres Loch in deinem Server. Wenn du aber sowieso in irgendeiner Form SSH erlaubst (z. B. Administration), so kannst du getrost auch das Backup-Script zulassen. Man kann z. B. in authorized_keys über command="..." ganz spezielle Befehle für ganz spezielle SSH-Keys erlauben. Auch kannst du noch eine Passphrase verwenden falls dir mal jemand den Private-Key klaut.hobbyadmin hat geschrieben:Das Problem beim "abholen" der Daten, also wenn der Backup-Server die Daten vom Arbeits-Server abholt ist, dass der Arbeitsserver zwar eine feste IP hat aber hinter einer sehr strengen Firewall sitzt. Da will und kann ich nicht dran rum fummeln.
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Problem bei Backup über SSH
Zum Thema strenge Host-Key Überprüfung...
Zur Option StrictHostKeyChecking
Da gibt es ja verschiedene Einstellungen in den ssh-client optionen(man ssh_config).
Zur Option HostKeyAlias
HostKeyAlias erlaubt es für einen bestimmten Host einen Alias zu setzen, der auch bei geänderter IP-Adresse für die HostKey-Überprüfung herangezogen wird. D. h. auch wenn Dein Host eine neue IP-Adresse zugewiesen bekommt, wird der Key akzeptiert, auch wenn der in Verbindung mit dieser IP-Adresse noch nicht in den KnownHostsFiles enthalten ist. Ebenso wird bei StrictHostKeyChecking=yes der Key als neuer Key für diese IP-Adresse aufgenommen(Habe ich gerade nochmal geprüft). Der zusätzliche Eintrag im UserKnownHostsFile für die neue IP und dem bekannten Key ist wohl dafür da, falls mal eine bekannte IP mit einem geänderten Key auftritt, das dann die Verbindung dorthin verweigert wird.
Die Kombination beider Optionen scheint mir die volle Sicherheit der HostKeyChecks bei dynamischen IPs aufrecht zu erhalten.
Also das Fragment des SSH-Kommandos wäre dann:
Weitere Detailinformationen dazu via: man ssh_config
Wenn man das Verhalten des SSH-Kommandos ansonsten noch prüfen, will, so wie es das Backup ausführt, ist es evtl. noch hilfreich die Option BatchMode=yes zu setzen.
P. S.: Das habe ich nicht herausgefunden, weil ich so fleissig man-pages lese, sondern weil Proxmox die Optionen genauso verwendet und die HostKeyChecks gelegentlich mal fehlschlagen, wenn ich mit meinem Konfigurations-Management in die Proxmox-Konfiguration eingreife...
Nachtrag
Zum Thema Push/Pull-Backup...
Ich finde es besser, wenn der Backupserver sich die Daten holt, als dass sie vom zu sichernden System selbst drauf geschoben werden. Grund: Wenn das zu sichernde System kompromitiert ist, dann kann man von dort aus auch noch die Backups zerstören. Konsequenz ist hier aber auch, dass ein Backup-Server der ggf. Zugriff auf viele Systeme hat, ein entsprechend lohnendes Ziel ist, das besondert abgesichert werden sollte.
Zur Option StrictHostKeyChecking
Da gibt es ja verschiedene Einstellungen in den ssh-client optionen(man ssh_config).
- yes
- accept-new
- no / off
- ask (=default)
Zur Option HostKeyAlias
HostKeyAlias erlaubt es für einen bestimmten Host einen Alias zu setzen, der auch bei geänderter IP-Adresse für die HostKey-Überprüfung herangezogen wird. D. h. auch wenn Dein Host eine neue IP-Adresse zugewiesen bekommt, wird der Key akzeptiert, auch wenn der in Verbindung mit dieser IP-Adresse noch nicht in den KnownHostsFiles enthalten ist. Ebenso wird bei StrictHostKeyChecking=yes der Key als neuer Key für diese IP-Adresse aufgenommen(Habe ich gerade nochmal geprüft). Der zusätzliche Eintrag im UserKnownHostsFile für die neue IP und dem bekannten Key ist wohl dafür da, falls mal eine bekannte IP mit einem geänderten Key auftritt, das dann die Verbindung dorthin verweigert wird.
Die Kombination beider Optionen scheint mir die volle Sicherheit der HostKeyChecks bei dynamischen IPs aufrecht zu erhalten.
Also das Fragment des SSH-Kommandos wäre dann:
Code: Alles auswählen
ssh -o HostKeyAlias=MeinBackupServer -o StrictHostKeyChecking=yes targetuser@dyndns.host.name
Wenn man das Verhalten des SSH-Kommandos ansonsten noch prüfen, will, so wie es das Backup ausführt, ist es evtl. noch hilfreich die Option BatchMode=yes zu setzen.
P. S.: Das habe ich nicht herausgefunden, weil ich so fleissig man-pages lese, sondern weil Proxmox die Optionen genauso verwendet und die HostKeyChecks gelegentlich mal fehlschlagen, wenn ich mit meinem Konfigurations-Management in die Proxmox-Konfiguration eingreife...
Nachtrag
Zum Thema Push/Pull-Backup...
Ich finde es besser, wenn der Backupserver sich die Daten holt, als dass sie vom zu sichernden System selbst drauf geschoben werden. Grund: Wenn das zu sichernde System kompromitiert ist, dann kann man von dort aus auch noch die Backups zerstören. Konsequenz ist hier aber auch, dass ein Backup-Server der ggf. Zugriff auf viele Systeme hat, ein entsprechend lohnendes Ziel ist, das besondert abgesichert werden sollte.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
-
- Beiträge: 127
- Registriert: 26.12.2020 18:13:43
Re: Problem bei Backup über SSH
Moin!
Ich habe jetzt nochmals geschaut.
Der DSL-Anbieter macht leider jede Nacht eine Zwangstrennung und vergibt scheinbar auch neue IP-Adressen.
Die push/pull Frage kann ich wahrscheinlich aufklären. Ich war nur zu faul, das alles zu schreiben.
Ich habe innerhalb des sicheren Arbeitsnetzwerkts einen kleinen Hilfsserver aufgesetzt. Dieser kleine Hilfsserver HOLT täglich die Daten vom Arbeitsserver innerhalb des Arbeitsnetzwerks. Im Anschluss werden die Daten dann von diesem kleinen Hilfsserver mittels Borg-Backup und SSH auf den entfernten Backup-Server übertragen.
Ich habe das so gemacht, weil an der Firewall nichts verändert werden soll. Von aussen kann ich auch nicht auf diesen Server zugreifen, auch nicht zur Administration. Wie gesagt, alles sehr sicher...
Jetzt zurück zum Problem:
Jede Nacht wird also Borg-Backup gestartet und die Daten werden an den entfernten Backup-Server übertragen. Alle paar Wochen gibt es dabei eine Fehlermeldung, weil angeblich die Dyn-DNS-Adresse und die IP-Adresse in der Datei known_hosts nicht übereinstimmen.
Borg-Backup verwendet folgenden Befehl für die Datenübertragung. Bitte sagt mir, wo ich dort die von Euch genannten Parameter eintragen soll. Vielen Dank!
Ich habe jetzt nochmals geschaut.
Der DSL-Anbieter macht leider jede Nacht eine Zwangstrennung und vergibt scheinbar auch neue IP-Adressen.
Die push/pull Frage kann ich wahrscheinlich aufklären. Ich war nur zu faul, das alles zu schreiben.
Ich habe innerhalb des sicheren Arbeitsnetzwerkts einen kleinen Hilfsserver aufgesetzt. Dieser kleine Hilfsserver HOLT täglich die Daten vom Arbeitsserver innerhalb des Arbeitsnetzwerks. Im Anschluss werden die Daten dann von diesem kleinen Hilfsserver mittels Borg-Backup und SSH auf den entfernten Backup-Server übertragen.
Ich habe das so gemacht, weil an der Firewall nichts verändert werden soll. Von aussen kann ich auch nicht auf diesen Server zugreifen, auch nicht zur Administration. Wie gesagt, alles sehr sicher...
Jetzt zurück zum Problem:
Jede Nacht wird also Borg-Backup gestartet und die Daten werden an den entfernten Backup-Server übertragen. Alle paar Wochen gibt es dabei eine Fehlermeldung, weil angeblich die Dyn-DNS-Adresse und die IP-Adresse in der Datei known_hosts nicht übereinstimmen.
Borg-Backup verwendet folgenden Befehl für die Datenübertragung. Bitte sagt mir, wo ich dort die von Euch genannten Parameter eintragen soll. Vielen Dank!
Code: Alles auswählen
[ssh://user@meine.dyn.dns.adresse:12345/pfad/zum/zielverzeichnis/code]
Zuletzt geändert von hobbyadmin am 09.05.2022 12:32:43, insgesamt 1-mal geändert.
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Problem bei Backup über SSH
Wie man bei Borg ssh-Einstellungen setzt, weiss ich aus dem Kopf nicht. Ich verweise mal an die Borg-Dokumentation. Da wird sich sicher etwas dazu finden lassen.
Alternativ dazu ist es bestimmt möglich, dass ganze in $HOME/.ssh/config festzulegen. Siehe man ssh_config.
Beispiel aus der $HOME/.ssh/config
Alternativ dazu ist es bestimmt möglich, dass ganze in $HOME/.ssh/config festzulegen. Siehe man ssh_config.
Beispiel aus der $HOME/.ssh/config
Code: Alles auswählen
Host aws01
Hostname ec2-1-11-98-114.eu-central-1.compute.amazonaws.com
User admin
Port 22
IdentityFile ~/.ssh/aws-keypair.pem
Jede Rohheit hat ihren Ursprung in einer Schwäche.
-
- Beiträge: 127
- Registriert: 26.12.2020 18:13:43
Re: Problem bei Backup über SSH
Hallo!
Hier kommt meine Rückmeldung.
Weil ich die Einstellungen in Borg-Backup nicht zu meiner Zufriedenheit umsetzen konnte, habe ich die SSH-Einstellung in /etc/ssh/ssh_config
geändert. Ich hoffe, dass ich kein all zu großes Sicherheitsrisiko...
Hier kommt meine Rückmeldung.
Weil ich die Einstellungen in Borg-Backup nicht zu meiner Zufriedenheit umsetzen konnte, habe ich die SSH-Einstellung in /etc/ssh/ssh_config
geändert. Ich hoffe, dass ich kein all zu großes Sicherheitsrisiko...
-
- Beiträge: 127
- Registriert: 26.12.2020 18:13:43
Re: Problem bei Backup über SSH
Ich habe das falsch geschieben.
Ich habe die Einstellung im Client wie folgt geändert. Mal sehen, ob es funktioniert.
Ich habe die Einstellung im Client wie folgt geändert. Mal sehen, ob es funktioniert.
Code: Alles auswählen
Host *
StrictHostKeyChecking accept-new
-
- Beiträge: 127
- Registriert: 26.12.2020 18:13:43
Re: Problem bei Backup über SSH
Tja, das hat noch nicht funktioniert.
Ich habe den Eintrag jetzt auf no geändert.
Vielleicht funktioniert es so...
Ich habe den Eintrag jetzt auf no geändert.
Vielleicht funktioniert es so...
Code: Alles auswählen
Host *
StrictHostKeyChecking no
Re: Problem bei Backup über SSH
Wenn man sowas schon macht, dann doch bitte nur für die Kiste, bei der es notwendig erscheint.
-
- Beiträge: 127
- Registriert: 26.12.2020 18:13:43
Re: Problem bei Backup über SSH
Also ich habe diese Einstellung nur auf dem Client den es betrifft geändert.eggy hat geschrieben:13.05.2022 09:20:44Wenn man sowas schon macht, dann doch bitte nur für die Kiste, bei der es notwendig erscheint.
Am Server habe ich keinerlei Einstellung verändert.
Ich hoffe, das ist in Ordnung so und nicht zu unsicher...
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Problem bei Backup über SSH
Das bezieht sich vermutlich darauf:eggy hat geschrieben:13.05.2022 09:20:44Wenn man sowas schon macht, dann doch bitte nur für die Kiste, bei der es notwendig erscheint.
Code: Alles auswählen
Host *
StrictHostKeyChecking no
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: Problem bei Backup über SSH
Du kannst beim Client die Einstellungen aber auf verschiedenen Arten erwirken.hobbyadmin hat geschrieben:16.05.2022 11:14:13Also ich habe diese Einstellung nur auf dem Client den es betrifft geändert.
- Ändern der Datei /etc/ssh/ssh_config
- Ändern der Datei ~/.ssh/config global für alle Hosts
- Ändern der Datei ~/.ssh/config nur für einen bestimmten Hosts
Methode 3 wäre die von mir bevorzugte. Mit einem Eintrag nach dem Schema
Code: Alles auswählen
Host hier.name.und.domain.des.hosts
StrictHostKeyChecking no
Re: Problem bei Backup über SSH
Ich bin erschüttert wie wie viele Leute hier einfach antworten dass man halt die Sicherheit von SSH abschalten soll.
Und sorry:
-o StrictHostKeyChecking=no + DynDNS heißt dass defakto jeder der es darauf anlegt Zugangsdaten+Backup abziehen.* Das Überprüfen des SSH fragt nicht zum Spaß, den Host-Key zu überprüfen. Es sendet instantan danach das Passwort an jeden der danach fragt.
Trust on first Use (Die erste mal ist die Verbindung unsicher) ist wie SSH oft genutzt wird, das eine jedes mal erneut jeden HostKeys zu akzeptieren ist sogar noch unter telnet Sicherheitsniveau. Und DynDNS lässt sich üblicherweise verdammt einfach fälschen.
Die einfachere Variante ist die: Dann achtet er nur noch auf Hostnamen. Weil das so ein bisschen ein loses Ding ist, das eventuell gefaked werden kann noch optimaler mit HostKeyAlias:
* Tatsächlich gilt das alles nur für Authentification mit Passwort der öffentlichem Schlüssel. Wer bei SSH einen privaten Key akzeptieren will braucht den öffentlichen Schlüssel. Es gibt also die Möglichkeit den öffentlichen schlüssel einfach ebenfalls geheim zu halten und sozusagen mit einem Keypair zwei private schlüssel zu haben. Dann wird die HostKeyVerification überflüssig. Bedenke aber dass du den Öffentlichen schlüssel dann wirklich geheim behalten musst und kein SSH-Sessions zu anderen (unvertrauenswürdigen) Servern mit dem selben Key aufbauen darfst.
Und sorry:
-o StrictHostKeyChecking=no + DynDNS heißt dass defakto jeder der es darauf anlegt Zugangsdaten+Backup abziehen.* Das Überprüfen des SSH fragt nicht zum Spaß, den Host-Key zu überprüfen. Es sendet instantan danach das Passwort an jeden der danach fragt.
Trust on first Use (Die erste mal ist die Verbindung unsicher) ist wie SSH oft genutzt wird, das eine jedes mal erneut jeden HostKeys zu akzeptieren ist sogar noch unter telnet Sicherheitsniveau. Und DynDNS lässt sich üblicherweise verdammt einfach fälschen.
Die Coole aber komplizierte Variante ist VerifyHostKeyDNS. Dann musst du deinem DynDNS-Anbieter aber DANE beibringen, was nicht so ganz einfach ist.hobbyadmin hat geschrieben:04.05.2022 13:27:54Was ich dabei grundsätzlich nicht verstehe ist, warum da überhaupt ein Problem besteht. Ich habe ja ganz bewußt eine Dyn-DNS-Adresse für den Backup-Server eingerichtet, weil ich die dauernd wechselnden IP-Adressen umgehen wollte. Warum reicht das denn immer noch nicht? Dann braucht man doch auch keine Dy-DNS-Adressen, oder?
Die einfachere Variante ist die:
Code: Alles auswählen
-o CheckHostIP=no
Code: Alles auswählen
-o CheckHostIP=no -o HostKeyAlias=MeinEinzigartigerBackupserver
* Tatsächlich gilt das alles nur für Authentification mit Passwort der öffentlichem Schlüssel. Wer bei SSH einen privaten Key akzeptieren will braucht den öffentlichen Schlüssel. Es gibt also die Möglichkeit den öffentlichen schlüssel einfach ebenfalls geheim zu halten und sozusagen mit einem Keypair zwei private schlüssel zu haben. Dann wird die HostKeyVerification überflüssig. Bedenke aber dass du den Öffentlichen schlüssel dann wirklich geheim behalten musst und kein SSH-Sessions zu anderen (unvertrauenswürdigen) Servern mit dem selben Key aufbauen darfst.
rot: Moderator wanne spricht, default: User wanne spricht.
Re: Problem bei Backup über SSH
Und ich verstehe weiterhin nicht, warum er nicht einfach die Richtung umkehrt. Das hatte ich ja weiter oben schon gefragt und folgende Antwort erhalten:
Weil irgendjemand den SSH-Port angreift? Einfach den Port umlegen oder Fail2Ban nutzen. Auch passiert sowieso nichts solange du nur SSH-Keys zulässt. Es gibt so viele Server im Internet wo SSH läuft. Und noch mehr Server mit HTTPS.hobbyadmin hat geschrieben:Ja, der Server hat eine feste IP-Adresse. Ich möchte die Daten aber lieber nicht vom Backup-Server abholen lassen. Wenn möglich, soll der Server die Daten an den Backup-Server senden.
Re: Problem bei Backup über SSH
Sollte man nicht sowieso für unterschiedliche Server auch unterschiedliche Schlüsselpaare verwenden? Für Paßwörter gilt ja die gleiche Regel, daß man für jeden Dienst ein anderes Paßwort nutzen sollte.wanne hat geschrieben:16.05.2022 15:07:11Bedenke aber dass du den Öffentlichen schlüssel dann wirklich geheim behalten musst und kein SSH-Sessions zu anderen (unvertrauenswürdigen) Servern mit dem selben Key aufbauen darfst.
Re: Problem bei Backup über SSH
Die Idee von den Public-Key Kryptografie ist ja eben, dass man den Aufwand nicht betreiben muss und die öffentlichen Schlüssel veröffentlichen und so einfach verteilen kann, da man vom öffentlichen nicht auf den privaten Schlüssel kommt. Jeder Webserver brüllt seinen öffentlichen Schlüssel nur so in die Gegend. Das Debianforum stellt ja auch nicht für jeden Nutzer neue Zertifikate aus. Das Problem ist, dass du dann immer noch mal Authentifizierung in die andere Richtung brauchst. Im Web passiert das oft per Passwort. SSH kannst du in beide Richtungen PubKeys fahren. Bei größeren Setups macht das schon Sinn. Es gibt viel Infrastruktur, die die öffentlichen Host-Schlüssel gleich auf ner Website veröffentlicht und passende Nutzer-Schlüssel gleich auf alle Maschinen legt, wo der User zugriff bekommen soll. Privat reicht aber eben eigentlich einfach ein Pair aus zwei "privaten" Keys.Sollte man nicht sowieso für unterschiedliche Server auch unterschiedliche Schlüsselpaare verwenden? Für Paßwörter gilt ja die gleiche Regel, daß man für jeden Dienst ein anderes Paßwort nutzen sollte.
rot: Moderator wanne spricht, default: User wanne spricht.
Re: Problem bei Backup über SSH
Es ging um den "*".hobbyadmin hat geschrieben:16.05.2022 11:14:13Also ich habe diese Einstellung nur auf dem Client den es betrifft geändert.
Am Server habe ich keinerlei Einstellung verändert.
Ich hoffe, das ist in Ordnung so und nicht zu unsicher...