Free tools Windows power users keep installed
One-click scans. No signup required.
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 using an encrypted transfer method. Put the files in the new account’s ~/.ssh directory, restrict the private file to the account owner, start ssh-agent, run ssh-add, and test the host you need to access.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The file without .pub is the secret credential. The .pub file can be registered with a Git service or server, but the private file must never be emailed, pasted into chat, uploaded to account settings, or placed in an unencrypted sync folder.
As an Amazon Associate I earn from qualifying purchases.
Understand which SSH files you are moving
A normal file-based SSH key is a pair. The private key is usually named id_ed25519, while the matching public key is id_ed25519.pub. Older installations may use names such as id_rsa, and a custom key may have any filename. The two files are related, but they do not have the same security requirements.
- Private key: the file without
.pub. It proves your identity and must remain secret. - Public key: the file ending in
.pub. Its complete text is intended to be copied to a Git account, a server’sauthorized_keysfile, or another SSH service. - SSH configuration: an optional
~/.ssh/configfile that tells SSH which key, username, port, or host alias to use. It is not itself a credential, but moving it can preserve host-specific behavior.
On the old computer, list the directory before copying 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
ls -la ~/.sshLook for the key that is actually used by the host. If several keys exist, do not assume that id_ed25519 is the right one. Check the configuration file, your Git remote, or the agent’s loaded identities. The command ssh-add -l shows keys currently loaded in the agent; it does not prove that every key in ~/.ssh is in use.
Copy the existing key or create a new one?
Both approaches are valid. Copying preserves the same identity, so every service that already trusts the old public key continues to work. Creating a new key gives each computer a separate credential, which limits the damage if one device is lost or compromised.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problems| Choice | Best when | Trade-off |
|---|---|---|
| Copy the existing pair | You need continuity and can move the private file through a protected channel. | Both computers hold the same credential. If the new computer or a backup is exposed, the copied key must be revoked and replaced everywhere it was trusted. |
| Generate a new ED25519 key | You want per-device isolation, the old computer is unavailable, or you cannot safely transfer its private file. | You must register the new public key with every Git host and server, and remove the old key when it is no longer needed. |
GitLab documents that the same SSH key can be used on multiple devices, while recommending a separate key for each device to reduce the impact of loss or compromise. ED25519 is the preferred ordinary key type in the cited GitLab and GitHub guidance.
When copying is reasonable
Copy the pair when the old machine is under your control, the transfer can be encrypted, and keeping one identity is more useful than isolating devices. You still need to protect the new computer, backups, and any removable media used during the move.
When regeneration is safer
Generate a replacement when the old device is missing, may have malware, has been given to someone else, or the private key has ever been exposed. A new key does not automatically invalidate the old one: remove the old public key from every account and server that trusted it.
Use a protected transfer method
GitLab specifically warns against sending a private key by email, chat, or unencrypted cloud synchronization. Safer choices include an encrypted USB drive, an encrypted password-manager vault that permits secure file attachments, or a direct transfer over an encrypted SSH connection.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
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
Encrypted USB drive
- On the old computer, copy the private key, its matching public key, and, if needed, the SSH configuration file to the encrypted drive.
- Eject the drive from the old computer and unlock it only on the new computer. Do not leave the drive unlocked while unattended.
- Copy the files into the new account’s
~/.sshdirectory, then eject the drive. - Remove the temporary copies from the drive when the move is complete, or securely erase the drive before reusing it.
An encrypted drive protects the files if the media is lost, but it does not protect a key after you unlock the drive on a compromised computer.
Password-manager attachment
Use a vault with end-to-end encryption and a strong, unique vault passphrase. Attach the files as files rather than pasting the private key into a normal note. Download them only to the intended account on the new computer, confirm the destination permissions, and delete the local download if it was only a temporary copy.
Direct encrypted copy
If both computers already have a trusted SSH path, an scp or sftp transfer encrypts the connection. Copy the private and public files separately so that you know exactly what arrived:
scp ~/.ssh/id_ed25519 newuser@new-computer:~/.ssh/id_ed25519
scp ~/.ssh/id_ed25519.pub newuser@new-computer:~/.ssh/id_ed25519.pubReplace the username, host, and filenames with your values. This method is appropriate only when the destination SSH service and host key are verified; it does not make an untrusted destination safe.
Transfer a key on macOS or Linux
The following procedure applies to a normal file-based key. Run it as the account that will use SSH, not as an unrelated administrator account.
- Make sure the destination directory exists.
mkdir -p ~/.ssh chmod 700 ~/.ssh - Copy the pair into that directory. Use the encrypted USB, password-manager download, or encrypted network transfer. If the key has a custom name, preserve that name. Do not rename an unrelated key over an existing file without first making a protected backup.
- Set private-key permissions.
chmod 600 ~/.ssh/id_ed25519The private file must be readable and writable only by its owner. A public key can normally be readable by other users, but keeping the entire directory private is the safer default:
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.
chmod 644 ~/.ssh/id_ed25519.pub - Check ownership. The files should belong to the account that will run SSH. If they were copied as another user, correct the owner with your operating system’s account-administration tools before testing.
- Start an agent for the session.
eval "$(ssh-agent -s)" - Load the private key.
ssh-add ~/.ssh/id_ed25519If the key is passphrase-protected, enter the passphrase when prompted. The agent keeps the unlocked key available to SSH without requiring you to type the passphrase for every connection.
- Confirm that the agent has it.
ssh-add -lYou should see the key’s fingerprint. If the list is empty, SSH cannot use the key through that agent yet.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. - Test the target host. For a Git service, use that service’s current SSH verification command, such as
ssh -T [email protected]orssh -T [email protected]. For your own server, connect with its normal hostname and username.
Some desktop environments start an agent automatically, while others start one only for a terminal session. If the key works in one terminal but not another, compare the SSH_AUTH_SOCK environment variable and load the key into the agent used by the failing session.
Transfer a key on Windows
Windows can have more than one SSH environment. Git for Windows commonly uses a Windows home directory such as C:UsersYourName.ssh, while WSL uses a separate Linux home directory such as /home/yourname/.ssh. A key copied into one environment is not automatically available in the other. Copy and load it where the Git or SSH command actually runs.
Git for Windows or Windows OpenSSH
- Open a non-elevated PowerShell or Git Bash terminal as the account that will use SSH.
- Inspect the expected directory. In PowerShell, for example:
Get-ChildItem $HOME.ssh - Create the directory if necessary and copy the private and public files there. Keep a custom filename if your configuration refers to one.
- Start the Windows
ssh-agentservice. In an administrative PowerShell, set the service to start automatically if your organization permits that, then start it. GitHub’s Windows instructions use the Windows service rather than a Unix-styleevalcommand. - Return to a normal, non-elevated terminal and load the key:
ssh-add $HOME.sshid_ed25519 - List loaded identities and run the target service’s SSH test:
ssh-add -l ssh -T [email protected]
Windows OpenSSH also checks file access controls. Open the private key’s Properties, select the Security and Advanced settings, disable inherited access when appropriate, and ensure that only your account (and an administrator policy required by the machine) can read the file. If OpenSSH reports that the private key is too accessible, correct the ACL rather than weakening the SSH client.
WSL
Inside WSL, follow the Unix procedure: place the key in the Linux user’s ~/.ssh, run chmod 700 ~/.ssh and chmod 600 ~/.ssh/id_ed25519, start or connect to an agent, and run ssh-add. A key in C:UsersYourName.ssh is not automatically the same key as one in WSL’s home directory. Decide which environment owns the workflow and test from that environment.
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
Register a new public key when you regenerate
If you chose a new key instead of copying the old one, create it on the new computer:
ssh-keygen -t ed25519Accept the suggested path or specify a distinct filename when you already have another key. Use a strong passphrase. Then start the agent and load the new private key:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519Display the public half and copy the entire single line, including its key type and any comment:
cat ~/.ssh/id_ed25519.pubIn the Git service’s account settings, add that public-key text to the SSH keys section. On a server you administer, append the line to the target account’s ~/.ssh/authorized_keys file without wrapping or altering it. The service or server needs only the public key; it never needs your private file.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →After confirming the new key works, remove the old public key from services and servers where it is no longer required. If the old computer was lost or compromised, treat removal and replacement as urgent rather than waiting for the old key to fail.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Handle custom filenames and several hosts
Multiple keys are common when personal, work, and deployment access must be separated. Load the intended file explicitly:
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
ssh-add ~/.ssh/work_ed25519Use ~/.ssh/config when different hosts need different identities:
Host code-work
HostName gitlab.com
User git
IdentityFile ~/.ssh/work_ed25519
IdentitiesOnly yes
Host code-personal
HostName github.com
User git
IdentityFile ~/.ssh/personal_ed25519
IdentitiesOnly yesWith aliases like these, use git@code-work:group/project.git or ssh -T code-work according to the service’s connection format. Keep the configuration file readable only by your account if it contains sensitive host details, and make sure every IdentityFile path exists on the new computer.
Recommended Free Tools
IdentitiesOnly yes prevents SSH from offering a large collection of agent keys to a host and is useful when a server rejects connections after too many unsuccessful key offers. It does not replace loading the correct key or registering the matching public key.
FIDO2 and security-key-backed SSH keys are different
A FIDO2-backed key such as ed25519-sk or ecdsa-sk is tied to a hardware authenticator. There may be a small local public-key file, but the private credential is held by the authenticator and must not be copied as an ordinary file.
- Connect the same security key to the new computer.
- Use the resident-key import or load procedure supported by your OpenSSH build, such as
ssh-keygen -Kto retrieve resident keys orssh-add -Kwhere that platform supports loading them. - Complete the authenticator’s touch or PIN prompt.
- Load the resulting identity into the agent and test the target host.
GitLab’s cited guidance requires OpenSSH 8.2 or later for the referenced ed25519-sk and ecdsa-sk types. If the new computer has an older client, update OpenSSH or use the platform’s documented security-key workflow; do not attempt to copy a nonexistent software private key.
Verify the move and diagnose failures
Run the test from the same shell, operating system environment, and user account that will run Git or SSH day to day. A successful file copy alone does not prove that authentication is configured.
| Symptom | Likely cause | Check or fix |
|---|---|---|
Permission denied (publickey) |
The wrong key was offered, the public key is not registered, or the server rejected the account. | Run ssh-add -l, load the intended private key, confirm the matching public key is on the service or in authorized_keys, and verify the username and host. |
| SSH says the private key is too open | Unix permissions or Windows ACLs allow other users to read the file. | Use chmod 600 on Unix-like systems or restrict the Windows file’s Security and Advanced permissions to the intended account. |
| The key is not found | SSH is using a different home directory, WSL profile, filename, or configuration. | Check the path, run ssh-add /path/to/private-key, and inspect the relevant IdentityFile entry. |
| The agent list is empty | No agent is running in the current session, or the key was loaded into another agent. | Start the appropriate agent, run ssh-add again, and repeat ssh-add -l in the failing terminal. |
| Authentication works for one host but not another | Each host has its own registered public key, account, alias, or policy. | Test the exact hostname and account, then add the matching public key to that host or select it with IdentityFile. |
| SSH asks for a key after copying it | Copying files does not load the private key into the active agent, and a passphrase-protected key still needs to be unlocked once. | Run ssh-add /path/to/private-key; if necessary, start the agent first and verify with ssh-add -l. |
For more detail, run a connection with verbose diagnostics, for example ssh -vT [email protected]. Read which configuration file, identity file, and agent identities the client actually uses. Do not paste verbose output publicly without reviewing it for hostnames, usernames, and other identifying information.
Secure the old computer and backups after the move
A copied key remains valid on the old computer. If you are retiring that machine, remove the private key only after confirming that the new computer works and that you have a deliberate backup strategy. Keep any backup encrypted and limit access to it.
If the old computer or a removable copy is lost, assume the private key may be compromised. Generate a new ED25519 key, register its public half everywhere it is needed, remove the old public key from each service and server, and update any automated jobs that referenced the old filename. A key cannot be revoked by deleting the local file alone; trust is controlled by the public-key registrations on the hosts you access.
Quick Recap
A practical decision checklist
- Identify the exact private/public pair and any relevant
configfile. - Choose copying for continuity or a new ED25519 key for per-device isolation.
- Use an encrypted USB drive, encrypted vault, or encrypted SSH transfer; never use email, chat, or unencrypted sync.
- Place the files in the home directory of the environment that actually runs SSH.
- Restrict the private key with
chmod 600on macOS, Linux, or WSL, or equivalent Windows ACLs. - Start the correct agent and load the private key with
ssh-add. - Verify with
ssh-add -land the target host’s current SSH test. - For a regenerated key, register only the complete public-key line and remove the old registration when appropriate.
- For FIDO2-backed keys, reconnect and import the authenticator identity instead of copying a private file.
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.
