You're looking for two things, both of which RSA can provide:
- You want to encrypt a message so it cannot be read without the private key of the destination.
- This is encryption TO the public key of the destination. You're doing this already!
- You want the destination to be able to verify that you, the approved source, is in fact the one who sent the message.
- This is signing and verifying. You need to sign the message with your (the source's) private key when you're encrypting it to the destination's public key. Then the destination uses your (the source's) public key to verify who sent the message.
An example of using GPG to do this from a batch file (i.e. automated commands - you SHOULD have an RSA key pair for nothing but this, since the passphrase is vulnerable in the batch file). If you have a human sending commands, they should NOT use the --passphrase argument; have them enter it into your software so it's not vulnerable!
gpg --batch --encrypt --sign --local-user "Your own private key <[email protected]>" --passphrase "Put your private key passphrase here" --recipient "DestinationKey <their email>" --output "test.command.gpg" "test.command"
You will, of course, need to make sure the destination verified the message, and that the signing key is, in fact, the correct one.
Another reference is What is the difference between encrypting and signing in asymmetric encryption?.
EDITED TO ADD: As far as alternatives to RSA for asymmetric encryption, the two most common that I'm aware of are DSA (based on discrete logarithms, and please try to use a |p| >= 2048 and a |q| >= 224, just as you'd use at least 2048 bits for your RSA key) and EC (Elliptic Curve - be very careful which curve you pick - the 25519 curves seem to be well regarded so far, ans use at least 256 bits) variants like ECDSA (Elliptic Curve Digital Signature Algorithm. See Signatures: RSA compared to ECDSA and RSA vs. DSA for SSH authentication keys for references.