Sorry, not an answer but too long for a comment, which I think is in place.
Important thing is what you are trying to achieve by storing the key in the database encrypted.
An attacker that is able to access the temporary private key file will be able to read the ssh client process' memory as well (and hence get to the key data anyway), because both of these data must have basically the same access permissions - trying to hide the file doesn't seem to make it any more secure.
If you are using different users for db, webapp and ssh connection, by storing the key in the db, decrypting it in the webapp and feeding it to ssh, you are just opening potential attack vectors by spreading the key all over the process. If you are using just one user for all of these (db, app, ssh), you are gaining nothing except for code complexity.
The only advantage seems to be an easier transfer of the system to a different host and potential gain in case the db data gets stolen but the webapp (which AFAIU contains the decryption algorithm and password) not. But is that likely?
That said, if you want to protect the key, you can also use the ssh's internal encryption of the keys and load them into an ssh-agent when starting your service (remember to remove it when it stops!). But again remember that the ssh-agent keeps the keys in memory unencrypted, so it can potentially be read. Yet again: is this the problem you are trying to solve?
If you just need to protect communication between two machines,
stunnel might be of better service than ssh.
And finally for the question: as far as OpenSSH (portable) is concerned, writing a simple patch that would allow
ssh to read the key from another process as
sshd does with the
AuthorizedKeysCommand option should be reasonably straightforward.