[BALU] rsync: --password-file doesn't work
daniel.hallmark at gmail.com
Thu Feb 8 09:37:26 CST 2007
I usually tend to agree with all of Mark's comments. However, in the
general case (although not necessarily this specific circumstance) I
would have to take exception with Mark's comments regarding his
preference to go the ssh route.
The ssh public key is contained within a file on the remote filesystem
(the same as an rsync password file on a remote filesystem). At ssh
key-generation you have the option of specifying a passphrase to
protect the private key or you can leave it unsecured (required for
unattended script access). If you secure the private key with a
passphrase, then you would still be prompted for that passphrase at
runtime *unless* the only time you run this rsync script is from an
interactive keyboard session where you are logged in and have already
authenticated yourself to an ssh key-agent.
In order for a script to run attended you'd have to set up the ssh
keys in an unprotected mode (no passphrase protection). This means
that anyone who manages to get access to your public key file can take
and use your ssh key for full remote access to the target machine.
In general, I expect that anyone who would set up an unattended rsync
with a password file would probably be putting that password file on
the same filesystem where their ssh public key would reside. So a
hacker who got access to one of those files would most likely have
access to both of them. Using the rsync in server mode allows you to
lock down (chroot) the rsync remote user account to a specified
directory tree. If someone steals that rsync password file all they
get access to is the share point and not full shell access to the
*ANY* use of a file to store access credentials - whether it is an ssh
key or an rsync password is less secure than an access method which
requires a keyboard interactive authentication. It just so happens
that one common usage with ssh is to set up a key-agent so that you
only have to authenticate once per session, but you are still having
to manually enter a password at least once in order to securely use a
set of ssh keys. For any unattended, scheduled, automated usage that
option isn't available and your only choice is to use a less secure
key file with no passphrase confirmation.
If you've made that choice to use a less secure password file then I
think it is far less of a security vulnerability to be using a
chrooted rsync server "module" vs. using an unsecured ssh key that
gives the user direct filesystem access. Even if the ssh account is
restricted to the same directory tree as the rsync server, there are
plenty of vulnerabilities that are only exploitable to users who have
a local system account. SSH may secure and encrypt the traffic while
it is in transit, but granting a local account to a remote user or
system which only needs to be able to sync a set of files poses its
own increased security risks.
In this particular situation where the two machines are both owned by
the same individual and it is the machine-owner who is setting up the
connections this probably doesn't matter. But from a general security
viewpoint there is a huge difference. It is easy to be lulled into
complacency thinking "I'm using ssh public/private keys so I'm secure"
when in fact the use of SSH can decrease your system's security
depending on the details of how it is being used. This is especially
true of ssh keys where it is easy to not think of them as being as
vulnerable as a password file, but that's basically what they are.
Bottom line is this: if you don't have to key in a password/passphrase
for remote system access then neither does your hypothetical attacker
who has gained access to your password files, regardless of whether
those are plain text passwords or an ssh public key.
On 2/8/07, Mark Dillavou <mlists at line72.net> wrote:
> On Wed, 2007-02-07 at 22:16 +0000, Eric Volker wrote:
> > I'm trying to automate rsync on a Mac OS X machine to sync some files
> > from a Linux file server. From a shell, I can type
> > rsync <ip address>:/path/to/remote/folder /path/to/local/folder
> > rsync --password-file=/Users/<username>/rsync-pass <ip address>:/path/
> > to/remote/folder /path/to/local/folder
> > I *still* get prompted for the freaking password. Per man rsync, the
> > only thing in the rsync-pass folder is the password as a single line.
> > What could I possibly be missing?
> I'm not sure about MacOSX, but on most linux distributions, rsync is
> setup to use ssh by default. If you setup ssh keys, then you shouldn't
> need a password and would be much more secure than putting a password in
> a file!
> Mark Dillavou <mlists at line72.net>
> Members mailing list
> Members at lists.bham-lug.org
More information about the Members