[gelöst] Problem bei Backup über SSH

[hobbyadmin]

Tja, das hat noch nicht funktioniert.
Ich habe den Eintrag jetzt auf no geändert.
Vielleicht funktioniert es so...

Code: Alles auswählen

Host *
  StrictHostKeyChecking no

[eggy]

Wenn man sowas schon macht, dann doch bitte nur für die Kiste, bei der es notwendig erscheint.

[hobbyadmin]

Wenn man sowas schon macht, dann doch bitte nur für die Kiste, bei der es notwendig erscheint.

Also 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...

[heisenberg]

Wenn man sowas schon macht, dann doch bitte nur für die Kiste, bei der es notwendig erscheint.

Das bezieht sich vermutlich darauf:

Code: Alles auswählen

Host *
  StrictHostKeyChecking no

Das bedeutet, dass Du für alle ausgehenden SSH-Verbindungen StrictHostKeyChecking abgeschaltet hast.

[MSfree]

Also ich habe diese Einstellung nur auf dem Client den es betrifft geändert.

Du kannst beim Client die Einstellungen aber auf verschiedenen Arten erwirken.

• Ä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

Du hast die erste Möglichkeit gewählt. Damit gilt diese Einstellung für alle Benutzer auf diesem Client. Solange das aber ein System ist, auf das nur du Zugriff hast und ausser deinem Benutzerkonto nur noch das root-Konto existiert, ist es im Grunde egal, welche Methode du nutzt. Du mußt dir aber im Klaren sein, daß das für jeden SSH-Server gilt, den du nutzen willst.

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

kannst du das srtikte Hostkeychecking gezielt für nur einen Host abstellen. Die Einstellung gilt dann auch nur für einen Benutzer, die Konfiguration steckt ja im Homeverzeichnis des Benutzers.

[wanne]

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.

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?

Die Coole aber komplizierte Variante ist VerifyHostKeyDNS. Dann musst du deinem DynDNS-Anbieter aber DANE beibringen, was nicht so ganz einfach ist.
Die einfachere Variante ist die:

Code: Alles auswählen

-o CheckHostIP=no

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:

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.

[uname]

Und ich verstehe weiterhin nicht, warum er nicht einfach die Richtung umkehrt. Das hatte ich ja weiter oben schon gefragt und folgende Antwort erhalten:

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.

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.

[MSfree]

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.

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]

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.

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.

[eggy]

Also 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...

Es ging um den "*".

[hobbyadmin]

Guten Morgen!
Ich muss zugeben, dass ich jetzt verwirrt bin.
Ich habe es soweit verstanden, dass ich die Einstellung nicht in /etc/ssh/ssh_config ändern sollte, weil das zu unsicher sei.
Ich habe aber die alternative Lösung noch nicht verstanden.
Daher nochmals die konkrete Frage:
Was sollte ich wo ändern, damit das Ganze nicht zu unsicher wird?

[MSfree]

Was sollte ich wo ändern, damit das Ganze nicht zu unsicher wird?

In deinem Home-Verzeichnis gibt es ein ("verstecktes") Unterverzeichnis namens ".ssh"
Wechsel in dieses Verzeichnis mit dem Befehl

Code: Alles auswählen

cd ~/.ssh

Starte hier einen Texteditor und editiere damit die Datei "config"

Code: Alles auswählen

nano config

Füge folgenden Text in diese (bei dir wahrscheinlich neue) Datei ein:

Code: Alles auswählen

Host hier.name.und.domain.des.hosts
  StrictHostKeyChecking no

Statt "hier.name.und.domain.des.hosts" ist natürlich der Hostname des Zielrechners einzutragen und nicht wörtwörtlich "hier.name.und.domain.des.hosts"

Hintergrund:
ssh sucht immer im Verzechnis ~/.ssh nach dieser "config" Datei. Dieser gilt nur für den Benutzer, mit dem du gerade eingelogt bist. Mit der expliziten Angabe des Hostnamens ist auch gewährleistet, daß die Einstellung nur für diesen einen Host gilt und alle anderen Verbindungen nicht mit dieser Einstellung durchgeführt werden.

Sicherer wird die Verbindung zu deinem Server durch diese Einstellung natürlich nicht. Aber sie ist auf diesen einen Host beschränkt und nur für diesen einen Benutzer gültig. Andere Benutzer und Verbindungen zu andern Host werden dann immerhin nicht mit dieser "unsicheren" Einstellung aufgebaut.

[hobbyadmin]

Aha,
vielen Dank für die Hilfe und die Erklärung.
Das werde ich jetzt mal so einrichten und beobachten.

[wanne]

@MSfree ich finde es unverantwortlich hier auch nach der expliziten Nachfrage nach Sicherheit weiter unsichere empfiehlst Setups empfiehlst. Zumal ich sogar drei sicherer Variante genannt habe.
@hobbyadmin
Wenn du statt

Code: Alles auswählen

Host hier.name.und.domain.des.hosts
 StrictHostKeyChecking no

Das machst

Code: Alles auswählen

Host MeinEinzigartigerBackupserver
  HostName domain.dyndns.org
  CheckHostIP no
  HostKeyAlias MeinEinzigartigerBackupserver

Und ein mal mit ssh MeinEinzigartigerBackupserver deinen HostKey checkst hast du ein vollständig sicheres Setup.
domain.dyndns.org ist der DNS-Name deines servers. MeinEinzigartigerBackupserver kann ein beliebiger Name sein den du an keiner anderen Stelle im config file benutzt. Beides kann (muss aber nicht) gleich sein.

[hobbyadmin]

@ MSfree und wanne:
Ich danke Euch beiden für Eure Hilfe.
Ich kann die Sicherheitsrisiken leider nicht einschätzen. Dafür verstehe ich zu wenig davon.
An einem Client habe ich jetzt die Lösung von MSfree eingerichtet und an einem anderen Client die Lösung von wanne. Mal sehen wie das funktioniert.

@wanne:
Bei Deiner Lösung muss ich doch auch den SSH-Befehl für die Adressierung der Datensicherung ändern oder?
bisher lautete der Befehl:

Code: Alles auswählen

ssh -p12345 benutzer@meine.dyn.dns.adresse.de

Das muss bei Deiner Lösung doch geändert werden in:

Code: Alles auswählen

ssh mein-individueller-server-name

Der Rest der Parameter steht dann in der config-Datei für ssh (im home-Verzeichnis des Nutzers).
Oder denke ich wieder falsch?

[MSfree]

Bei Deiner Lösung muss ich doch auch den SSH-Befehl für die Adressierung der Datensicherung ändern oder?
bisher lautete der Befehl:

Code: Alles auswählen

ssh -p12345 benutzer@meine.dyn.dns.adresse.de

Du kannst du Portnummer ebenfalls in die config eintragen. Wannes Konfiguration würde sich dann so ändern:

Code: Alles auswählen

Host MeinEinzigartigerBackupserver
  HostName domain.dyndns.org
  CheckHostIP no
  HostKeyAlias MeinEinzigartigerBackupserver
  Port 123445

Der dazu passende Aufruf hieße dann

Code: Alles auswählen

ssh benutzer@MeinEinzigartigerBackupserver

[wanne]

Code: Alles auswählen

ssh -p12345 benutzer@meine.dyn.dns.adresse.de

Das muss bei Deiner Lösung doch geändert werden in:

Code: Alles auswählen

ssh mein-individueller-server-name

Der Rest der Parameter steht dann in der config-Datei für ssh (im home-Verzeichnis des Nutzers).
Oder denke ich wieder falsch?

Nein. Das ist so korrekt.

Du kannst du Portnummer ebenfalls in die config eintragen.

Und der Nutzer kann natürlich auch in die Config:

Code: Alles auswählen

Host MeinEinzigartigerBackupserver
  HostName domain.dyndns.org
  CheckHostIP no
  HostKeyAlias MeinEinzigartigerBackupserver
  Port 123445
  User benutzer

[hobbyadmin]

Moin!
Beide Lösungen sind jetzt mehrere Tage fehlerfrei auf den beiden Clients gelaufen.
Da die Lösung von wanne sicherer sein soll, habe ich nun beide Clients auf wannes Lösung umgestellt und werde das weiter beobachten.
Wenn das mehrere Wochen fehlerfrei durch läuft, gebe ich nochmal eine Rückmeldung.

[hobbyadmin]

Hallo!
Hier meine versprochene Rückmeldung.
Der Lösungsansatz von "wanne" läuft jetzt ca. 2 1/2 Wochen auf den Computern und es gab keine Fehlermeldung mehr, auf keinem der Computer.
Diese Lösung kann ich also weiter empfehlen.

Vielen Dank für Eure Hilfe!

[hobbyadmin]

Moin!
Ich muss mich leider nochmals melden, weil die Einstellungen doch nicht dauerhaft funktioniert haben.
Ich hatte ja die Lösung von wanne übernommen aber nach einigen Wochen trat die Fehlermeldung wieder auf.
Ich habe jetzt die SSH-config-Datei im home-Verrzeichnis des Nutzers etwas verändert und seitdem läuft es wieder ohne Fehlermeldung
Mal abwarten, ob das auch dauerhaft so bleibt...

So sieht die SSH-config jetzt aus:

Code: Alles auswählen

Host meine.dyn.dns.adresse.de
 	CheckHostIP no
  

[hobbyadmin]

Hier noch eine elegantere Möglichkeit um mein Problem zu lösen. Das habe ich in den man-Pages zu ssh gefunden.
Man kann die Option auch direkt in den SSH-Befehl einbauen. Dann ist es auch nur auf diese eine Verbindung beschränkt. Also vielleicht noch ein kleines Stück sicherer : )

Beispiel:

Code: Alles auswählen

ssh -o "CheckHostIP no" BENUTZER@DYN.DNS.ADRESSE.DE

Das läßt sich dann natürlich auch in einen Rsync-Befehl mit ssh einsetzen. Also z.B.:

Code: Alles auswählen

rsync -aSAXHP -e 'ssh -p 12345 -o "CheckHostIP no"' /home/BENUTZER BENUTZER@DYN.DNS.ADRESSE.DE:/PFAD/ZUM/ZIELVERZEICHNIS

Mensch, man wird mit der Zeit immer besser, oder? : )
Erstaunlich was man mit Linux so alles machen kann...