The question you need to ask yourself is this: "If some wiley hax0r where to gain control of the web server, how difficult would it be for them to get my database password?"

If they see before them a script that uses ssh, can they then use that script to get the password? If so, you haven't gained yourself much.

Now if this is all done from a middle tier that the wiley hax0r can't get to, that's another matter.

Whether what you describe is a "middle-tier process" I don't know. Perhaps.

Update: What this scheme seems to protect against is losing the password to a sniffer. That works only if you're then using some secure, database-dependent login mechanism, or are using ssh-tunneling to talk to the database.

Ah I see.

My script (an LWP Perl script) that calls the ssh to get a password from the DB,
does not reside on the web server and is not used by a web server in anyway.

But this script does need to use a password to connect to a https webpages that requires a user/password.
The machine the script resides on (M1) is seperated from the DB server with a firewall (FW1) and
seperated from the "outside world" with another firewall (FW2).

I think this set up is pretty secure. Here's where I expose my ignorance of
firewalls. FW1 only allows ssh and scp from M1 and FW2 only allows http and https to
pass through.

Does that make any sense?

Does that make any sense?

Yup, though I'm unclear on where the web server fits into the picture. You say that your script "does not reside on the web server," but then say that FW2 only allows http and https to pass through. Does that mean that the web server is on M1, or on separate box?

With the caveat that I'm not an expert, this sounds like a pretty solid scheme, as long as you're keeping up with vendor patches for the web server (and firewall vendor patches for the firewall).