What an SSH key is and why you need one

An SSH key is a pair of digital codes — one public, one private — that lets you log into a server or computer without typing a password. The public key lives on the server you want to access. The private key stays on your own computer. When you try to connect, the server checks that your private key matches the public key it has on file, and if they match, you're in.

SSH keys are more secure than passwords because they're much longer and harder to guess. They also let you automate tasks — scripts can use your key to log in without you typing anything. If you manage servers, use GitHub, or work with cloud services like AWS or DigitalOcean, you'll need an SSH key.

Key Takeaways

  • SSH keys come in a pair: a public key that goes on the server and a private key that stays on your computer and never leaves it.
  • On Windows, use PuTTYgen or the built-in ssh-keygen command in PowerShell; on Mac and Linux, use the terminal command ssh-keygen.
  • The private key file must have restricted permissions (chmod 600) so only you can read it, or SSH will refuse to use it.
  • After creating your key, you paste the public key into your server's authorized_keys file or upload it through your hosting provider's control panel.
  • Test the connection immediately after setup to confirm the key works before you disable password login.

Generate your SSH key on Mac or Linux

Open the terminal and run this command:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa

The command breaks down like this: ssh-keygen is the tool that creates the key, -t rsa specifies the type of encryption (RSA is standard and widely supported), -b 4096 makes the key 4096 bits long (longer keys are more secure), and -f ~/.ssh/id_rsa tells it where to save the key. The tilde (~) means your home directory, and .ssh is a hidden folder where SSH keys belong.

The terminal will ask you to enter a passphrase. This is optional but recommended — it's an extra password that protects your private key if someone gets access to your computer. Type a passphrase (or press Enter to skip), then type it again to confirm. When you're done, you'll have two files: id_rsa (your private key) and id_rsa.pub (your public key).

Generate your SSH key on Windows

Windows 10 and later have ssh-keygen built into PowerShell. Open PowerShell as an administrator and run the same command:

ssh-keygen -t rsa -b 4096 -f $env:USERPROFILE\.ssh\id_rsa

The command is identical except for the file path: $env:USERPROFILE\.ssh\id_rsa points to your Windows user folder instead of the Unix home directory. Follow the same steps as Mac and Linux — enter a passphrase when prompted, or press Enter to skip it.

If you're on an older version of Windows without ssh-keygen, download and install PuTTYgen instead. Open PuTTYgen, click "Generate", move your mouse around the window to create randomness, then click "Save private key" and "Save public key". PuTTYgen will create two files with .ppk and .pub extensions. The .pub file is what you upload to your server.

Set the correct permissions on your private key

On Mac and Linux, SSH will refuse to use your private key if other users on your computer can read it. After generating the key, run this command to lock it down:

chmod 600 ~/.ssh/id_rsa

This command means "let only the owner (you) read and write this file." If you skip this step, you'll get a "permissions are too open" error when you try to connect. You only need to run this once.

On Windows, permissions work differently and are usually set correctly by default. If you get a permissions error, right-click the private key file, select Properties, go to the Security tab, click Edit, select your username, and check "Full Control". Click Apply and OK.

Upload your public key to the server

Your public key (id_rsa.pub or the .pub file from PuTTYgen) needs to go on the server you want to access. There are two common ways to do this.

Method 1: Through your hosting provider's control panel. If you use DigitalOcean, AWS, Linode, or similar services, log into your account, find the SSH keys section, and paste the contents of your public key file. The provider will handle putting it in the right place. Open the public key file in a text editor, copy the entire contents (it's one long line starting with "ssh-rsa"), and paste it into the form.

Method 2: Manually on the server. If you already have password access to the server, log in and add your public key to the ~/.ssh/authorized_keys file. Open a terminal on the server and run:

nano ~/.ssh/authorized_keys

Paste your public key on a new line, save the file (Ctrl+O, Enter, Ctrl+X in nano), and exit. Make sure the .ssh folder has permissions 700 and authorized_keys has permissions 600:

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

Test your connection before disabling passwords

Before you lock down your server, test that the SSH key works. On Mac or Linux, run:

ssh -i ~/.ssh/id_rsa username@your.server.address

Replace username with your actual username on the server and your.server.address with the server's IP address or domain name. If you set a passphrase, you'll be asked for it. If the connection works, you're logged in.

On Windows with PuTTY, open PuTTY, enter the server address in the Host Name field, go to Connection > SSH > Auth in the left menu, click Browse under "Private key file for authentication", and select your .ppk file. Click Open to connect.

If the connection fails, check three things: the username is correct, the server address is correct, and the public key is actually in the authorized_keys file on the server. A common mistake is uploading the private key instead of the public key — never do this. The private key should never leave your computer.

Protect your private key and manage multiple keys

Your private key is like a master password. If someone gets it, they can log into any server where you've uploaded the matching public key. Keep it safe: back it up somewhere secure (encrypted external drive, password manager), never email it, and never paste it into a web form.

If you work with multiple servers or services, you can create separate keys for each one. Run ssh-keygen again with a different filename:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_github

Then tell SSH which key to use for which server by creating or editing ~/.ssh/config:

Host github.comIdentityFile ~/.ssh/id_rsa_github

This way, if one key is compromised, you only need to replace it on that one service. The rest of your access stays intact.

Frequently Asked Questions

What's the difference between the public and private key?

The public key is safe to share — you put it on servers and services. The private key must stay secret on your computer. Anyone with your private key can log in as you. Think of the public key as a lock and the private key as the only key that opens it.

Can I use the same SSH key for multiple servers?

Yes. You can upload the same public key to as many servers as you want. They'll all recognize your private key. This is convenient but means if your private key leaks, all those servers are at risk. Many people create separate keys for different purposes (work, personal, GitHub) to limit the damage if one key is compromised.

What if I lose my private key?

If you lose your private key file, you can't recover it. You'll need to generate a new key pair and upload the new public key to every server. This is why backing up your private key in a secure location is important. If you lose it and have no backup, you'll need to use password login or recovery methods to regain access.

Do I need a passphrase on my SSH key?

A passphrase adds security but isn't required. If someone steals your private key file, they can't use it without the passphrase. However, if you use the key in scripts or automated tasks, you'll need to enter the passphrase each time unless you use an SSH agent to cache it. For personal use, a passphrase is recommended.

Why does SSH say my key permissions are too open?

SSH requires your private key to be readable only by you. On Mac and Linux, run chmod 600 ~/.ssh/id_rsa. On Windows, right-click the key file, select Properties, go to Security, and make sure only your user account has Full Control. SSH will refuse to use the key otherwise for security reasons.