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.

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......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.

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.

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?