I have a web application that needs to store server login information. I\'m using a 2048bit PGP public key to encrypt inserted passwords (see the insertServerDef
I believe there cannot be an answer unless you describe the threat scenario you want to avoid.
Let me rephrase your situation: You need to have a plain text password for accessing remote systems via SSH. The goal is to protect this password, but have it available when needed.
There really is no way to both protect the password and be able to use in its plain text form. There always has to be a way to decrypt it, and this needs both the mechanism and the secret key.
You can try to iterate a bit on this, like protecting this secret again, but in the end you will need to store the final plain text password into a variable and pass it into the authentication scheme.
What is the threat scenario you want to avoid?
You see, there is always a way to do harm. Most harm can be done if you do not check regularly against irregular activity on your systems. Like monitor all log files for attacks. Probably send the logs to another syslog server so that an attacker cannot change them if they are on the same server. If you do everything you can to prevent attackers from getting onto your system, then the need to securely store the secret passphrase diminishes.
It might be an idea to store the passphrase into RAM, like on a RAM disk or inside a dedicated memory. This way, if the server gets stolen, it most likely will be unpowered and forget the passphrase. But you then must have a way to restore the passphrase from remote to continue operation after a reboot. But again: if you cannot detect that an attacker is on your system, it's meaningless whether the passphrase is inside RAM or on magnetic disk - it can be read.
I wonder why you deal with passwords in the first place. If I use SSH, I always try to use SSH keys for cryptographic authentication. This is more secure on the target server, because one account (like root) can have multiple SSH keys, and if the one stored on your server is compromised, it can be deleted without interfering with the other keys. Yes, these SSH keys can be secured with a password, too.