I work at a company where I do backups of a database. They are asking that the backup files be encrypted prior to being placed on tape for extra security.

At first, I tried using the symmetric encryption, where you use the "-c" and "-d" options to encrypt/decrypt with a passphrase.
That didn't fly with the auditors since the passphrase is included in the script.

Next, I tried to create a public/private key pair using a bogus email address for the database itself. I stored these in the the account which manages the database, so that any DBA's could access the keys to encrypt/decrypt the files.

When I try to encrypt a file, using the following command style, I get a GPG file successfully:

gpg -e --recipient bogus@company.com --output file.gpg file

However, when I try to decrypt, I get an error:

gpg -d --recipient bogus@company.com --output file file.gpg
...
gpg: public key decryption failes: General error
gpg: decryption failed: No secret key

So, I don't know why im getting this error, nor how to get around it.
When I issue the command:
gpg -K
or
gpg -k
I get a key for both, and it appears to be the same key.
Any ideas what im doing wrong?

Is there a better way to simply encrypt/decrypt files using keys so I don't have to specify any passphrases during the encryption step (which is scripted)?

Two problems here,

1) your first idea to use symmetric encryption was probably okay. You can use a passphrase-file with the option “--passphrase-file” with a file-name or “--passphrase-fn” for use with a file-descriptor. This might solve your privacy-issues. It raises others, but those may not be your problem.

2.) I am almost sure, that you missed the point with the SECRET keys. Are you certain that their actual location corresponds with what you have configured for the gpg-instance to be used by authorized users? Not knowing the organization of the file-system in use, I can only guess. But you can be sure, that “No secret key” means that there is really ”no secret key”!

But, as stated above, you could do without public keys. I cannot really recommend the one or the other, as the procedures to establish in your environment might impose one of both for reasons, that I cannot see.

Most important of all: I am again certain that you should read the documentation more thoroughly. Simple glitches should not be condoned in a security-sensible scenario, especially if a number of other people are involved.

Thanks. When I created the keys, it also created a files under $HOME:
.gnupg/pubring.gpg
.gnupg/secring.gpg
.gnupg/trustdb.gpg
all of which are over 1KB in size.

When I issue the "gpg -K", it does show a key labled with "sec", which I thought to mean the secret key.
$ gpg -K
/home/user/.gnupg/secring.gpg
------------------------------
sec 2048R/5D60D1A2 2016-10-21
uid User (Test User) <bogus@company.com>
ssb 2048R/F45D9871 2016-10-21
Is this not the secret key it should be using?

I watches several videos and followed the examples from "https://www.gnupg.org/gph/en/manual/x110.html" regarding setting up and using keys, and I followed them as best I can.
The big difference seems to be that in the videos they get prompted for a Passphrase, while I do not.
Basically, I am not able to reproduce the example from https://www.gnupg.org/gph/en/manual/x110.html without the error.

Does it work if you don't use --recipient for decrypting? I think it's meaningless in that context anyway.

This is a configuration which corresponds to the usual use of GnuPG by 1 user who wishes to encrypt and send stuff to other people, who might use a similar installation to decrypt stuff and/or respond.

What you described above is a more complicated setting with different people accessing encrypted content. I cannot know which GnuPG-instance they are using or if it is all the time the same. The location of the secret key must correspond to the configuration of the GnuPG instance that is employed by each user. If you have to store secret keys on a server (very bad, very bad), then I do not know how you should configure GnuPG. And I even do not want to know!

It would be far better to create individual key-pairs for each user and encrypt the content with the multiple keys of the concerned addressees (maybe all). GnuPG can be installed on the individual workstations and no secret keys will ever have to be shared or made public (you know it hurts to even type these words).

Your requirements may be different, but they may also render all security-considerations moot. Also, where web-protocols are used for data-exchange, different encryption mechanisms (ssl, ssh) with secret keys appear to be adapted.

I have waited intentionally for other contributions to this thread, but these are all the indications that I can give, myself, at this time.

Offhand, it seems to me that symmetric encryption would be perfectly satisfactory for your situation. (Either GPG or openssl could be used, because all of them provide good, trustworthy implementations of good, trustworthy symmetric ciphers.)

You simply want to encrypt the data using a (symmetric) key that you believe that you can "keep secret." You simply want to be sure that anyone who steals the backup cannot make use of it without simultaneous possession of the key.

You are not transferring these files anywhere, and this (IMHO ...) negates any practical necessity to try to use "public key" (PKI) techniques.

In all PKI situations, some (pure-random) symmetric cipher-key is actually used (due to practical necessity ...) to encrypt the data, while the PKI layer is used to enable the two parties to transfer knowledge of that symmetric key's value (in this particular message). You have no need for this layer of complexity, and it brings no benefit whatsoever to you.

Therefore, keep it simple: symmetrically encrypt the data using a random, secret, binary, key. Make damned-sure that no one can penetrate the software to extract the key. Protect access to the key by appropriate conventional means, while being sure that no one will resort to writing it down on a piece of tape underneath the keyboard, just "to get their work done." Be sure that the key, far from being anything that "could possibly be derived from 'anything that might be found in a dictionary,'" is an absolutely-unpredictable random number which is the same size as the underlying symmetric key-space. Then, guard it.

Incidentally, the openssl tool has some very useful-to-you functions, such as openssl rand, which "generates pseudo-random bytes." That would be a terrific way to generate your symmetric key, because this is a cryptographically strong PRNG = Pseudo-Random Number Generator. (Far superior, then, to "rand()," or to "haphazard banging-around on your keyboard.") This trustworthy tool really can produce "an n-bit key" that actually would give your opponent "2^n possibilities, every one of them equally likely." Which is exactly what you want for "a symmetric cipher-key" that you think that you can actually manage to "keep secret."