Backup eines Windows-Rechners mit RSYNC und SSH und ein Problem mit der Authentifizierung Für das Backup verwenden wir cwRsync und copssh von Itefix für Windows und auf dem Backup-Server wird Linux mit Rsync und OpenSSH eingesetzt. Alles die aktuellsten stabilen Versionen. Vorab sei bemerkt: zwischen den Rechnern kann mit Rsync kopiert werden, mit Rsync-Serverdienst (daemon) auf dem Windows-Rechner. Es funktioniert auch die SSH-Kommunikation. Aber aufgrund eines Bugs in der Windows-Version von SSH, die von cygwin und von copssh (itefix) eingesetzt wird, müssen wir eine Variante über einen SSH-Tunnel wählen, wenn über das Internet kopiert wird (und kein VPN da ist). Wichtig ist auch, dass der Betrieb automatisiert verläuft. Also fallen alle Lösungen weg, die einen Benutzereingriff erfordern. Außerdem ist eine Bedingung, dass der Backup-Server die *Daten vom Windows-Rechner holt* und nicht umgekehrt Daten gesendet bekommt. Wir öffnen einen SSH-Tunnel mit: ssh -L 4711:localhost:873 -i sshPrivKey backup@192.168.100.19 sshPrivKey ist ein gültiger Private-Key für den Benutzer backup. Der Public-Key ist auf 192.168.100.19 installiert und der SSH- Tunnel wird auch korrekt aufgebaut (man erhält eine Shell auf dem Zielsystem). Wenn die ssh-Parameter -f -N hinzugefügt werden, läuft der Tunnel auch schön im Hintergrund. Ich hatte das System erfolgreich getestet. Mit rsync -r -t rsync://localhost:4711/testshare /tmp/ws19/ wurden die Daten der Rsync-Freigabe "testshare" nach /tmp/ws19/ kopiert. Erforderlich ist hierzu der Betrieb eines Rsync-Serverdienstes auf dem Windows-Rechner. Um diesen einigermaßen abzusichern, wird dort "auth users" und "secrets file" in der rsyncd.conf eingesetzt: auth users = backup secrets file = rsyncsecrets (in rsyncsecrets stehen "benutzer:passwort" in Klarschrift). Das rsync-Commando erhält noch die Option: --password-file=winRsyncPW (aber es geht zum testen auch mit Passwort-Eingabe auf der Kommandozeile) und schon geht es nicht mehr. Es erscheint die Meldung @ERROR: auth failed on module testshare rsync: connection unexpectedly closed (92 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(342) auf dem Linuxserver und die Meldung: 127.0.0.1 is not a known address for "pcname": spoofed address? auth failed on module testshare from unknown (127.0.0.1) Die erstere Zeile erscheint bei mir nur auf dem Windows-2000-Server der eine FAT32-Partition hat. Auf dem Windows-XP-Prof. Rechner kommt nur die untere Fehlermeldung. Auf dem FAT-System sind die Dateien immer world-readable, deshalb habe ich hier "strict modes" auf false gestellt. Und wieder zurück: sobald ich den Eintrag "auth users = backup" entferne, funktioniert alles. Kennt sich jemand damit aus? Manfred
Manfred Rebentisch wrote:
Backup eines Windows-Rechners mit RSYNC und SSH und ein Problem mit der Authentifizierung
Für das Backup verwenden wir cwRsync und copssh von Itefix für Windows und auf dem Backup-Server wird Linux mit Rsync und OpenSSH eingesetzt. Alles die aktuellsten stabilen Versionen.
Vorab sei bemerkt: zwischen den Rechnern kann mit Rsync kopiert werden, mit Rsync-Serverdienst (daemon) auf dem Windows-Rechner. Es funktioniert auch die SSH-Kommunikation. Aber aufgrund eines Bugs in der Windows-Version von SSH, die von cygwin und von copssh (itefix) eingesetzt wird, müssen wir eine Variante über einen SSH-Tunnel wählen, wenn über das Internet kopiert wird (und kein VPN da ist). Wichtig ist auch, dass der Betrieb automatisiert verläuft. Also fallen alle Lösungen weg, die einen Benutzereingriff erfordern. Außerdem ist eine Bedingung, dass der Backup-Server die *Daten vom Windows-Rechner holt* und nicht umgekehrt Daten gesendet bekommt.
Wir öffnen einen SSH-Tunnel mit:
ssh -L 4711:localhost:873 -i sshPrivKey backup@192.168.100.19
sshPrivKey ist ein gültiger Private-Key für den Benutzer backup. Der Public-Key ist auf 192.168.100.19 installiert und der SSH- Tunnel wird auch korrekt aufgebaut (man erhält eine Shell auf dem Zielsystem). Wenn die ssh-Parameter -f -N hinzugefügt werden, läuft der Tunnel auch schön im Hintergrund.
Ich hatte das System erfolgreich getestet. Mit
rsync -r -t rsync://localhost:4711/testshare /tmp/ws19/
wurden die Daten der Rsync-Freigabe "testshare" nach /tmp/ws19/ kopiert.
Erforderlich ist hierzu der Betrieb eines Rsync-Serverdienstes auf dem Windows-Rechner. Um diesen einigermaßen abzusichern, wird dort "auth users" und "secrets file" in der rsyncd.conf eingesetzt:
auth users = backup secrets file = rsyncsecrets
(in rsyncsecrets stehen "benutzer:passwort" in Klarschrift).
Das rsync-Commando erhält noch die Option: --password-file=winRsyncPW
(aber es geht zum testen auch mit Passwort-Eingabe auf der Kommandozeile) und schon geht es nicht mehr. Es erscheint die Meldung
@ERROR: auth failed on module testshare rsync: connection unexpectedly closed (92 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(342)
auf dem Linuxserver und die Meldung:
127.0.0.1 is not a known address for "pcname": spoofed address? auth failed on module testshare from unknown (127.0.0.1)
Die erstere Zeile erscheint bei mir nur auf dem Windows-2000-Server der eine FAT32-Partition hat. Auf dem Windows-XP-Prof. Rechner kommt nur die untere Fehlermeldung.
Auf dem FAT-System sind die Dateien immer world-readable, deshalb habe ich hier "strict modes" auf false gestellt.
Und wieder zurück: sobald ich den Eintrag "auth users = backup" entferne, funktioniert alles.
Kennt sich jemand damit aus?
Manfred
Hallo, das sieht doch ganz nach einem Problem in der rsyncd.conf aus. Hier gibt es doch noch den Parameter hosts.allow ; dieser bremst hier wohl die Authentifizierung aus. Wenn du mit localhost (127.0.0.1) an deinem Sever ankommst, kann der dich ja nur ablehnen. gruss/torbjoern -- [ t o r b j o e r n g r i p p ] mailto:gripp@opus5.de
Am Dienstag, 23. November 2004 14:53 schrieb Torbjörn Gripp:
Manfred Rebentisch wrote:
Backup eines Windows-Rechners mit RSYNC und SSH und ein Problem mit der Authentifizierung
..
Hallo,
das sieht doch ganz nach einem Problem in der rsyncd.conf aus. Hier gibt es doch noch den Parameter hosts.allow ; dieser bremst hier wohl die Authentifizierung aus. Wenn du mit localhost (127.0.0.1) an deinem Sever ankommst, kann der dich ja nur ablehnen.
gruss/torbjoern
Hallo, der Parameter heißt "hosts allow" und ich habe es mit "*", mit "192.168.100.0/24 127.0.0.0/8", mit "127.0.0.1" und allen möglichen Kombinationen versucht: *keine Wirkung*. Manfred
Manfred Rebentisch wrote:
Am Dienstag, 23. November 2004 14:53 schrieb Torbjörn Gripp:
Manfred Rebentisch wrote:
Backup eines Windows-Rechners mit RSYNC und SSH und ein Problem mit der Authentifizierung
..
Hallo,
das sieht doch ganz nach einem Problem in der rsyncd.conf aus. Hier gibt es doch noch den Parameter hosts.allow ; dieser bremst hier wohl die Authentifizierung aus. Wenn du mit localhost (127.0.0.1) an deinem Sever ankommst, kann der dich ja nur ablehnen.
gruss/torbjoern
Hallo, der Parameter heißt "hosts allow" und ich habe es mit "*", mit "192.168.100.0/24 127.0.0.0/8", mit "127.0.0.1" und allen möglichen Kombinationen versucht: *keine Wirkung*.
Manfred
Da muss mir wohl der Ringfinger entglitten sein :_) Ok die man page von rsyncd sagt einiges dazu. Vielleicht solltest du mal den Parameter "hosts allow" einfach auskommentieren.... Dann kannst du zumindest feststellen, ob es daran liegt oder ober du weiter lesen musst...Denn auch ueber auth users gibt es einiges in der man page insbesondere zu CONNECTING TO AN RSYNC SERVER OVER A REMOTE SHELL PROGRAMM gruss/torbjoern -- [ t o r b j o e r n g r i p p ] mailto:gripp@opus5.de
Am Dienstag, 23. November 2004 15:30 schrieb Torbjörn Gripp:
Manfred Rebentisch wrote:
Am Dienstag, 23. November 2004 14:53 schrieb Torbjörn Gripp:
Manfred Rebentisch wrote:
Backup eines Windows-Rechners mit RSYNC und SSH und ein Problem mit der Authentifizierung
...
Hallo, der Parameter heißt "hosts allow" und ich habe es mit "*", mit "192.168.100.0/24 127.0.0.0/8", mit "127.0.0.1" und allen möglichen Kombinationen versucht: *keine Wirkung*.
Da muss mir wohl der Ringfinger entglitten sein :_) ;-)
Ok die man page von rsyncd sagt einiges dazu. Vielleicht solltest du mal den Parameter "hosts allow" einfach auskommentieren.... Dann kannst du zumindest feststellen, ob es daran liegt oder ober du weiter lesen musst...Denn auch ueber auth users gibt es einiges in der man page insbesondere zu CONNECTING TO AN RSYNC SERVER OVER A REMOTE SHELL PROGRAMM
Glaubst Du, ich lese keine man pages? Ich habe mich dem Thema auch zusammen mit zwei anderen Linux-Admins gewidmet. Aber ok, die meisten Leute lesen ja nicht... Jedenfalls: auch "hosts allow" ist Banane, ob es auskommentiert ist oder was dahinter steht ist egal. Nur eine Option hat eine unmittelbare Wirkung: wenn ich "auth users" deaktiviere, dann funktioniert alles. Grüße Manfred
Manfred Rebentisch wrote:
Am Dienstag, 23. November 2004 15:30 schrieb Torbjörn Gripp:
Manfred Rebentisch wrote:
Am Dienstag, 23. November 2004 14:53 schrieb Torbjörn Gripp:
Manfred Rebentisch wrote:
Backup eines Windows-Rechners mit RSYNC und SSH und ein Problem mit der Authentifizierung
...
Hallo, der Parameter heißt "hosts allow" und ich habe es mit "*", mit "192.168.100.0/24 127.0.0.0/8", mit "127.0.0.1" und allen möglichen Kombinationen versucht: *keine Wirkung*.
Da muss mir wohl der Ringfinger entglitten sein :_)
;-)
Ok die man page von rsyncd sagt einiges dazu. Vielleicht solltest du mal den Parameter "hosts allow" einfach auskommentieren.... Dann kannst du zumindest feststellen, ob es daran liegt oder ober du weiter lesen musst...Denn auch ueber auth users gibt es einiges in der man page insbesondere zu CONNECTING TO AN RSYNC SERVER OVER A REMOTE SHELL PROGRAMM
Glaubst Du, ich lese keine man pages? Ich habe mich dem Thema auch zusammen mit zwei anderen Linux-Admins gewidmet. Aber ok, die meisten Leute lesen ja nicht...
Jedenfalls: auch "hosts allow" ist Banane, ob es auskommentiert ist oder was dahinter steht ist egal. Nur eine Option hat eine unmittelbare Wirkung: wenn ich "auth users" deaktiviere, dann funktioniert alles.
Grüße Manfred
Ich glaube gar nichts.... Ich weiss nur, das ich das weder ironisch noch oberlehrerhaft gemeint habe.. Jedenfalls klingt dein Ton so, als seist du ueber das Problem schon ziemlich genervt... Konkret steht jedenfalls nichts ueber deine bisherigen Bemuehungen in der ersten Mail... Der Trick ist, "glaube ich" jedenfalls, die uid und die gid... Bei mir hat es zwischen zwei Linux-Rechnern (weil ich mich in keiner "Risiko-Lage" befand) mit uid und gid = root problemlos funktioniert und funktioniert noch Vielleicht hast du da ja noch nicht geschaut.... Freundliche Gruesse torbjoern -- [ t o r b j o e r n g r i p p ] mailto:gripp@opus5.de
Am Dienstag, 23. November 2004 16:05 schrieb Torbjoern Gripp:
Ich glaube gar nichts.... Ich weiss nur, das ich das weder ironisch noch oberlehrerhaft gemeint habe.. Jedenfalls klingt dein Ton so, als seist du ueber das Problem schon ziemlich genervt...
Damit hast Du getroffen. Ich möchte wirklich nicht unfreundlich klingen, aber genervt bin ich wirklich.
Konkret steht jedenfalls nichts ueber deine bisherigen Bemuehungen in der ersten Mail... Der Trick ist, "glaube ich" jedenfalls, die uid und die gid... Bei mir hat es zwischen zwei Linux-Rechnern (weil ich mich in keiner "Risiko-Lage" befand) mit uid und gid = root problemlos funktioniert und funktioniert noch Vielleicht hast du da ja noch nicht geschaut....
Also, gleich mal ran (ich hatte es natürlich auch schon mit uid/gid probiert, aber es gibt ja immer noch ne Kombination...). Also, mit uid und gid geht es auch nicht. Der Rsync-Server läuft unter dem Benutzer "backup". Hier die momentan aktuelle rsyncd.conf vom Windows-2000-Rechner. Mit dem untersten Eintrag "Programme", bei dem der "auth users" nicht steht, funktioniert es. use chroot = false strict modes = false hosts allow = * log file = rsyncd.log pid file = rsyncd.pid read only = true secrets file = rsyncdsecrets transfer logging = yes uid = backup gid = SYSTEM [restore] path = /cygdrive/c/cwrsync/data read only = false auth users = backup [totalcmd] path=/cygdrive/C/totalcmd auth users = backup [Programme] path=/cygdrive/C/Programme
Manfred Rebentisch wrote:
Am Dienstag, 23. November 2004 16:05 schrieb Torbjoern Gripp:
Ich glaube gar nichts.... Ich weiss nur, das ich das weder ironisch noch oberlehrerhaft gemeint habe.. Jedenfalls klingt dein Ton so, als seist du ueber das Problem schon ziemlich genervt...
Damit hast Du getroffen. Ich möchte wirklich nicht unfreundlich klingen, aber genervt bin ich wirklich.
Konkret steht jedenfalls nichts ueber deine bisherigen Bemuehungen in der ersten Mail... Der Trick ist, "glaube ich" jedenfalls, die uid und die gid... Bei mir hat es zwischen zwei Linux-Rechnern (weil ich mich in keiner "Risiko-Lage" befand) mit uid und gid = root problemlos funktioniert und funktioniert noch Vielleicht hast du da ja noch nicht geschaut....
Also, gleich mal ran (ich hatte es natürlich auch schon mit uid/gid probiert, aber es gibt ja immer noch ne Kombination...). Also, mit uid und gid geht es auch nicht. Der Rsync-Server läuft unter dem Benutzer "backup". Hier die momentan aktuelle rsyncd.conf vom Windows-2000-Rechner. Mit dem untersten Eintrag "Programme", bei dem der "auth users" nicht steht, funktioniert es.
use chroot = false strict modes = false hosts allow = * log file = rsyncd.log pid file = rsyncd.pid read only = true secrets file = rsyncdsecrets transfer logging = yes uid = backup gid = SYSTEM
[restore] path = /cygdrive/c/cwrsync/data read only = false auth users = backup
[totalcmd] path=/cygdrive/C/totalcmd auth users = backup
[Programme] path=/cygdrive/C/Programme
Hi, da bin ich wieder.. ich habe das ganze Problem heute noch einmal "durchgespielt" bzw. auf nem linux-server mit linux-client und einem windos2000 mit cwrsync als rsync-server. Zunaechst hatte ich mit deiner Konfiguration selbst auf der linux-kiste probs, doch das war meine Dusseligkeit... Dann klappte es so: Server-Konfig: uid=root gid=root use chroot = false strict modes = false hosts allow = * transfer logging = yes log file = /var/log/rsyncd.log [test] path = /test comment = An Example auth users = gripp secrets file = /etc/rsyncd.secrets strict mode = false client aufruf: rsync -avz -vv gripp@nettelnburg::test /tmp ok! Nichts Magisches Dann Windos: Server config: use chroot = false strict modes = false hosts allow = * transfer logging = yes log file = rsyncd.log pid file = rsyncd.pid [test] path = /cygdrive/c/cwrsync/test read only = true auth users = gripp secrets file = rsyncsecrets strict modes = false Und siehe da: N I X G I N G Ich dachte ich werde bloed...und wollte schon wieder die Mailinglisten rauf und runter studieren... Da fiel mir auf, dass im Verzeichnis ../../../cwrsync zwei Dateien gleichen Namens rumlagen: rsync mit irgendwas unterschiedlich gross jedenfalls. Habe dann die Anzeige der Endungen eingeschaltet und siehe da: Die Erleuchtung::::::: rsyncd.secrets hiess rsyncd.secrets.t x t Super Editor kann man da nur sagen... Ich hoffe jetzt, dass das auch bei dir der Fall ist.. Sonst muessen wir weitersehen...Gibts doch sonst gar nicht.. gruss/torbjoern -- [ t o r b j o e r n g r i p p ] mailto:gripp@opus5.de
Am Mittwoch, 24. November 2004 14:48 schrieb Torbjoern Gripp:
Dann Windos: Server config:
use chroot = false strict modes = false hosts allow = * transfer logging = yes log file = rsyncd.log pid file = rsyncd.pid
[test] path = /cygdrive/c/cwrsync/test read only = true auth users = gripp secrets file = rsyncsecrets strict modes = false
Und siehe da: N I X G I N G
Ich dachte ich werde bloed...und wollte schon wieder die Mailinglisten rauf und runter studieren... Da fiel mir auf, dass im Verzeichnis ../../../cwrsync zwei Dateien gleichen Namens rumlagen: rsync mit irgendwas unterschiedlich gross jedenfalls. Habe dann die Anzeige der Endungen eingeschaltet und siehe da: Die Erleuchtung::::::: rsyncd.secrets hiess rsyncd.secrets.t x t Super Editor kann man da nur sagen...
Jaaaa, die Falle kenne ich schon. Aber das ist hier nicht der Fall.
Ich hoffe jetzt, dass das auch bei dir der Fall ist.. Sonst muessen wir weitersehen...Gibts doch sonst gar nicht..
Es kann natürlich schon sein, dass die secrets-Datei nicht richtig erkannt oder gelesen wird, aber es kommt dazu eben auch keine Fehlermeldung. Als Alternative habe ich schon versucht, den rsync-Daemon on the fly über ein ssh-Kommando auf dem Windows Rechner zu starten: ssh -i privSSHKey backup@192.168.100.19 "/bin/rsync --daemon -no-detach" aber das geht leider auch nicht. Auch nicht mit "net start RSyncServer". Ich glaube schon, ich muß eine eigene Rsync/SSH-Applikation für Windows schreiben ( mal eben so, ;--)). Manfred
Manfred Rebentisch wrote:
Am Mittwoch, 24. November 2004 14:48 schrieb Torbjoern Gripp:
Dann Windos: Server config:
use chroot = false strict modes = false hosts allow = * transfer logging = yes log file = rsyncd.log pid file = rsyncd.pid
[test] path = /cygdrive/c/cwrsync/test read only = true auth users = gripp secrets file = rsyncsecrets strict modes = false
Und siehe da: N I X G I N G
Ich dachte ich werde bloed...und wollte schon wieder die Mailinglisten rauf und runter studieren... Da fiel mir auf, dass im Verzeichnis ../../../cwrsync zwei Dateien gleichen Namens rumlagen: rsync mit irgendwas unterschiedlich gross jedenfalls. Habe dann die Anzeige der Endungen eingeschaltet und siehe da: Die Erleuchtung::::::: rsyncd.secrets hiess rsyncd.secrets.t x t Super Editor kann man da nur sagen...
Jaaaa, die Falle kenne ich schon. Aber das ist hier nicht der Fall.
Ich hoffe jetzt, dass das auch bei dir der Fall ist.. Sonst muessen wir weitersehen...Gibts doch sonst gar nicht..
Es kann natürlich schon sein, dass die secrets-Datei nicht richtig erkannt oder gelesen wird, aber es kommt dazu eben auch keine Fehlermeldung.
Als Alternative habe ich schon versucht, den rsync-Daemon on the fly über ein ssh-Kommando auf dem Windows Rechner zu starten:
ssh -i privSSHKey backup@192.168.100.19 "/bin/rsync --daemon -no-detach"
aber das geht leider auch nicht. Auch nicht mit "net start RSyncServer".
Ich glaube schon, ich muß eine eigene Rsync/SSH-Applikation für Windows schreiben ( mal eben so, ;--)).
Manfred
Guten Morgen, ich glaub du musst keine Applikation schreiben...mich lassen solche Sachen nicht los und so habe ich heute morgen noch einmal getestet...und zwar mit deinen Vorgaben! Das einzige was ich ausgelassen habe ist der ssh-schluessel, da der ja nur zur Automatisierung dient. Also: Auf Linux-Seite alles so wie gestern.. Dann auf der Windos-Kiste copssh in der neuesten Version 1.2.2 installiert (funktioniert nur einwandfrei, wenn der rsyncdaemon gestoppt wird!)Den user gripp mit "activate-user.sh" angelegt und zwar mit meinem normalen password dann den rsyncdaemon gestartet Als root mit ssh -L 4711:localhost:873 gripp@hunt den Tunnel gebaut und anschliessend als user gripp mit: rsync -r -t rsync://localhost:4711/test /tmp den ersten Versuch gestartet. Die Passwortabfrage erschien....das PW aus der rsyncd.secrets eingegeben .......Ergebnis genau wie bei dir mit den gleichen Ausgaben im Log der Windowskiste Ok habe ich gedacht wenn du localhost nicht kennst brauchst du einen Namen ...Armer Windos-Rechner kennt sich selbst nicht ab in die c:\winnt\system32\drivers\etc\hosts Namen eingetragen: 127.0.0.1 hunt flugs gespeichert ....und und ...ich kam am passwort vorbei. cool Nur wurden die Dateien noch nicht ins /tmp geschrieben weil ich dort keine Schreibrechte hatte - gut - das war ein Befehl und jetzt löpt dat wie wir hier oben sagen.. Wette du kriegst das jetzt hin! gruss/torbjoern -- [ t o r b j o e r n g r i p p ] systemadministrator opus 5 interaktive medien gmbh grossneumarkt 50 20459 hamburg fon: +49(0)40 350174-439 fax: +49(0)40 350174-404 mobil: 0175 9326096 mailto:gripp@opus5.de http://www.opus5.de
Am Donnerstag, 25. November 2004 11:14 schrieb Torbjoern Gripp:
ab in die c:\winnt\system32\drivers\etc\hosts Namen eingetragen: 127.0.0.1 hunt flugs gespeichert ....und und ...ich kam am passwort vorbei. cool Nur wurden die Dateien noch nicht ins /tmp geschrieben weil ich dort keine Schreibrechte hatte - gut - das war ein Befehl und jetzt löpt dat wie wir hier oben sagen.. Wette du kriegst das jetzt hin!
Hallo, vielen Dank, dass Du Dich so bemühst. Das mit der hosts Datei hatte ich auch schon probiert und jetzt noch mal gemacht. Es will trotzdem nicht (gleicher Fehler). Aber da es bei Dir geklappt hat, werde ich jetzt noch weiter forschen und alles noch mal durchgehen. Ich melde mich dann noch mal. Grüße Manfred
Am Donnerstag, 25. November 2004 11:14 schrieb Torbjoern Gripp:
Als root mit ssh -L 4711:localhost:873 gripp@hunt den Tunnel gebaut und anschliessend als user gripp mit: rsync -r -t rsync://localhost:4711/test /tmp den ersten Versuch gestartet. Die Passwortabfrage erschien....das PW aus der rsyncd.secrets eingegeben .......Ergebnis genau wie bei dir mit den gleichen Ausgaben im Log der Windowskiste Ok habe ich gedacht wenn du localhost nicht kennst brauchst du einen Namen ...Armer Windos-Rechner kennt sich selbst nicht ab in die c:\winnt\system32\drivers\etc\hosts Namen eingetragen: 127.0.0.1 hunt flugs gespeichert ....und und ...ich kam am passwort vorbei. cool Nur wurden die Dateien noch nicht ins /tmp geschrieben weil ich dort keine Schreibrechte hatte - gut - das war ein Befehl und jetzt löpt dat wie wir hier oben sagen.. Wette du kriegst das jetzt hin!
SO, JETZT haben wir es auch! ssh -f -N -L 4711:localhost:873 -i sshPrivKey backup@192.168.100.19 rsync -r -t --compress --delete --backup --numeric-ids --modify-window=1 --password-file=pwd rsync://backup@localhost:4711/totalcmd /mirror/data/ TotalCmd/ Was am Ende noch gefehlt hat, ist der "backup@" vor dem "localhost". Etwas merkwürdig, aber NUR so geht es hier. Jetzt probiere ich die Synchronisation von Massendaten. Schade nur, dass ADSL über die Upload-Leitung nur 18kB/s schiebt... Grüße Manfred
Hallo Manfred, hallo Leute, Am Dienstag, 23. November 2004 15:48 schrieb Manfred Rebentisch:
Jedenfalls: auch "hosts allow" ist Banane, ob es auskommentiert ist oder was dahinter steht ist egal. Nur eine Option hat eine unmittelbare Wirkung: wenn ich "auth users" deaktiviere, dann funktioniert alles.
Hmm, Schuss ins Blaue: erweitere den Eintrag auth users mal, damit er sowohl den Zieluser (backup@windowsrechner) als auch den User enthält, der das Backup ausführt (also irgendwer@linux). Gruß Christian Boltz -- Planung ist der Ersatz des Zufalls durch den Irrtum.
Am Mittwoch, 24. November 2004 00:27 schrieb Christian Boltz:
Hallo Manfred, hallo Leute,
Am Dienstag, 23. November 2004 15:48 schrieb Manfred Rebentisch:
Jedenfalls: auch "hosts allow" ist Banane, ob es auskommentiert ist oder was dahinter steht ist egal. Nur eine Option hat eine unmittelbare Wirkung: wenn ich "auth users" deaktiviere, dann funktioniert alles.
Hmm, Schuss ins Blaue: erweitere den Eintrag auth users mal, damit er sowohl den Zieluser (backup@windowsrechner) als auch den User enthält, der das Backup ausführt (also irgendwer@linux).
Vielen Dank, aber das hat auch nichts gebracht. Manfred
participants (4)
-
Christian Boltz -
Manfred Rebentisch -
Torbjoern Gripp -
Torbjörn Gripp