[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Scp calls

From: AJ Weber
Subject: Re: [Duplicity-talk] Scp calls
Date: Mon, 4 Jan 2010 12:53:55 -0500

That would be exactly what I would have to do, which means editing the source code -- and I'm not "against" that, nor "afraid" of it, but it breaks compatibility with future duplicity upgrades, etc.

I assume I'd have to edit the sshBackend... code, but maybe it would be better to do it in the main code so the backend becomes irrelevant. I could maybe implement a "Pre-Connect" and "Post-Connect" hook of sorts that gets called before/after the actual backend connection operation.

Does anyone think that's worthwhile to develop and add to the project, and Ken, would you want to add that back into the codeline as a new feature should I develop it? I might actually do that work if it was to be included back into future versions; less enthusiastic if I was doing it just for me as a once-off.


----- Original Message ----- From: "Gabriel Ambuehl" <address@hidden> To: "AJ Weber" <address@hidden>; "Discussion of the backup program duplicity" <address@hidden>
Sent: Monday, January 04, 2010 12:41 PM
Subject: Re: [Duplicity-talk] Scp calls

On 04.01.2010 17:41, AJ Weber wrote:
It wouldn't be granular enough at that, unfortunately. I have a script that iterates my directories now, and could insert the port-knock command as well...

However, a port knock typically opens the firewall for a specified client-IP for a small window of time (typ 30sec). After that timeout, if you haven't established the TCP session, you can't get in unless you "knock" again. (Once you have an established connection, the firewall rules will continue to allow that connection, just not connect a new one.)

If I'm transferring small, incrementals, it would _probably_ work OK, because a few scp calls would likely make it within that 30sec timeout. However, if/when I run a full backup, the backup of most of those directories would take minutes (some, many minutes) to complete, so somewhere during the backup-run, the firewall will close-up the ssh port, and further scp calls will be denied/blocked. Thus the problem with a lot of individual ssh/scp connects versus one, persistent connection to tunnel the files/diffs through.

Then how about wrapping scp in a script doing the port knocking (possibly with a timeout below which it would straight go to scp without knocking, even) instead of duplicity?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]