VMware ESXi and vSphere Cluster Management

Understanding id_rsa: SSH RSA Private Keys

Learn what id_rsa and id_rsa.pub are, how SSH key authentication works, how to configure and protect RSA keys, use them with Git, migrate to Ed25519, and troubleshoot failures.

id_rsa is the conventional filename for an RSA private key used by SSH. It is normally stored in the user's ~/.ssh directory on Linux or macOS. The matching public key is usually ~/.ssh/id_rsa.pub.

This guide explains SSH key pairs, secure key creation, remote installation, permissions, agents, client configuration, Git usage, key migration, and troubleshooting. SSH means Secure Shell, a protocol for secure remote login, command execution, forwarding, and file transfer. OpenSSH is the widely used SSH client and server implementation.

What id_rsa and id_rsa.pub mean

An SSH key pair contains two mathematically related files:

• Private key: ~/.ssh/id_rsa. It remains on the client device and proves that you possess the credential.
• Public key: ~/.ssh/id_rsa.pub. It can be installed on servers and services to authorize the matching private key.

The filename is only a convention. A key named id_rsa_work can be used just as well as one named id_rsa. The .pub file is not a password and cannot be used to derive the private key in practical use. Never confuse it with known_hosts, which records server host keys for identity checking rather than user authentication.

How SSH public-key authentication works

1. An SSH client connects to an SSH server for a remote account.
2. The server checks the account's ~/.ssh/authorized_keys file for an accepted public key.
3. The client selects the corresponding private key locally.
4. The server sends authentication data that the client must sign.
5. The client proves possession by producing a valid signature. The private key itself is not transmitted.

A key pair is generated by ssh-keygen. The server stores only the public key, usually as one complete line in authorized_keys. This model is generally preferable to password authentication because a strong private key is difficult to guess, can be protected by a passphrase, and does not require sending a reusable password to the server for each login.

Important files and locations

Linux and macOS normally use ~/.ssh. Common private-key names include id_rsa and id_ed25519; their public counterparts add .pub. Custom names are useful for separate work, personal, client, server, device, or environment identities.

RSA in modern SSH

RSA is a public-key cryptography algorithm. An RSA key can be used with modern RSA/SHA-2 SSH signature algorithms such as rsa-sha2-256 and rsa-sha2-512.

ssh-rsa is different: it commonly refers to the older RSA signature algorithm using SHA-1. Modern OpenSSH versions may reject that signature algorithm even when the RSA private key itself is valid. Prefer RSA/SHA-2 or upgrade the endpoint when possible. Do not globally re-enable deprecated algorithms; use a narrowly scoped temporary compatibility setting only when unavoidable.

Generate an id_rsa key pair

First check existing identities so that you do not overwrite a key that is still authorized somewhere:

ls -la ~/.ssh

To create a passphrase-protected RSA key with a distinct filename:

ssh-keygen -t rsa -b 4096 -C "device-purpose" -f ~/.ssh/id_rsa_example

Use a strong, memorable passphrase. It encrypts the private key at rest, so someone who copies the file still needs the passphrase. The comment identifies the key and is not secret. When ssh-keygen asks whether to overwrite an existing file, stop and verify the path unless replacement is intentional.

The command creates id_rsa_example and id_rsa_example.pub. Inspect the directory and fingerprint without displaying private key material:

ls -l ~/.ssh/id_rsa_example ~/.ssh/id_rsa_example.pub
ssh-keygen -lf ~/.ssh/id_rsa_example.pub

If the public file is missing, derive the public portion from the private key:

ssh-keygen -y -f ~/.ssh/id_rsa

For a new system that supports it, create an Ed25519 key instead:

ssh-keygen -t ed25519 -C "device-purpose" -f ~/.ssh/id_ed25519_example

Install and test the public key

Copy only the .pub file to the remote account. If available, ssh-copy-id appends it correctly:

ssh-copy-id -i ~/.ssh/id_rsa.pub user@example.com

Without that utility, log in using an existing method and append the public key as one complete line in the remote user's ~/.ssh/authorized_keys. Do not wrap, truncate, or alter the line. On the server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Test from a new terminal session before disabling passwords or removing an old key:

ssh -i ~/.ssh/id_rsa -o IdentitiesOnly=yes user@example.com

Permissions and ownership

OpenSSH checks that private keys and their parent directories are not writable or readable by inappropriate users. Incorrect modes or ownership can cause an otherwise valid key to be rejected.

The files and directory must be owned by the intended user. On the server, a root-owned or incorrectly owned home or SSH directory may also prevent login. Use ls -ld ~/.ssh and ls -l ~/.ssh to inspect them. Windows uses different ACL-based permissions; ensure the private key is accessible only to the intended Windows account and follow the behavior of the OpenSSH implementation in use.

chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_rsa && chmod 644 ~/.ssh/id_rsa.pub

Use ssh-agent safely

ssh-agent is a process that holds unlocked private keys for SSH clients. It reduces repeated passphrase prompts without writing the passphrase into shell history or scripts.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa
ssh-add -l

Remove one identity or clear the agent:

ssh-add -d ~/.ssh/id_rsa
ssh-add -D

Do not pass passphrases on command lines, store them in scripts, or use an agent you do not trust. Limit loaded identities and remove them when no longer needed.

Configure multiple identities

Use ~/.ssh/config to select a key by host alias:

Host work-git
    HostName git.example.com
    User git
    IdentityFile ~/.ssh/id_rsa_work
    IdentitiesOnly yes

IdentityFile selects a private key. IdentitiesOnly yes prevents the client from trying unrelated agent keys, which is especially useful when several identities are loaded. Create separate aliases for personal and work accounts, then check the effective configuration:

ssh -G work-git

Use id_rsa with Git

Git uses SSH authentication when a repository remote has an SSH URL. A typical SSH remote resembles git@host:account/project.git, unlike an HTTPS remote. Register the matching public key with the intended Git hosting account, then use the configured alias in the remote URL:

git remote set-url origin git@work-git:work-account/project.git
ssh -T git@work-git

Test each account-specific alias. If Git authenticates as the wrong account, inspect the remote URL, agent identities, and resolved configuration with ssh -G. The public key must be registered with the account that should receive the connection.

Private-key formats and conversion

OpenSSH private keys may use the modern OpenSSH private-key format. Older tools may instead require a PEM-formatted RSA private key. These are file encodings, not different authentication identities. Convert only when a specific older client requires it, and back up the original securely before changing formats. Never place either format in source control or transmit it through insecure channels.

Key security lifecycle

• Protect every private key with a strong passphrase.
• Keep encrypted backups in secure storage with restricted access.
• Use separate keys for different devices, people, services, environments, and organizations.
• Remove old public keys from authorized_keys, Git accounts, and service accounts when they are no longer needed.
• After suspected exposure, generate a replacement key, install its public key, verify access, and remove the old public key everywhere it was authorized.
• A private key committed to source control is compromised even if the commit is later deleted. Rotate it and review access logs.

Safely migrate from RSA to Ed25519

1. Create a passphrase-protected Ed25519 key.
2. Install its public key alongside the existing RSA public key.
3. Open a separate session and test the new key explicitly.
4. Update ~/.ssh/config and Git hosting settings.
5. Remove the old RSA authorization only after the new route is confirmed.
6. Disable password authentication only after verified key-based access and an account-recovery plan.

Troubleshoot SSH authentication

Verbose output separates client key-selection problems from server authorization problems:

ssh -vvv -i ~/.ssh/id_rsa -o IdentitiesOnly=yes user@example.com

When a public key appears correct, check that it is one intact line, belongs to the private key being offered, and is in the correct remote user's home directory. If administrative access exists, inspect the SSH server configuration and authentication logs. Common server-side settings include allowing public-key authentication and pointing to the expected authorization file.

Exam-relevant notes

• id_rsa is private; id_rsa.pub is public.
• The private key stays on the client; the server stores the public key in authorized_keys.
• known_hosts verifies server identity and does not authorize the client user.
• ssh-agent caches unlocked keys, while ssh-add manages those identities.
• ssh-rsa can mean a legacy SHA-1 signature algorithm; it is not synonymous with every RSA key.
• Ed25519 is normally the preferred choice for new keys when compatibility permits.

For related practice, see SSH RSA private-key usage and security.