cron jobs and password security

Printable View

April 6th, 2005, 05:01 PM
ew1

cron jobs and password security

Hi,
I code a website that lives on a linux box with Apache. I have access to php and MySQL. I have implemented cron jobs to query an off-site database, store it to a delimited text file, and then upload that info into MySQL. Because this happens in the wee hours of the morning, I am not here to type in a password. So I (temporarily) hard-coded the password in the perl script that the crontab runs. I imagine that this is very insecure and want to figure out how to encrypt this password so that these cron jobs can run without my intervention.

Any suggestions?

Sincere thanks!
:cool:
April 7th, 2005, 07:18 AM
zencoder

Well, I'm not a big code poet myself (don't let the handle confuse you...most assume it means 'zen master of code writing...notice there is no 'master' in my handle or profile...) I can't give you exact snipets. However, I can suggest 'best practice' considerations to use.

You're right, hard coding passwords is ridiculously bad form. Particularly with a script on a web platform. If that script is under the httpd root, and you have a breach (or poorly configured security), that script may be accessed and the PWD revealed.

You'll absolutely want to write the PWD and other tidbits to a .conf file elsewhere. It's not a bad idea to use one of the many many many functions in Perl (or one its myriad of modules) to encrypt/decrypt the PWD in the .conf file as well. crypt() sounds familiar...not sure, go read the manual, it'll give you clear answers.

A less desirable solution is to run the ftp transaction as a LIMITED RIGHTS USER (not root, or I will hunt you down and beat you with Spaf's Practical UNIX & Internet Security...a hefty book, take heed!) using scp, rsync, sftp, etc. and utilize the trusted hosts functions (kinda like .rhosts.) Not a very secure solution, but better than using a user password hardcoded into a live script.
April 7th, 2005, 04:23 PM
ew1

zencoder,
Thanks for the explanation on your handle. It's good to get some history, part of a person's story in these forums. It's more fun this way. Otherwise, it would just be about getting the 'right' answer (whatever that means) to my problem here at work. Important but not everything.

Anyways... thanks very much for your tips! I am jumping right in to a serious study of encryption. I hope I figure this stuff out. I may uncover more questions so you may see more posts from me soon.

Thanks for offering your expertise to those of us on the learning curve.
::biggrink
April 7th, 2005, 05:23 PM
roswell1329

GAAH!! Hardcoded passwords?!! Are you nuts?!! And shame on you zen for not telling our friend ew1 about public-key authentication! :bigsmile:

Run a google search for "passwordless logins ssh". Should bring up a bunch of pages on how to use SSH and public-key authentication to allow this sort of thing. Public-key authentication gives you the ability to run an encrypted session over SSH without typing in a password. Very cool.

Heck...since I'm here, here's the whole process in a nutshell:

1) type ssh-keygen -t rsa. This will kick out the following (or something similar):

Code:

Generating public/private rsa key pair. Enter file in which to save the key (/home/<user>/.ssh/id_rsa):

2) it will then ask you for a "passphrase". to make things simple, you should leave this blank, but this does create some inherent security risks (should your account on this system be compromised, the attacker may also have access to any other system you copy the key to). it's possible to enter a passphrase here, but you'll need to become intimately familiar with how the "ssh-agent" runs so you can bind a script to it when it runs automatically. For now, just leave the passphrase blank.

3) it will ask you to repeat the passphrase...just leave it blank by hitting return again. You'll get the following output:

Code:

Your identification has been saved in /home/<user>/.ssh/id_rsa. Your public key has been saved in /home/<user>/id_rsa.pub. The key fingerprint is: 02:06:76:af:56:de:b4:16:dc:68:90:da:e1:61:f8:8c <user>@<system>

4) If you look in your .ssh directory now, you'll see 2 files called id_rsa and id_rsa.pub. Copy the id_rsa.pub file to the remote system you have to access via the script.

5) Once the file is there, log into the remote system yourself, and run the command:

cat /path/to/id_rsa.pub >> ~/.ssh/authorized_keys

6) If all has gone well, you should be able to log into the remote system without a password now.

If this doesn't make sense, run the google search I gave you above. There are some much better documented processes out there.

There are a few things you can do now with the above groundwork laid. For example, if you have access to other accounts on the remote system, and would like passwordless access to them as well from the original account on the local system, just copy the same id_rsa.pub file over to the remote system into the ~/.ssh/ directory for the other user, and just like in the above directions, append the id_rsa.pub file to the end of that user's authorized_keys file. After that, you could log into the remote system as that user with ssh -l <newuser> <remote system>. No passwords necessary. Always be sure to APPEND. There may be other keys in there, and you don't want to clobber them. If the file doesn't exist, the shell redirects >> will create the file.

Also, remember to keep your private key (id_rsa) well guarded! If you lose that, your entire security model is broken.

Another thing: If the account on the remote system is a disabled account (ie, they have a '*' in the password field of the /etc/passwd file), you'll need to either enable the account by supplying a password for it, or some systems allow you to put a '!!' in the place of a '*' which will allow public-key authentication logons, but not standard password logons.

Finally, remember that someone who breaches your account on the original system could potentially have access to all the other systems you copied your public key to. It would be wise to learn about how the ssh-agent binary can help this, but that's a much more involved process that I don't have room to go into here.
April 7th, 2005, 11:06 PM
ew1

I LOVED your mini-tutorial!! THANKS!
and I understood most of it. AND I googled the passwordless access ssh like you suggested.

I got stuck when I got to the point where you said to place the id_rsa.pub file on to the remote system into the ~/.ssh/ directory for the other user because there really

I checked on the server that I'm hoping to automate the cron jobs on and there is no authorized_keys file or directory. There's one .ssh directory with a known_hosts file but that seems to be host-based authentication rather than identity-based authentication.

Also, the cron job will not need access to a different server but only to the MySQL db on the same server.

I’m not sure if what you said still applies if this is the case.

I am investigating what this article is talking about: http://webmonkey.wired.com/webmonkey...tw=programming

Perhaps using the .htpasswd function. Could I make the $PHP_AUTH_USER contain the username of the server nobody and then code some php so that

If(isset($PHP_AUTH_USER)){
// do other stuff
}

I’m probably way off but my boss wants me to figure out a way to do this and I’m going to keep trying.

Thanks again for your wonderful tips!
April 8th, 2005, 02:31 AM
zencoder

Quote:

Originally posted here by roswell1329
GAAH!! Hardcoded passwords?!! Are you nuts?!! And shame on you zen for not telling our friend ew1 about public-key authentication! :bigsmile:

Run a google search for "passwordless logins ssh". Should bring up a bunch of pages on how to use SSH and public-key authentication to allow this sort of thing. Public-key authentication gives you the ability to run an encrypted session over SSH without typing in a password. Very cool.

Gah, I was giving him small bites...baby steps! You gotta pace people as they learn.

So just step back or your backup tapes might mysteriously disappear! I still have connections there. Don't you have a printer cartridge to replace, or a paper jam to clear, or something?
April 8th, 2005, 04:21 PM
roswell1329

Quote:

Originally posted here by ew1
I checked on the server that I'm hoping to automate the cron jobs on and there is no authorized_keys file or directory. There's one .ssh directory with a known_hosts file but that seems to be host-based authentication rather than identity-based authentication.

If the authorized_keys file isn't there, or if the ~/.ssh directory isn't there, it just means that the user on that system hasn't been prepared to use ssh yet. You can simply create the .ssh directory in their home directory and use touch to create the authorized_keys file. The directory is usually automatically created when you use ssh for the first time.

Quote:

Originally posted here by ew1
Also, the cron job will not need access to a different server but only to the MySQL db on the same server.

I’m not sure if what you said still applies if this is the case.

Oh...um...:bigsmile:...that's diff'ernt. Accessing a remote MySQL database with PHP should only be slightly different than accessing a local MySQL database. It should look something like this:

PHP Code:

$result = @mysql_pconnect("remotehost", "www", "www");

Where "remotehost" is the system you're connecting to from the cron job. If you're wondering how you can make this connection with PHP using cron, you should look at how to use PHP as a shell scripting language: Using PHP As A Shell Scripting Language. Very cool stuff. All the ease of PHP...no need for a web-server. :bigsmile:

Unfortunately, that still leaves the problem of hardcoding the password into the script. I haven't been able to find any way around hardcoding a MySQL password into a PHP script. This is why many people in this situation will create a "web-read-only" account for the MySQL database that is only granted permission to select information from the database. You'll notice above that the username and password I'm using are both "www". That's my web-read-only account, and should anyone get a hold of that account, they'll only be able to extract information -- they cannot modify the database in any way. If the data you are storing is confidential, you can add additional security by only allowing connections with your web-read-only account from the host you're running the cron from. All other hosts and usernames are denied. Then lock the permissions on that file down to read-only by your web server account.

Quote:

Originally posted here by ew1
I am investigating what this article is talking about: http://webmonkey.wired.com/webmonkey...tw=programming

Perhaps using the .htpasswd function. Could I make the $PHP_AUTH_USER contain the username of the server nobody and then code some php so that...

That was a cool article, but I don't really see how that will help you with your cron problem. If you're not there to enter the password when the cron kicks off, won't you still be in the same dilemma?