Recommended Free Tools
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
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
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.
First, identify what kind of SSH key you have
The usual file-based key pair consists of two files in your SSH directory:
id_ed25519is 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.pubis the public key. You can copy its complete one-line contents into a Git host, a server’sauthorized_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
- 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.
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.
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
- 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.
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.
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
- 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:
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:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →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
- 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.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchIf 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.
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
- 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.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesDiagnose “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:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →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 -lin 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.
Quick Recap
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.

