Or Let Me Google That For You

Let me very-strongly echo the sentiment ... that under n-o circumstances should you ever have a password in a script.   That you should use o-n-l-y digital certificates (“password-free”) and that, furthermore, you should exclude passwords as an available means of authentication.   (Perversely, ssh will accept the least-secure option that is made available to it, so it must be told to exclude passwords as an option.)

Even though a password is not required for a holder of the certificate to make the connection, the connection (if secured by a uniquely-issued certificate) is much, much stronger.   You can’t “fake” not having one of the right keys, and the script does not have to, itself, “present” the key that is to be used.

Finally, in most large organizations, ssh certificates are or can be controlled using LDAP (OpenDirectory), along with everything else, thus allowing for central management of keys (on both sides) across all servers.

“Grabbing a live password from a script or job-file” is one of the most common exploits that there is.

You're partly right, but...

How is it that the script's source is legible? If the permissions are managed properly then someone has to authenticate as the application's user account to read the thing. If one can authenticate as the user, why can't they bind to LDAP as that user, or read the disk-based private key if not using LDAP to store them? You could say you'd require credentials other than being logged in as the user to get the keys from LDAP, but then how are you storing those other credentials for the LDAP connection in any way that's different from how you'd store the SSH passwords OP is trying to hide? The big advantage to certificates is the information complexity compared to passwords, not that they are stored differently. One could shuffle passwords off into LDAP, too.

Clearly the solution is to ask for the password on launch of the script and have it entered. However, anyone who could attach a debugger to it could still look at its memory and find the strings it has stored. This solution is a partial solution, then, but still better than just shuffling stored credentials from one place to another.

At what point does the security actually improve from storing the credentials differently? Rather than playing ball-and-cups with the credentials, wouldn't it be better not to store them on an account one is expecting to be breached?