Hmm.. Sounds like it might work.  Please send me an update when you get it
working!

To get ssh to sign in without a password is no problem.  I googled and
quickly found the following page but there are probably hundreds with the
instructions on how to do it:

http://www.mines.edu/~gmurray/HowTo/sshNotes.html

Search down to the section 'OpenSSH to OpenSSH'

Basically you generate a public/private key pair (with a blank passphrase)
on the client and then transfer the public key to the server.  This tells
the server you are allowed to sign on, it's a one way authentication; the
server can't use the public key to sign onto the client.  You'll have to do
it manually once because there is a prompt just to verify the server
machine to defend against a man in the middle attack.  But after that your
ssh command will work seamlessly.  If this first time prompt is a problem
then I think there is a known hosts file you can add the server to on the
client.

It feels to me like there has got to be a way to do this using only a
single user with access only to the BackupPC command.  There should be a
way for your script to detect what server it's talking to and kick off the
correct command.  SSH itself knows which server it's talking to by looking
at the key.... Perhaps something related to that.

I'd suggest altering my rsync-ping script to do the job but it wouldn't be
secure... Someone could alter their hostresponse.txt file with someone
elses client and that could cause problems.  Unless you could add a
password within the file somehow..

Anyway, good luck!  Sounds like an interesting project.

"dan" <[EMAIL PROTECTED]> wrote:

>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 <<a
>href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>> wrote:
><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt
>0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> 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" <<a target="_blank"
>href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>> 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
>><a target="_blank" href="http://127.0.0.1:2401";>127.0.0.1:2401</a> 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.
>><a target="_blank"
>>href="http://sourceforge.net/services/buy/index.php";>http://sourceforge.net/services/buy/index.php</a>
>>--------------------------------
>>
>>_______________________________________________
>>BackupPC-users mailing list
>><a target="_blank"
>>href="mailto:[email protected]";>[email protected]</a>
>>List:    <a target="_blank"
>>href="https://lists.sourceforge.net/lists/listinfo/backuppc-users";>https://lists.sourceforge.net/lists/listinfo/backuppc-users</a>
>>Wiki:    <a target="_blank"
>>href="http://backuppc.wiki.sourceforge.net";>http://backuppc.wiki.sourceforge.net</a>
>>Project: <a target="_blank"
>>href="http://backuppc.sourceforge.net/";>http://backuppc.sourceforge.net/</a>
>>
>   




-------------------------------------------------------------------------
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/

Reply via email to