no, the backuppc server wont have any idea where to find the client. the
client needs to make the connection.
as for the login session:
log in as a specific remote backup user. lets say reback. reback has no
permissions on the system except and entry in the sudoers file.
build the entire backup script and put it is a common readable location(rx,
not w) and then set the new users shell to that script instead of /bin/bash
or /bin/sh. so long as the script does not ever read input, it wont be able
to. it also wont be able to be broken out of as there is no shell to
interpret the break. now, allow passwordless sudo in the /etc/sudoers file
but only for specific commands. specifically the BackupPC_servermsg and
nothing else. that would technically allow anyone to run the script with
sudo, but they cannot write to the file so that should be safe as well.
then the 'shell' script should launch the backup with a
#!/bin/bash
echo Backup in progress...(or something witty!)
sudo -u backuppc '/path/to/BackupPC_servermsg hostname 1'
(that might not be right, i dont have backuppc on my home pc!)
now whenever that username logs in(reback) it will launch the backup and
then bail out at the end or bail out if the command crashes. remember, the
user has no access to any command interpreter!
as long as the client is configured with the right IP address and port in
the client config, then all should be well.
also, make the reback user have no password or else the script will ask for
one, unless thats what you want to happen.
the downside is having a specific user on the system just for the remote
command and a 'shell' for each user also.
if you rely on the ssh client on the client side passing the script across
then i dont know how you get a passwordless system without compromising
security without using some other software or a daemon to act as a buffer.
On Dec 10, 2007 8:23 PM, Gene Horodecki <[EMAIL PROTECTED]> wrote:
> A question: are you able to initiate the tunnel from the BackupPC server?
> It will be more easily to do that way, I think.
>
> I ask because with the example I gave in the wiki, I am unable to initiate
> the tunnel from the client because of the firewall on the client. The
> technique would be different, depending on your answer.
>
>
>
> "dan" <[EMAIL PROTECTED]> wrote:
>
> Hi all.
>
> Is anyone currently backing up over an ssh tunnel? and if so are you
> using putty and some manual steps or have you perfected an automatic system?
>
> I have an idea on it and I'll lay that out. I am not familiar with using
> the direct cygwin rsync and rsyncd and have not yet installed and played
> with them.
>
> I want to do this all with a command line ssh client so that i can put it
> in a script and put an icon on the startmenu to launch a backup remotely.
>
> so the idea is, the script starts by initiating the ssh connection for the
> tunnel and a specific port for each laptop so i would choose something like
> 2401 for the first laptop and 2402 for the second and so on.
>
> the next step is initiating an additional ssh connection to run the remote
> command for the backup, using the BackupPC_servermsg with the appropriate
> flags for incremental backups.
>
> and final killing the tunnel. in not sure if doing this on the client
> side or on the server side would be best and just how to do it.
>
> the client to be backed up would be configured with 'clientalias' equal to
> 127.0.0.1:2401 or the corrisponding port.
>
> any thoughts on this? anyone doing something like this?
>
> note: i would still be using deltacopy as my local rsyncd as it has a
> great interface to work with and already runs as a daemon on windows startup
> with no hassle. im sure the process of building the tunnel and initiating
> the backup doesnt care about what rsyncd is used. i would also like to
> enable compression on the ssh tunnel!
>
> alternatively we could use putty and put a remote command to run in even
> if that command is a script on the server side.
> ------------------------------
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ------------------------------
> _______________________________________________
> BackupPC-users mailing list
> [email protected]
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
>
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
