If your cipher is using padding (i.e. is not in a streamed mode such as CFB, OFB, CTR or CTS), then it may be able to tell just by looking at the encrypted data's size. For instance if it is 24 bytes (192 bits), then it could be Blowfish (because it has a block size of 64 bits, and 192 is divisible by 64), and it cannot be AES because 192 cannot be divided by 128 (AES's block size). But since most block sizes are multiples of one another, this will probably not be very helpful, but it can be used to narrow the choice down sometimes.
If the above method failed, then it is computationally infeasible to distinguish data decrypted with the wrong key with the correct cipher and data decrypted with the correct key with the wrong cipher. They both produce random data. (this can be formalized assuming the cipher is a random permutation). This is unless the cipher has big weaknesses, of course, which is probably not the case if it is included in OpenSSL (except the old export-safe ones like 40-bit rc4).
So the only way is to try all the possible ciphers the data could have been encrypted with (there are an infinite number of potential ciphers, but only a few are actually used in the world). You could always whip up a script to automate it.
Of course, you can store the cipher used to encrypt the file next to it (or within it), like a byte that takes a different value for each cipher. If the key is kept secret, this presents no security risk (modern ciphers are designed to rely completely on the key - see Kerckhoffs's Principle).
