Jim -

I have read the man pages, and with my lack of experience, they are not that clear. Do you have another reference to suggest?

Todd

Jim Perrin wrote:

On 12/10/05, Todd Cary todd@aristesoftware.com wrote:

...

To synchronize my server with the "standby" server, I run the following:

rsync -a -e ssh /home/ 192.168.0.22:/home/

As expected, I am asked for a password from the destination computer. Is there a way to avoid that so I can make a crontab to run the rsync nightly?

Todd

Set up ssh keys.

-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Todd Cary wrote:

I have read the man pages, and with my lack of experience, they are not that clear. Do you have another reference to suggest?

Here is a link on setting up automatic rsync with ssh:

http://www.tux.org/~tbr/rsync/rsynchowto.html

I have not used that setup. If you want a few more examples googling for 'rsync ssh' will get you several to help you with your setup.

/jft

On Sat, 2005-12-10 at 10:13 -0800, Todd Cary wrote:

Jim - I have read the man pages, and with my lack of experience, they are not that clear. Do you have another reference to suggest?

Yeah, public key authentication can seem to use a number of concepts and terms that seem daunting at first. But after just a little practice, they become second nature.

In a nutshell (uber-simplified): 1) You generate a key pair on the client -- a public and private 2) You copy the public key to the server

The next time you login to the server, the server "challenges" your client using the public key, of which, only the client has the private key to decrypt the challenge and respond correctly (again, mega oversimplification here).

You do #1 on the client with: ssh-keygen -t dsa (enter twice for no passphrase)

You do #2 with something like: scp ~/.ssh/id_dsa.pub user@server:.ssh/authorized_keys

[ NOTE: When you run scp that time, you _will_ be prompted for your password. That's the last time you should ever be though. ]

Now that should be it. You should be able to ssh without being prompted for a password. If you are still prompted, check the /var/log/messages files on both the client and server for any errors/issues.

I can get more geeky if you have follow-up questions.

On Sat, 2005-12-10 at 20:08 -0500, Jim Perrin wrote:

Only one thing to add to this. If the .ssh directory on the remote machine doesn't exist, ssh from there to somewhere else, or create it youself,

Which would result in an error when the "scp" (#2) is attempted, yes.

but keep in mind the permissions. If your .ssh directory is anything other than 600 (I think... pulling that number from deep within my arse) it'll fail, and you'll be prompted for a password and will wonder what went wrong.

Which would result in an error added to /var/log/messages, which I mentioned to check as well.

<non-technical response=ON>

So why didn't I mention the full details?

I've been chastised in the past for giving long, drawn-out answers instead of shorter, more "cookbook" answers (including from yourself if I am not mistaken ;-) -- especially when treating the original poster like a "noob" in the eyes of some (e.g., the non-existance of the remote .ssh directory, which a user who has used scp would probably know). So my post was trying to keep it that way.

No, I wasn't as short as somme others with just telling him to, essentially, RTFM. I mentioned that errors might result, and I could follow up on any the user received if the "cookbook" didn't work. There are far more issues he can run into, by far.

FYI, there's nothing more enjoyable for myself than my talking about public key encryption (I won't mention any specifics, because some would view that as flaunting my resume). But I restrained myself here. I hope you note this for the future. ;->

</non-technical>

On Sat, 2005-12-10 at 22:13 -0500, Jim Perrin wrote:

...

I've been chastised in the past for giving long, drawn-out answers instead of shorter, more "cookbook" answers (including from yourself if I am not mistaken ;-) -- especially when treating the original poster like a "noob" in the eyes of some (e.g., the non-existance of the remote .ssh directory, which a user who has used scp would probably know). So my post was trying to keep it that way.

Mostly accurate. I criticized you for offering theory to someone wanting practice. My addition here still falls within the boundaries of practice. Also, I've NEVER criticized you for the verbosity of your responses. I've criticized you and SEVERAL others for the QUANTITY of responses to a thread, and for refusing to let a thread die. You're not the worst offender here for that, although you're the most infamous for it. War & peace is a shorter read than some of the recent threads on the list (general statement of fact. not directed at you. don't get worked up.)

Side note -

<flame suit on> Didn't you request to be removed from posting to the list to avoid this sort of hostility? How's that working out for ya? :-P

</flame suit off>

---- personally, I like having him post to the list. Most of us blur the distinction between theory and practice.

There are some who bait him since he doesn't seem to be capable of ignoring a taunt. It's sort of obvious who those people are (not referring to you Jim).

Craig

On Sat, 2005-12-10 at 22:13 -0500, Jim Perrin wrote:

You're not the worst offender here for that, although you're the most infamous for it.

The only way to win is not to play, I know. Appreciate the commentary, sorry I cop'd a bit of 'tude. You just basically posted what I wanted to say, but I figured I better not start (or I'd _really_ get into a lot of stuff).

Bryan -

I wish there was a "Simplified Linux Admin" book written with your approach! It worked as advertised, and when I go to the man pages for more detail, I have a beginning place to start...a place that works. This is a writing/learning style that I call "spiral learning": you start with the fundamentals and expand your knowledge from that point as needed.

Many thanks! Now I will create the crontab.

Todd

Bryan J. Smith wrote:

On Sat, 2005-12-10 at 10:13 -0800, Todd Cary wrote:

...

Jim - I have read the man pages, and with my lack of experience, they are not that clear. Do you have another reference to suggest?

Yeah, public key authentication can seem to use a number of concepts and terms that seem daunting at first. But after just a little practice, they become second nature.

In a nutshell (uber-simplified):

1. You generate a key pair on the client -- a public and private
2. You copy the public key to the server

The next time you login to the server, the server "challenges" your client using the public key, of which, only the client has the private key to decrypt the challenge and respond correctly (again, mega oversimplification here).

You do #1 on the client with: ssh-keygen -t dsa (enter twice for no passphrase)

You do #2 with something like: scp ~/.ssh/id_dsa.pub user@server:.ssh/authorized_keys

[ NOTE: When you run scp that time, you _will_ be prompted for your password. That's the last time you should ever be though. ]

Now that should be it. You should be able to ssh without being prompted for a password. If you are still prompted, check the /var/log/messages files on both the client and server for any errors/issues.

I can get more geeky if you have follow-up questions.