You cannot decrypt an RSA private key with openssl pkeyutl because ssh-add does not encrypt keys; it loads unencrypted keys into the SSH agent's memory. To encrypt a PEM file for storage, use openssl rsa -aes256 -in key.pem -out key_encrypted.pem. To remove passphrase protection, use openssl rsa -in key_encrypted.pem -out key_unencrypted.pem.
Understanding SSH Agent Encryption Misconceptions
A common source of confusion arises when users attempt to manipulate private keys using OpenSSL commands after interacting with the SSH agent. The core misunderstanding lies in the function ofssh-add. Many assume that adding a key to the agent encrypts the file on disk or transforms it into a binary blob that requires decryption later. This is technically incorrect.
When you run ssh-add ~/.ssh/id_rsa, the SSH client reads your private key from the filesystem. If the key is protected by a passphrase, the user must enter it interactively. Once verified, the decrypted private key material is loaded into the memory of the running ssh-agent process. The original file on disk remains unchanged. It retains its original format (PEM or OpenSSH) and its original encryption status.
The SSH agent holds the decrypted key in RAM to facilitate authentication for subsequent SSH connections without requiring repeated passphrase entry. It does not create a new encrypted version of the key file. Therefore, there is no "encrypted payload" generated by ssh-add that can be passed to openssl pkeyutl for decryption. Attempting to treat the output of ssh-add or the agent's internal state as an encrypted file leads to errors because the data structures are incompatible with standard OpenSSL decryption routines.
If your goal is to manage key encryption at rest (on the disk), you must use OpenSSL directly on the key file itself, independent of the SSH agent. The SSH agent operates on decrypted keys in memory, while OpenSSL operates on encrypted files on disk. These are two distinct layers of security management.
For more information on resolving connection issues that might arise during key management, see our guide on Troubleshooting kex_exchange_identification Error in Linux SSH Connection.
Encrypting an Unprotected Private Key
To add password protection to an existing unencrypted RSA private key, you should use theopenssl rsa command with a specific cipher algorithm. This process converts a plain-text key file into an encrypted PEM file.
First, ensure you have a backup of your original key. Never overwrite the only copy of a critical private key until you have verified the new encrypted version works.
Use the following command to encrypt the key using AES-256:
openssl rsa -aes256 -in id_rsa -out id_rsa_encryptedid_rsa_encrypted file contains the same key material but wrapped in an encrypted structure defined by the PKCS#1 standard.
It is important to note that ssh-add can still read this newly encrypted file. When you run ssh-add id_rsa_encrypted, the SSH agent will prompt you for the passphrase you just created. Upon successful entry, the agent loads the decrypted key into memory, just as it would with any other key.
Removing Passphrase Protection from an Encrypted Key
Conversely, if you wish to remove the passphrase from an encrypted key—perhaps to automate scripts that cannot handle interactive prompts—you can use OpenSSL to strip the encryption. This results in an unencrypted key file. Be aware that storing unencrypted private keys poses a significant security risk. Anyone who gains access to the file can impersonate you. Only perform this step if necessary and ensure strict file permissions are set afterward. Run the following command:openssl rsa -in id_rsa_encrypted -out id_rsa_unencryptedid_rsa_unencrypted without any additional encryption layer. The resulting file can be used by ssh-add without prompting for a password, assuming the file permissions allow the user to read it.
Setting File Permissions
Regardless of whether the key is encrypted or not, Linux systems require strict permissions on private key files. If permissions are too open, SSH clients will refuse to use the key. After creating or modifying your key file, apply these permissions:- Owner Read/Write:
chmod 600 id_rsa - No Group/Other Access: Ensures only the owner can read the key.
Creating Handy Aliases
Frequently encrypting and decrypting keys can become tedious. You can streamline this workflow by creating shell aliases in your~/.bashrc or ~/.zshrc file.
Add the following lines to your configuration file to create shortcuts:
# Encrypt a key with AES-256
alias ssh-key-encrypt='openssl rsa -aes256 -in $1 -out ${1}_enc'
# Decrypt a key (remove passphrase)
alias ssh-key-decrypt='openssl rsa -in $1 -out ${1%_enc}'ssh-key-encrypt id_rsa will generate id_rsa_enc. Running ssh-key-decrypt id_rsa_enc will generate id_rsa.
Remember that these aliases operate on local files. They do not interact with the SSH agent's memory. The agent still needs to be started (eval $(ssh-agent)) and populated (ssh-add) separately.
Verifying Key Integrity
After encrypting or decrypting, verify the key is valid by attempting to list its details:openssl rsa -in id_rsa_encrypted -check -nooutFrequently Asked Questions
Can I recover a lost passphrase for my SSH key?
No, you cannot recover a lost passphrase for an SSH private key. The encryption used (typically AES-256) is designed to be computationally infeasible to break without the key. If you forget the passphrase, the key material is effectively lost forever. You must generate a new key pair and update all authorized hosts with the new public key.Does ssh-add store the key permanently on disk?
No,ssh-add stores the decrypted key only in the memory of the ssh-agent process. It does not write the key back to the filesystem in any form. When the ssh-agent process terminates, the key is removed from memory. To persist the agent across sessions, you typically configure your desktop environment or shell startup scripts to launch the agent automatically.
Why does openssl pkeyutl fail when I try to decrypt my SSH key?
openssl pkeyutl expects an encrypted data payload using specific padding schemes like PKCS#1 OAEP. SSH private keys use a different structure (PKCS#1 or PKCS#8). Furthermore, since ssh-add does not produce an encrypted file, there is nothing for pkeyutl to decrypt. Use openssl rsa for key-specific encryption and decryption tasks instead.
Is it safe to keep unencrypted SSH keys on my system?
It is generally unsafe to leave unencrypted private keys on disk unless they are strictly protected by file permissions (chmod 600) and the system itself is secured against unauthorized access. If someone gains root access or physical access to the machine, they can copy the unencrypted key and use it to authenticate as you. Encrypting the key adds a layer of defense even if the file is stolen.
How do I switch between multiple encrypted keys in the SSH agent?
The SSH agent can hold multiple keys simultaneously. When you connect to a server, the agent offers all loaded keys. If the server accepts one, the connection proceeds. If not, it tries the next. You do not need to decrypt or re-encrypt keys to switch contexts. Simply ensure all relevant encrypted keys are added to the agent usingssh-add, and provide their respective passphrases when prompted.