I was following along on http://www.uwsg.iu.edu/security/rsync.html to setup a user to use with rysync for some files (not mirroing user files like this website is attempting to do, but rather mirror simple data files from a user account to the same user account on another machine... basic stuff, ya know?)... but ran into a problem.

No matter what I try, whenever I attempt to just plainly "ssh destination.domain" (even while being logged in as the user in question), it still continues to ask for the password.

Stuck on the step where you test to see if the key is working... well it aint

Basically, the ssh-keygen process is supposed to make a key (identity.pub) you copy/put on the destination machine (authorized_keys), so that when you ssh from one machine to the destination, it logs you in without asking for a password.

This is VERY critical when setting up something like rsync to run without human intervention of typing in a password. Unfortunately it is not working and am baffled why? I followed those directions... they arnt difficult... its really basically straightforward. Its just the server is deciding not to do what its supposed to based on docs (even the MAN pages for ssh, and ssh-keygen say pretty much the exact same thing this howto page does).

Crazy. How can something so simple, just not work?

Server Source: RH7.3 SSH OpenSSH_3.1p1, SSH protocols 1.5/2.0
Destination: YDL2.1 SSH OpenSSH_2.9.9p2, SSH protocols 1.5/2.0

Both of which understand rsa1 key files, and generated the same type of things and have the same types of programs. So that shouldn't be an issue.

Anyone have any ideas? This is a tricky one... I've tried many things (spent the last 5 hours just trying to get this tiny thing to work OMG!).

well you may well have ssh1 disabled by default. you should really try to use ssh2 authentication (rsa or dsa) indentity.pub only holds an ssh1 key. ssh-keygen seems to change day by day as to how to specify what key type to generate, but try and get a dsa key if possible, putting it in authorized_keys as before.

That worked...

Well... it might have been a combination of that, and futzing with permissions on the .ssh directory on the destination ... but maybe the combination made it work.

Seems to work, but I am a bit dissapointed with the result

See, in order to use it with rsync now, I cant simply connect with -e ssh to theuser@the.domain.com:/path/to/files ... because it tries to look up the ROOT's .ssh keys, even though I am saying to connect with "theuser" instead of "root".

SO, in order to run the rsync command line and make it work (without asking a password), I have to run it from "theuser"... and by god I have no idea how to do this in a script! AYE!

So... it works... but its pretty useless unless I can figure out a way to change to "theuser" when I run the script to do the rsync command... bummer.

Just after my post... I was doing some google searches (seems to be my best friend lately! no popup banners!)... and saw an obscure reference to 'sudo' on some site. So I maned it, and sure enough... BOINK! It works anywhere as anyone now.

sudo -u mruser rsync -azu --delete --ignore-errors --blocking-io -e ssh /path/to/files/* mruser@mr.domain.name:/path/to/files

Works like a champ after the help you gave, the permissions mungling, and well... the help you gave.

Thanks a bunch! I can now cron this puppy, and even tag it onto other processes that run via file checks. Nice.