Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

To move a conventional SSH key, copy the private key and its matching .pub file from the old computer’s ~/.ssh directory to the new computer over an encrypted channel. Put them in the new account’s ~/.ssh, restrict the private file to the account owner, load it into ssh-agent, and test the service or server. The file without .pub is the secret; the .pub file is safe to register with a Git host or server.

Copying is technically supported on multiple devices, but a separate ED25519 key per device is safer when you can update every account and server. A device-specific key limits the damage if one computer is lost or compromised. Hardware-backed FIDO2 keys are different: their private material stays on the authenticator and must not be copied as a file.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

First, identify what kind of SSH key you have

The usual file-based key pair consists of two files in your SSH directory:

  • id_ed25519 is the private key. Treat it like a password or security token and never send it to another person or upload it to an account-setting page.
  • id_ed25519.pub is the public key. You can copy its complete one-line contents into a Git host, a server’s authorized_keys, or another approved access-control system.

Names can differ. Older RSA pairs commonly use id_rsa and id_rsa.pub; a custom pair might be named work-laptop and work-laptop.pub. Do not assume that id_ed25519 is the key actually used by your account. List the directory and inspect the public-key comments or your SSH configuration before transferring anything.

#1 Best Overall
Integral 16GB Crypto-197 256-Bit Hardware Encrypted 3.0 USB Secure Flash Memory Drive - Certified to FIPS 197, Brute-Force Password Attack Protection & Rugged Double-Layer Waterproof Design
  • Certified to FIPS 197 - High-level information security standard approved by the U.S. Government
  • Brute-Force Password Attack Protection - Data is automatically erased after 6 failed access attempts. The data and encryption key are securely destroyed and the crypto drive is reset
  • Rugged Double-Layer Waterproof* Design - Protects the crypto drive against knocks, drops, break-in and submerging in water. The electronics are shielded by a hardended inner case. The rubberised silicone outer casing provides a final layer of protection
  • Auto-lock - The crypto drive will automatically encrypt all data and lock when removed from a PC/Mac or when the screen saver or "computer lock" function is activated on the host PC/Mac
  • Secure Entry - Data cannot be accessed without the correct high-strength alphanumeric 8-16 character password. A password hint option is available. The password hint cannot match the password

List keys on macOS or Linux

ls -la ~/.ssh

Look for matching files and remember that a private key normally has no .pub suffix. Files such as known_hosts and config are useful SSH settings, but they are not key pairs. You may transfer a configuration file separately if it contains host aliases or an IdentityFile setting; review it first because it can contain hostnames, usernames, ports, or other sensitive operational details.

Find the key used by an existing connection

Run SSH in verbose mode against the relevant host:

ssh -vT git@github.com

In the diagnostic output, look for identity files SSH offers. The command may list several candidates, so the result is not proof that every listed file was accepted. An explicit IdentityFile in ~/.ssh/config, an agent-loaded key, or a host-specific setting can determine the final choice.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Choose between copying and generating a new key

Choice Best when Trade-off
Copy the existing pair You need continuity, cannot easily update all services, and can protect the transfer and the new computer. Both computers hold the same credential. A lost backup or compromised new computer can expose access everywhere that key is trusted.
Generate a new ED25519 key You want one credential per device, or you cannot move the old private key through a trustworthy channel. You must register the new public key on every Git host, server, and other SSH service, and remove the old key when it is no longer needed.

GitLab documents that one SSH key can be used on multiple devices by copying the private-key file, while recommending a new key for each device to reduce the impact of loss or compromise. GitLab and GitHub documentation both describe ED25519 as the preferred ordinary key type and show ssh-keygen -t ed25519 for creating one.

Do not upload the private file to GitHub or GitLab account settings. Those pages require the complete public-key text only. The service uses that public key to verify signatures produced by your private key; it never needs the private file.

Prepare a safe transfer

Do not email the private key, paste it into chat, or place it in an unencrypted cloud-sync folder. GitLab specifically identifies a password manager or an encrypted USB drive as safer transfer methods. The transfer medium should protect the file while it is moving and should be removed or securely cleared afterward.

Before copying, check these conditions

  • You know which account on the new computer will run SSH.
  • The destination account is protected by a strong login password, full-disk encryption, or both.
  • You have verified the source filename and, if applicable, its matching public key.
  • No backup, sync job, screenshot, shell history entry, or temporary archive will leave an unprotected copy of the private key.

If you suspect that the old computer or a backup has been compromised, do not copy the key. Generate a replacement, register its public half everywhere it is needed, and revoke the old key.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Transfer a file-based key on macOS or Linux

1. Create the destination directory

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Run this as the destination user, not as an administrator. The directory should belong to that user. If you created it with elevated privileges, correct ownership before testing:

sudo chown -R "$USER":"$(id -gn)" ~/.ssh

Use the ownership command only when the directory is incorrectly owned; it is not required for a normally created home directory.

Rank #2
Integral 8GB Courier-197 256-Bit Hardware Encrypted 3.0 USB Secure Flash Memory Drive - Certified to FIPS 197, Brute-Force Password Attack Protection & Super USB3.0 Transfer Speeds
  • Certified to FIPS 197 - High-level information security standard approved by the U.S. Government
  • Brute-Force Password Attack Protection - Data is automatically erased after 6 failed access attempts. The data and encryption key are securely destroyed and the crypto drive is reset
  • Auto-lock - The crypto drive will automatically encrypt all data and lock when removed from a PC/Mac or when the screen saver or "computer lock" function is activated on the host PC/Mac
  • Secure Entry - Data cannot be accessed without the correct high-strength alphanumeric 8-16 character password. A password hint option is available. The password hint cannot match the password
  • SuperSpeed USB 3.0 - Transfer all your confidential files and folders faster than ever before. Works on both PC & Mac

2. Copy both halves through the protected medium

Copy the private file and its matching public file, preserving their names. For an ED25519 pair, that normally means id_ed25519 and id_ed25519.pub. An encrypted USB drive can be mounted on both computers, or a password manager can hold the protected file temporarily. Never copy only the public file when you intend to authenticate as the existing identity: the new computer also needs the private half.

If you use a direct computer-to-computer transfer, use an encrypted connection and authenticate the destination carefully. Avoid unencrypted file-sharing protocols. After the copy, eject the removable drive and remove temporary copies from the source, destination staging directories, and recycle or trash locations according to your operating system.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

3. Set private-key permissions

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

The private file must be readable and writable only by its owner. OpenSSH can reject a key that is accessible to other users. The public file does not contain the secret, but keeping it owner-writable and generally readable is conventional. If your filename is different, substitute that path exactly.

4. Start an agent and load the key

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

Enter the key’s passphrase when prompted. The agent keeps the decrypted key available to SSH for the lifetime of the agent or session, so you do not need to type the passphrase for every connection. Confirm that the agent has it:

ssh-add -l

The output should show a fingerprint for the transferred key. If it says that no identities are loaded, the key is present on disk but not available to the agent.

5. Test the actual service or server

Use the target service’s current SSH verification command. Common examples include:

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
ssh -T git@github.com
ssh -T git@gitlab.com

A Git service may intentionally close the session after identifying you rather than provide a shell. Read the complete response and compare it with that service’s current verification instructions. For a normal server login, test the real account and hostname:

ssh username@example-host

If the test succeeds, the new computer is using a trusted key. If it fails, follow the troubleshooting section rather than repeatedly copying files.

Rank #3
Integral 4GB Crypto-197 256-Bit 3.0 USB Flash Drive Encrypted - FIPS 197 Certified, Brute Force Password Attack Protection & Waterproof Double Layer Design
  • Certified to FIPS 197 - U.S. Government Approved High Level Information Security Standard.
  • Protection against brute force password attacks - Data is automatically erased after 6 unsuccessful access attempts. The data of the USB flash drive type c encryption with dual connectors is destroyed and the cryptographic drive is reset.
  • Durable dual-layer waterproof design* — Protects the crypto reader from bumps, drops, run-in and immersion in water. The electronics are protected by a hardened internal case. Rubberized silicone outer case provides a final layer of protection.
  • Auto-Lock —The cryptographic key automatically encrypts all data and locks when removed from a PC/Mac or when screen protection or "computer lock" is enabled.
  • Secure Entry —Data on these flash drives cannot be accessed without the correct alphanumeric password of 8 to 16 characters. A password indication option is available for this flash drive. The hint cannot match the password.

Transfer a key on Windows, Git for Windows, and WSL

Windows can have more than one SSH environment. Git for Windows typically uses a Windows home directory, while WSL uses a Linux home directory inside the selected distribution. A key copied into one environment is not automatically available in the other. First decide where Git or your SSH command actually runs, then copy and load the key there.

Git for Windows

Open a regular, non-elevated Git Bash terminal and check the home directory:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
echo "$HOME"
ls -la ~/.ssh

Place the pair in that .ssh directory. GitHub’s documentation describes starting the Windows ssh-agent service and adding the key from a non-elevated terminal. The exact service-management command can vary with Windows policy, so use the current instructions for your installed Git for Windows version. After the service is running, load the key:

ssh-add ~/.ssh/id_ed25519
ssh-add -l

If Windows reports that the agent is unavailable, start or enable the OpenSSH Authentication Agent service with an administrator-approved Windows service-management method, then reopen a normal terminal and run ssh-add again. Do not run daily Git commands as administrator merely to work around a permissions problem.

WSL

Inside the WSL distribution that runs your Git commands, check:

echo "$HOME"
ls -la ~/.ssh

Copy the key into that Linux home directory and apply the Unix permissions:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Start an agent in WSL and load the key with the same eval and ssh-add commands used on macOS and Linux. A key loaded into the Windows agent may not appear in a separate WSL agent unless you deliberately configure agent forwarding or integration. Do not enable forwarding casually: a remote host could request signatures from a forwarded agent while the connection is active.

Keep environments from being confused

Run which ssh (or where.exe ssh in a Windows shell) and git config --show-origin --get core.sshCommand when Git appears to use the wrong key. These commands reveal which executable and Git override are involved. Then load the key in that same environment or set an explicit host configuration there.

Rank #4
Kingston IronKey Vault Privacy 50 16GB Encrypted USB
  • FIPS 197 with XTS-AES 256-bit Encryption: Provides business-grade security with hardware-based encryption to protect your sensitive data
  • Brute Force and BadUSB Attack Protection: Safeguards against unauthorized access attempts and malicious USB attacks with digitally-signed firmware
  • Multi-Password Option with Complex/Passphrase modes: Offers flexible password configuration options to meet various security requirements and user preferences
  • New Passphrase Mode: Enhanced security feature allowing users to create longer, more memorable password phrases for easier access without compromising protection
  • Dual Read-Only (Write-Protect) Settings: Enables write protection functionality to prevent accidental data modification or deletion when needed

Handle custom filenames and several hosts

Load a custom private-key path explicitly:

ssh-add /path/to/private-key

For repeatable host-specific selection, use ~/.ssh/config:

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

With this alias, use ssh -T git-work or a Git remote that points to git-work. IdentitiesOnly yes tells SSH to prefer the configured identity instead of offering a large collection of agent keys. Protect the configuration file from unwanted edits and review it before transferring because it can reveal infrastructure details.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

If one private key serves several hosts, you can keep one IdentityFile entry or load it once into the agent. If you generated a new per-device key, add a separate host or account registration for its public half rather than replacing unrelated keys blindly.

When the key is FIDO2 or security-key-backed

Keys such as ed25519-sk and ecdsa-sk depend on a physical authenticator. Their private material is designed to remain on that authenticator. Do not search for a normal private-key file to copy and do not export a secret from the device.

Reconnect the authenticator to the new computer and use the resident-key import or load process documented for your OpenSSH version. The cited GitLab guidance requires OpenSSH 8.2 or later for these key types and documents commands such as:

ssh-add -K
ssh-keygen -K

Command behavior can differ by OpenSSH build and token configuration. If the key is not resident on the authenticator, you may need the original authenticator and its PIN or touch confirmation; a copied public key alone cannot recreate the private credential. Register the resulting public key with the service if the new device or account does not already have it.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Generate a new key instead of copying

Choose this route when you want per-device isolation or cannot establish a safe transfer path. On macOS, Linux, Git Bash, or WSL, create an ED25519 pair with a passphrase:

ssh-keygen -t ed25519

Accept the proposed location only if it will not overwrite a key you still need. Otherwise provide a new filename, such as ~/.ssh/id_ed25519_new-laptop. Use a strong, memorable passphrase. Then load the new private file:

Best Value
Kingston Ironkey Keypad 200 16GB Encrypted USB | Alphanumeric Keypad | Multi-Pin Access | XTS-AES 256-bit | FIPS 140-3 Level 3 Certified | Brute Force & BadUSB Protection | IKKP200/16GB,Blue
  • FIPS 140-3 Level 3 (Pending) Certified Military-Grade Security
  • OS/Device Independent
  • XTS-AES Hardware Encryption
  • Enforced Alphanumeric PIN
  • Multi-PIN (Admin and User) Option
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_new-laptop

Display the public text and copy the complete single line, including its key type and trailing comment:

cat ~/.ssh/id_ed25519_new-laptop.pub

Add that public key to each required Git account, deployment system, or server’s ~/.ssh/authorized_keys. Do not paste the private file into any web form. Test every destination from the new computer before removing the old public-key registration. Once all tests pass and the old device is no longer trusted, delete the old key from each service and remove obsolete local copies.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Diagnose “SSH still asks for a key” or authentication failures

The agent does not contain the key

ssh-add -l

If the fingerprint is absent, start the agent and run ssh-add /full/path/to/private-key. A new terminal, a reboot, or a separate Windows/WSL environment can create a new agent context.

SSH is using a different home directory

Compare echo "$HOME", which ssh, and the path shown by verbose SSH output. This is especially important when Git for Windows and WSL are both installed. Copying a key to the Windows profile does not place it in WSL’s Linux home.

Permissions are too broad

On Unix-like systems, run chmod 700 ~/.ssh and chmod 600 ~/.ssh/private-key-name. Check ownership with ls -ld ~/.ssh and ls -l ~/.ssh/private-key-name. Correct ownership if another account or administrator owns the files.

The public key is not registered or does not match

A private key works only with its corresponding public key. Compare the fingerprint of the local public key with the key listed by the service, or regenerate the public half from the private key if the public file is missing:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
ssh-keygen -y -f ~/.ssh/private-key-name

Register the resulting public text where the account or server expects it. On a self-managed server, verify that the complete line is present in the intended account’s ~/.ssh/authorized_keys and that the server is using the expected account and port.

The wrong identity is offered

Use a host-specific IdentityFile and, when appropriate, IdentitiesOnly yes in ~/.ssh/config. Run a verbose test to see which keys are offered. Remove stale keys from the agent with ssh-add -d /path/to/key or clear and reload the agent according to your platform’s current OpenSSH behavior.

The key was copied but the old registration remains

Copying does not revoke anything. If the old computer is lost, stolen, or suspected of malware, immediately remove that key from every Git account, server, and automation system that trusts it. Generate and register a replacement, then test it before relying on it for deployments.

After the move: a security checklist

  • Confirm that the private key has a passphrase and restrictive permissions.
  • Confirm that only the public key was added to account settings and servers.
  • Check ssh-add -l in every environment that runs SSH.
  • Test each important host with its own current verification command.
  • Delete temporary transfer copies and unencrypted archives.
  • Record which device owns each key so you can revoke one device without disabling all others.
  • Revoke and replace a key as soon as compromise is suspected; do not wait for a failed login.

The practical decision is straightforward: copy the existing pair only when continuity is worth the shared-credential risk and the transfer can be protected; otherwise create a new ED25519 key for the new computer and register its public half. In either case, the private key stays private, the agent must be loaded in the environment that runs SSH, and a successful test against the real service is the final confirmation.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.