Mailinglist Archive: opensuse (1904 mails)
|< Previous||Next >|
Re: [opensuse] rsync with password?
- From: "Brian K. White" <brian@xxxxxxxxx>
- Date: Thu, 05 Mar 2009 22:21:29 -0500
- Message-id: <49B096B9.4020705@xxxxxxxxx>
Ken Schneider - openSUSE wrote:
Greg Freemyer pecked at the keyboard and wrote:
On Thu, Mar 5, 2009 at 5:55 PM, Brian K. White <brian@xxxxxxxxx> wrote:
----- Original Message -----You are a fount of little known knowledge!!
From: "Greg Freemyer" <greg.freemyer@xxxxxxxxx>
To: "SUSE Linux" <opensuse@xxxxxxxxxxxx>
Sent: Thursday, March 05, 2009 5:29 PM
Subject: [opensuse] rsync with password?
All,Since the remote path only uses one colon, that means you are using either ssh
I'm trying to connect to a remote rsync server. ie. It is running
rssh as the shell and rsync is one of the few allowed programs to run.
From my local machine I can invoke rsync and it connects and rsync
asks me for a password. I provide it an all proceeds fine.
I need this to work from a script. So I'm trying to use the
RSYNC_PASSWORD environment variable to pass in the password but it is
My simple test script is:
echo RP = $RSYNC_PASSWORD
rsync -avh --delete --stats --max-size=100M --links --timeout=600
Am I missing something? the echo is working fine.
FYI: by chance the password I'm trying starts with a shell special
char, but I can't see why that would be an issue since the echo works.
or rsh as the communication layer, not rsync itself (aka native rsync).
RSYNC_PASSWORD only applies to native rsync.
To authenticate non-interactively, you need to do so using whatever methods are
available with the communication layer being used.
Since the above command is not using rsync natively (there is only one colon),
And since the above command does not explicitly specify the communication means (there is no
"-e foo" command line argument), then the above command is communicating by whatever is
the compile-time default for "-e". These days almost everywhere, and definitely for all
opensuse packages, this is ssh.
So, you need to set up ssh keys for user b291007.
Similarly, the user specification above: "b291007"
needs to be a real user in the OS on the remote machine, not an "rsync user" in
/etc/rsyncd.secrets. It is not necessary for there to be a user b291007 on the local
Similarly, the remote path specification above: "mach1/"
means a directory named "mach1" in user b291007's home directory.
NOT an rsync module defined in /etc/rsyncd.conf
You are simply logging in via ssh as user b291007 to host backup.abc.com, just
like if you did it manually to get a login prompt and then an interactive shell
or if you used sftp.
Brian K. White brian@xxxxxxxxx http://profile.to/KEYofR
Unfortunately I am paying for a remote backup server that gives me
very limited access. I'm just setting things up, so I'm not sure how
this will work out.
Getting a ssh connection via a key is unlikely to happen, but I should
be able to get them to run rsync as a daemon.
Why don't you use expect for this as that is what it was designed for.
Good god no that's like saying why use a shell script when you could just make an array of solenoids to press the keyboard keys by reading a player piano roll.
Expect was designed for cases where no other or no better way exists.
Expect was designed to automate things which were not originally designed to be automated, and it should really only be used as a last resort when that is exactly the case, when you need to automate something that has no facility already for doing so.
As a system, it's never very robust, merely, .. lucky. As long as the program you are interacting with always behaves exactly the same way (such as the dialup login prompt of a remote system originally), and as long as your expect script has enough complexity to handle any unexpected output (or lack of), then things will work ok.
But ultimately, no matter what, no mater how good expect itself is or how well you wrote your expect script (which can be quite non-trivial and subtle!) you still have a system where 1/2 of the system was not designed to be automated.
ssh on the other hand was designed to be automated from the get go and has it's own robust, and _simpler_ means built-in.
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
|< Previous||Next >|