No, SSH keys are not PGP keys and serve different purpose .
You must have PGP keys in GnuPG keyring.
But - you can convert GPG keys to SSH keys (using gpgkey2ssh) and gpg-agent can take care of SSH keys (using --enable-ssh option). I believe no such tool exists for converting SSH keys to GPG keys and cannot exist.
In so many words, gpg --decrypt wants a file, not an email message. An email message typically consists of multiple MIME parts (your example shows a multipart/mixed with just a single body part, but the concept still holds), which are not files. You need to pass just the encrypted payload, not the MIME container, to gpg, or find a wrapper or option which helps gpg parse the MIME wrapper.
Quick googling turned up a simple Perl MIME wrapper which does this:
In case the link goes bad, reinventing the same wheel again should not be a significant challenge; you basically need to identify the MIME part which contains an encrypted payload, decode it (it's probably base64 encoded, unless it uses gpg's own "ASCII armor"), and pass it to gpg. The existence of an encrypted payload is probably a good trigger, but perhaps the wrapper should simply pass through anything which doesn't contain an encrypted payload, and you would feed everything to the wrapper.
Tangentially, there is nothing which defines $subject in Procmail or in your rules. You can do something like this:
:0
* ^Subject:[ ]\/[^ ].*
{ subject=$MATCH }
... where the whitespace between the square brackets should be a space and a tab.
Best Answer
You do not want a symmetric cipher
If you need to auto-run encryption you don't want to use a symmetric cipher with a passphrase (this is what gpg -ac does). Storing the passphrase in a script or in cron is unacceptable and pointless (seriously, this sounds harsh, but you may as well rot13 it.)
If you're using encryption, it isn't enough to simply "change the permissions" of the script. If it was, you could simple change the permissions on the data you want to hide. Encryption at this level is obviously meant to stop someone who has gained access to your account (most likely maliciously) reading the data once they have access.
In this case, what you want is public key crytography. You generate a private key (which is encrypted again with a symmetric cipher with a password) and a public key. The public key can be distributed anywhere. Anyone can encrypt data that you can read with your private key. Noone should have access to your private key. So for the type of encryption you need, it's perfect. You can store your public key on the server and encrypt all of your data using it. If an attacker has your public key and your encrypted data, he can do nothing.
Your private key should be the bit of the puzzle a potential attacker is always missing. You need to hide this. i.e. encrypting data that you can read is easy. Decrypting it should be hard. With a symmetric cipher, the difficulty of both is the same (if you want to think of it in those terms, it's probably not the greatest analogy.)
GPG makes public crypto relatively painless, but first things first, you need to generate a keypair (this is not done on your server, but on your desktop or somewhere secure you're happy having your private key):
Run through the questions there.
Then you want to export your GPG public key and copy and paste it to your server:
Copy pub.key to your server and then import with:
If you're considering using encryption in the first place, it's obviously because you've got sensitive data. I'd stress again: you need to think seriously about the way you're encrypting this data as it is a whole lot of effort for no gain if you simply use a symmetric cipher where the password can be accessed trivially.