how can i run rsync as a cron job using public keys authentication

hello

i figured out how to do passwordless logins for rsync between systems using public keys, but it requires either:
1) a user to log in an start ssh-agent and enter a password for the keys
2) use passwordless keys (not good idea)

is there anyway to start ssh-agent + ssh-add as a system process without tying them to a user (root) login without using passwordless keys?

the purpose would be to keep my cron jobs running rsync going after an unexpected reboot.

samba uses the /etc/krb5.keytab to keep itselt authenticated to a domain in between reboot - anything similar for ssh?

thanks!
disorderly

Why is using keys not a good idea if I may ask?

Originally Posted by lord-fu Why is using keys not a good idea if I may ask?

He said passwordless keys...huge difference there. I agree with him...you're defeating the purpose of keybased authentication if you're going to utilize passwordless keys.

Just my opinion.

AFAIK passwordless logins using ssh private/public keys is considered on of the most secure methods of communication between systems. Some other steps you can take to increase your security are:

1. Disable root logins
2. Change the listening port to a high unprivileged port (i.e. 22022)
3. Disable password logins with PasswordAuthentication no

An excellent article can be found at http://www.howtoforge.com/ssh-best-practices

Quote: Originally Posted by lord-fu http://linuxquestions.cachefly.net/i...s/viewpost.gif Why is using keys not a good idea if I may ask? He said passwordless keys...huge difference there. I agree with him...you're defeating the purpose of keybased authentication if you're going to utilize passwordless keys.

In my opinion you are defeating the purpose of using keys at all if you are using a password; a key is meant to verify a persons identity and if I have my private key secure I am good to go.

If I were to try and run a job via cron that required a password, I would A: Have to sit in front and type in password or B: Read in a plain text password from a file and both are bad choices, thus keys. Of course I reserve the right to be wrong ;}

Originally Posted by lord-fu In my opinion you are defeating the purpose of using keys at all if you are using a password; a key is meant to verify a persons identity and if I have my private key secure I am good to go. If I were to try and run a job via cron that required a password, I would A: Have to sit in front and type in password or B: Read in a plain text password from a file and both are bad choices, thus keys. Of course I reserve the right to be wrong ;}

I believe the password is for the key itself, not for actual authentication. If someone gets ahold of the key and it has no passphrase, you're in trouble...if someone gets ahold of the key and it has a passphrase, they won't be able to do a thing with it. I believe a better but similar explanation is found in O'Reilly's 'SSH, The Secure Shell: The Definitive Guide.'

BTW. ssh-agent should be able to help with automated logins.

Originally Posted by lord-fu In my opinion you are defeating the purpose of using keys at all if you are using a password, a key is meant to verify a persons identity and if I have my private key secure I am good to go.

The OP is NOT talking about a case where he is even present. He wants to run rsync through an ssh tunnel to another computer when he is not there to authenticate.

A typical use for this is nightly backup. Another is to synchronize data between two or more computers (or even users on the same box).

But the point is that he is doing it through crontab. So he is NOT THERE.

Originally Posted by mmaki An excellent article can be found at http://www.howtoforge.com/ssh-best-practices

And these are good practices. No doubt about it. The problem, as the author notes is:

Public key authentication is no silver bullet - similarly, people generate passphrase-less keys or leave ssh-agents running when they shouldn't - but, in my opinion, it's a much better bet.

The reason people do those things (passwordless keys or ssh-agents) is precisely so that they can rsync when they are not present.

That said, AFAIK disorderly (the OP) is right. You cannot initiate ssh sessions or tunnels without

Originally Posted by disorderly either: 1) a user to log in an start ssh-agent and enter a password for the keys 2) use passwordless keys

The best I have been able to think of (at least for security purposes, and I would also welcome a better idea, since I have been doing (2) for some time now) assumes that you have root access to (or at least a very cooperative sysadmin on) both boxes.

You create a user with very limited rights on both machines. Depending on how restrictive you want it to be, it could be a user who is chroot'ed and sandboxed to the point where it cannot do any more than read or write files in its own home directory and run rsync. Suppose you want to tie it down as much as possible, but want to move files owned by root. The routine could work like this:

Assume "captiveuser" has accounts on both box A and box B but can't do much of anything with those accounts, i.e. no privs.

1. root's crontab on box A creates a tar file, and gpg-signs it with a passwordless key that is used for nothing else, then move it to /home/captiveuser/ and sets some sort of flag
2. captiveuser's crontab, using a passwordless ssh key, rsync's (or scp's) the signed tar file to box B
3. root's crontab on box B verifies the signature of the tar file and then untars the contents to where they ought to go.

Frankly, this is a lousy way to do things like backup or other sync because rsync is supposed to move only what needs to be moved and not what is unchanged. In fact, rsync can transfer only the changes in files so that it does not even need to move whole files just to sync up modifications. Doing it by means of signed tar files completely loses that advantage of rsync.

If you don't need that level of security, you could skip the tar and gpg steps and just use rsync in steps (1) and (3) so that the only the changed data is rsync'ed to captiveuser's directory on A and then to B. This might be less suitable if you are concerned with the possibility that someone might tamper with the data in captiveuser's directory. I suspect that it might be possible to come up with some variations on the theme, but the variations all depend on your level of comfort and the threat model that you are concerned with. Obviously, root access to either machine is still root access and once that is compromised, security is gone. So everything depends on that.

If nobody else has login rights to a machine, then you may or may not care to do something as elaborate as this.

But the bottom line, AFAICT, is that you have to have some kind of passphraseless keys to do this unattended, even if the passwordless keys do not belong to root.

Paul

The OP is NOT talking about a case where he is even present. He wants to run rsync through an ssh tunnel to another computer when he is not there to authenticate.

Obvious, thats why I said using a password would defeat the purpose.

If I were to try and run a job via cron that required a password, I would A: Have to sit in front and type in password or B: Read in a plain text password from a file and both are bad choices, thus keys

And thats why I originally asked.

Why is using keys not a good idea if I may ask?

With this question I was hoping for a response of,"mandated by corporate or hairy bearded sysadmin", or "I am highly paranoid and want everything short of a flamethrower shooting out the back"

I too use rsync and key pairs for all sorts of things. There is no doubt in my mind that ssh-agent adds an extra defense to a compromised account, but as you noted very well that if an account or design is properly set, then really it is a moot point. I guess it all comes down to personal preference or corporate policy in my case :]

SSH, The Secure Shell: The Definitive Guide, p. 234:

Also, if you think you have a good reason just to type RETURN and give your key no passphrase, think again. That is essentially equivalent to putting your password in a file in your home directory named MY-PASSWORD.PLEASE-STEAL-ME. If you don't want to have to type a passphrase, the right thing to do is to use ssh-agent, hostbased authentication, or Kerberos. There are very limited circumstances having to do with unattended usage (e.g., cron jobs) where a plaintext, passphrase-less client key might be acceptable.

Chapter 11, section 11.1.2 (Public-Key Authentication) also explains the thoughts behind key authentication.

Note the last sentence of the excerpt. If you don't use a passphrase on your key, it is therefore plaintext. Having a passphrase means that the key itself is encrypted and can't be viewed by ordinary means.

If the OP follows the book's authors' line of thought on the above, he should be able to use ssh-agent initially to load any key being used. Due to the nature of servers, he should very rarely have to manually load the keys. Or, the OP can use hostbased authentication or Kerberos, as explained above.

Originally Posted by lord-fu Obvious, thats why I said using a password would defeat the purpose. And thats why I originally asked. With this question I was hoping for a response of,"mandated by corporate or hairy bearded sysadmin", or "I am highly paranoid and want everything short of a flamethrower shooting out the back" I too use rsync and key pairs for all sorts of things. There is no doubt in my mind that ssh-agent adds an extra defense to a compromised account, but as you noted very well that if an account or design is properly set, then really it is a moot point. I guess it all comes down to personal preference or corporate policy in my case :]

I believe this is considered a best practice in the security industry. If you don't encrypt your private key, anyone can use it if they find it. They can do anything you would do with your SSH tunnel with that key if it didn't have a passphrase. It doesn't quite make sense to me, especially when there are other technologies that can be leveraged when wanting to run a cron securely.

Originally Posted by lord-fu I too use rsync and key pairs for all sorts of things. There is no doubt in my mind that ssh-agent adds an extra defense to a compromised account, but as you noted very well that if an account or design is properly set, then really it is a moot point. I guess it all comes down to personal preference or corporate policy in my case :]

Corporate policy, in my case, is ... well, I'd better not say.

Of course, ssh-agent can add extra defense to a compromised account. The problem is that you cannot run ssh-agent without either (a) having a user present to type in the password (passphrase), (b) having a plaintext passphrase in a script, or (c) having no passphrase for the key.

The OP was not talking about the login password for box B. He was talking about the password (passphrase) for the key. IOW, you still have the same problem regardless of whether you are using a key or login password for the other box. That's the real question and I don't see that anyone has answered it. I certainly have not. I can come up with a procedure that can be used to prevent a compromise to the root (or other user) account on box A from compromising root (or corresponding user) on box B. That is, it is possible to limit the damage that compromising box A can do to box B. However, it is definitely clunky.

However, if you want the transfer to take place without human intervention, you still have to have at least some key that does not have a password (or has a plaintext password in a script).

Paul

However, if you want the transfer to take place without human intervention,

What unixfool is saying though is that ssh-agent can do this. I do not know, never used it never had to.

I believe this is considered a best practice in the security industry.

I'm sure it is, very logical.

I'm bowing out of this discussion because in my case I do not need to add this extra layer so I am not familiar with it.

Best of luck to OP

Originally Posted by prn That's the real question and I don't see that anyone has answered it. I certainly have not. Paul

Answers are here.

EDIT - whoa...did i just create an endless loop? LOL!

Originally Posted by unixfool Answers are here. EDIT - whoa...did i just create an endless loop? LOL!

Sorry, I missed this while I was thinking about what I wanted to say in my last response.

Originally Posted by unixfool Due to the nature of servers, he should very rarely have to manually load the keys. Or, the OP can use hostbased authentication or Kerberos, as explained above.

As the OP said, he is trying to do something that can survive a reboot. That is, "rarely having to manually load the keys" does not really meet his needs.

OTOH, hostbased authentication looks promising. It seems to be a relatively recent innovation that I had missed along the way. I will definitely look into that.

Thanks,
Paul

Right on, was just looking at that today for Rsync