Re: [opensuse] rsync with password?



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

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
not working.

My simple test script is:

==

#!/bin/sh
RSYNC_PASSWORD=<my_password>
export RSYNC_PASSWORD

echo RP = $RSYNC_PASSWORD

rsync -avh --delete --stats --max-size=100M --links --timeout=600
/$BACKUP_PATH/config-enc-raw /$BACKUP_PATH/srv-enc-raw
b291007@xxxxxxxxxxxxxx:mach1/
==

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.
Since the remote path only uses one colon, that means you are using either ssh 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 (client) machine.

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
You are a fount of little known knowledge!!

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.

Thanks
Greg

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.

--
bkw
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

Relevant Pages

  • Re: remote copy file
    ... system on our server since it contains data. ... It would be nice if it would work with rsync. ... As I understand it, you need the embedded device to initiate the ransfer, not the remote PC, and you need authentication but without needing to specify a password. ...
    (alt.os.linux.suse)
  • Re: rsync -
    ... The name "rsync" seems to imply that it will make them identical. ... some changes on both machines, but to different files, then rsync is ... "Local to Remote, Delete Remote" \ ... echo "Running rsync for real..."; ...
    (Fedora)
  • Re: [opensuse] backups via rsync leaving old junk in the backup?
    ... I just noticed that the main directory is 247GB, but the remote copy is 354GB. ... I assume rsync can cause the extra files on the remote to be deleted? ... For backup purpuses, --numeric-ids is also useful, because it makes sure ... so it is redundant in your command line. ...
    (SuSE)
  • Re: rsync using sudo.
    ... Both rsync ... users are in /etc/sudoers and permitted to run the command as root ... the local files get permission denied on root owned files ... still get a prompt for a password for the remote machine. ...
    (Fedora)
  • Re: [opensuse] backups via rsync leaving old junk in the backup?
    ... I just noticed that the main directory is 247GB, but the remote copy is 354GB. ... I assume rsync can cause the extra files on the remote to be deleted? ... Litigation Triage Solutions Specialist ... The Intersection of Evidence & Technology ...
    (SuSE)