SSH has a variety of configuration options that let you login through the use of generated keys. Consult the man pages on ssh and ssh-keygen. What you do is generate an RSA or DSA key for your system and put the identity.pub(public version of the key) into the .ssh/authorized_keys file on the systems that you want to login to remotely without a password and set your .ssh/config file to accept a key instead of a password.

Good book on the subject: SSH, the Secure Shell

Web Reference for SourceForge's SSH system: Guide To Generating and Posting SSH Keys

Do this with CAUTION. It leaves cleartext off of your system of course, but if someone were to appropriate the identity files it could leave your target systems vulnerable.

One thing you could do is to replace the private identity key in your home system with a symlink to /mnt/floppy or /mnt/cdrom and keep the files there and only insert them when you get to work. I'm not sure that will work though, I've never done it myself, having just thought of it now, but I'm dying to try it. :)

My own .ssh/config files at home are setup in this way for a couple of sytems, and I'll see if I can't put a more detailed write up here later.

update:

This is a very handy technique for CVS systems that are accessed through ssh, spares you alot of entering/re-entering passwords. Setting this up and using PCL-CVS under emacs actually makes CVS almost fun to use.

Confession:

I tried to put the <blink> tag around 'vulnerable'.

ptkdb covers the SSH side of things well.

As for any database passwords, I'd be inclined to simply store passwords in a file that is readable only by the user running the script.
Parse, do or otherwise include that file as required.

If that requires a new user and/or group just for running automated commands, so be it.

Cheers,

BazB

Just a tip when storing passwords in a daemon. On most platforms putting it in the environment isn't any safer than putting it in a file on disk (if you are on a linux box, try 'cat /proc/$$/environ').

---

We're not surrounded, we're in a target-rich environment!

Well that's unfortunate. I guess you're better off avoiding environment variables for that sort of thing then, although Solaris and Tru64 don't supply that info in /proc. I don't know about other OS's.

this is my favorite SSH key usage introduction. worth the free registration (and no spam yet). it's from the IBM developerWorks pages. (and writen by the Gentoo guy)

there are three parts covering setting up your keys and using key-agent.

eventually you pretty much have to trust the filesystem, or you require human-being to type in password and trust the human...

i use Kerberos for my database authn and authz, but still anybody who can manage to read the /etc/krb5cc_0 cache could gain access... but it does keep simple plaintext passwords out of the files.