LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices

Reply
 
Search this Thread
Old 03-13-2008, 09:42 AM   #1
disorderly
Member
 
Registered: Sep 2003
Location: NJ
Distribution: RHEL5
Posts: 154

Rep: Reputation: 30
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
 
Old 03-13-2008, 10:45 AM   #2
lord-fu
Member
 
Registered: Apr 2005
Location: Ohio
Distribution: Slackware && freeBSD
Posts: 676

Rep: Reputation: 30
Why is using keys not a good idea if I may ask?
 
Old 03-13-2008, 11:22 AM   #3
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by lord-fu View Post
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.
 
Old 03-13-2008, 11:33 AM   #4
mmaki
Member
 
Registered: Nov 2005
Location: Thousand Oaks, CA
Distribution: Debian
Posts: 33

Rep: Reputation: 15
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
 
Old 03-13-2008, 11:38 AM   #5
lord-fu
Member
 
Registered: Apr 2005
Location: Ohio
Distribution: Slackware && freeBSD
Posts: 676

Rep: Reputation: 30
Quote:
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 ;}

Last edited by lord-fu; 03-13-2008 at 11:54 AM. Reason: speling :p
 
Old 03-13-2008, 12:27 PM   #6
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by lord-fu View Post
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.
 
Old 03-13-2008, 12:40 PM   #7
prn
Member
 
Registered: Apr 2005
Location: Muncie, IN, USA
Posts: 58

Rep: Reputation: 16
Quote:
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.

Quote:
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:

Quote:
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
Quote:
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
 
Old 03-13-2008, 12:59 PM   #8
lord-fu
Member
 
Registered: Apr 2005
Location: Ohio
Distribution: Slackware && freeBSD
Posts: 676

Rep: Reputation: 30
Quote:
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.
Quote:
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.
Quote:
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 :]

Last edited by lord-fu; 03-13-2008 at 01:10 PM.
 
Old 03-13-2008, 01:12 PM   #9
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
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.
 
Old 03-13-2008, 01:17 PM   #10
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by lord-fu View Post
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.
 
Old 03-13-2008, 01:21 PM   #11
prn
Member
 
Registered: Apr 2005
Location: Muncie, IN, USA
Posts: 58

Rep: Reputation: 16
Quote:
Originally Posted by lord-fu View Post
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
 
Old 03-13-2008, 01:31 PM   #12
lord-fu
Member
 
Registered: Apr 2005
Location: Ohio
Distribution: Slackware && freeBSD
Posts: 676

Rep: Reputation: 30
Quote:
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.

Quote:
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

Last edited by lord-fu; 03-13-2008 at 01:33 PM.
 
Old 03-13-2008, 01:33 PM   #13
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by prn View Post
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!
 
Old 03-13-2008, 01:55 PM   #14
prn
Member
 
Registered: Apr 2005
Location: Muncie, IN, USA
Posts: 58

Rep: Reputation: 16
Quote:
Originally Posted by unixfool View Post
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.


Quote:
Originally Posted by unixfool View Post
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
 
Old 03-13-2008, 09:51 PM   #15
Lantzvillian
Member
 
Registered: Oct 2007
Location: BC, Canada
Distribution: Fedora, Debian
Posts: 210

Rep: Reputation: 41
Right on, was just looking at that today for Rsync
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can't get a cron job to run derzok Linux - General 10 12-16-2007 04:00 AM
Open SSH authentication using public keys Xiiph Linux - Software 8 01-05-2007 08:58 AM
Cannot execute rsync as a cron job jdaniels73 Linux - Software 2 09-03-2006 05:03 AM
SSH public/private key authentication with GnuPG keys? thinksincode Linux - Security 1 02-25-2005 02:33 PM
how to run this cron job ashley75 Linux - General 5 05-24-2004 11:20 AM


All times are GMT -5. The time now is 10:27 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration