Create SSH Keys with OpenSSH on macOS, Linux, or Windows

When setting up a remote Linux server, you need a secure way to connect to it. Passwords work but are vulnerable to brute force and phishing. Secure Shell keys (SSH keys) provide a stronger method: they use public-key cryptography so the server can verify your identity without sending a secret over the network. As part of the Secure Shell protocol, SSH keys also let you run network services securely over an unsecured network, such as running commands on a remote server or managing its services.

This tutorial walks you through creating SSH keys with OpenSSH (a standard suite of open-source SSH tools) on macOS, Linux, and Windows via the Windows Subsystem for Linux (WSL). It is aimed at readers new to the command line and includes how to open a terminal, generate keys, set permissions, use the SSH agent, and copy your key to a server. When you are done, you will have SSH keys you can use for the tutorial How To Set Up an Ubuntu Server on a DigitalOcean Droplet in the Introduction to the Cloud Curriculum.

If you already use the command line and want to connect to a remote server with SSH, see our collection Setting Up SSH Keys for various Linux systems.

• SSH keys are pairs of cryptographic keys (public and private) used to authenticate to servers securely, replacing passwords for login.
• Ed25519 is the recommended key type for new keys: it uses elliptic curve cryptography, is fast, secure, and widely supported in modern OpenSSH.
• Key storage and permissions: By default, keys are stored in the ~/.ssh directory (examples: id_ed25519 and id_ed25519.pub). The ~/.ssh directory should have permissions 700, and the private key file should have permissions 600.
• Passphrase protection: Setting a passphrase encrypts your private key on disk. You can enter it once per session by adding your key to the ssh-agent.
• Key-based login: To log in with keys, copy your public key to the remote server (using tools like ssh-copy-id). Never copy your private key to another machine.

To complete this tutorial, you will need:

• A local machine running macOS, Linux, or Windows with the Windows Subsystem for Linux (WSL) installed. For Windows, see Microsoft’s WSL installation documentation. OpenSSH works across many Linux distributions; this tutorial was tested on Ubuntu.

• Some experience with a terminal and the command line. For an introduction, see A Linux Command Line Primer.

SSH keys are two linked cryptographic values: a private key kept only on your machine, and a public key copied to any server you want to access. For new keys, use Ed25519 — it is the recommended algorithm in modern OpenSSH, faster than RSA, and produces shorter keys at equivalent security.

When you connect with SSH, the server uses your public key to encrypt a challenge that only your private key can answer. If your client answers correctly, the server grants access without a password. After that, you get a shell and can run commands on the remote server.

A terminal lets you run text-based commands instead of using the graphical interface. How you open it depends on your OS:

• macOS: Open Terminal from Applications → Utilities, or search for “Terminal” in Spotlight.
• Linux: Find your distribution’s terminal under Applications → Utilities or Accessories, or search for “terminal” in your desktop search.
• Windows (WSL): Launch your Linux distribution (for example, Ubuntu) from the Start menu. You get a Linux shell with the same paths and permissions as a native Linux environment. See How To Set Up SSH Keys on Ubuntu for WSL-specific context.

Once your terminal is open, confirm that OpenSSH is installed by checking the version:

ssh -V

You should see output similar to:

OpenSSH_9.x, OpenSSL 3.x.x

The exact version numbers will vary. Any output here confirms OpenSSH is available. If the command returns command not found, install OpenSSH using your distribution’s package manager (for example, sudo apt install openssh-client on Ubuntu).

Before generating a new key, check whether you already have one:

ls ~/.ssh

If you see files named id_ed25519 and id_ed25519.pub, you already have an Ed25519 key pair. You can use it as-is or generate a new one in Step 3 (with a different filename to avoid overwriting). If the directory does not exist or is empty, continue to Step 3.

macOS and most Linux installations include the OpenSSH tools. The ssh-keygen utility creates the key pair. Run the following command, substituting your own email address so the key comment helps you identify the key later:

ssh-keygen -t ed25519 -C "your_email@example.com"

Using -t ed25519 selects the Ed25519 algorithm. The -C value is a comment stored in the public key (often an email); it does not affect security.

You will be prompted for a save location. The default is ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public). Accepting the default lets the SSH client find your key automatically. Press ENTER to use the default:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/sammy/.ssh/id_ed25519):

If you accept the default, the private key is saved at ~/.ssh/id_ed25519 and the public key at ~/.ssh/id_ed25519.pub. On your system, sammy is replaced by your username.

Next, you will be prompted for an optional passphrase that encrypts the private key on disk. If you set one, you must enter it each time you use the key unless you add the key to ssh-agent (covered in Step 5). A passphrase adds protection if someone gains access to your machine. You can press ENTER twice to skip:

Created directory '/home/sammy/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

After the final prompt, the key pair is created. You should see output similar to:

Your identification has been saved in /home/sammy/.ssh/id_ed25519.
Your public key has been saved in /home/sammy/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:EXAMpl3+fingerprint+string+here your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
|     ..o         |
|   E o= .        |
|    o. o         |
|        ..       |
|      ..S        |
|     o o.        |
|   =o.+.         |
|. =++..          |
|o=++.            |
+----[SHA256]-----+

You now have a public and private key pair you can use for authentication.

Using RSA When Ed25519 Is Not Supported

If you need to connect to a server or tool that does not support Ed25519, generate an RSA key instead. RSA 4096-bit is a secure, widely compatible fallback:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Files are saved as ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. The rest of this tutorial applies the same way (use id_rsa and id_rsa.pub wherever id_ed25519 and id_ed25519.pub are mentioned).

OpenSSH requires strict permissions so other users on the same machine cannot read your private key. If permissions are too open, the client will ignore the key and may fall back to password authentication or fail.

• The ~/.ssh directory must be 700 (only you can read, write, and enter it).
• The private key file (e.g. id_ed25519 or id_rsa) must be 600 (only you can read and write).
• The public key file (e.g. id_ed25519.pub) can be 644; it is safe to share.

If you run ls -la ~/.ssh now, you may see more permissive modes (for example drwxr-xr-x for the directory or -rw-r--r-- for the private key). Those permissions are too open and need fixing.

Run these commands, adjusting the key name if you used RSA:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

To confirm:

ls -la ~/.ssh

You should see drwx------ for .ssh and -rw------- for the private key. If your output shows anything other than these (for example drwxr-xr-x or -rw-r--r--), the permissions need fixing; run the chmod commands above. If SSH ever reports “Permissions are too open” or “WARNING: UNPROTECTED PRIVATE KEY FILE,” fix the permissions the same way.

The SSH agent holds decrypted private keys in memory for the duration of your session. After you add a key and enter your passphrase once, the agent provides the key to SSH so you do not have to type the passphrase for each connection.

Check whether an agent is already running: run echo $SSH_AUTH_SOCK. If it prints a path (for example /tmp/... or similar), an agent is already active and you can skip to the ssh-add step below. If it prints nothing, start the agent with:

eval "$(ssh-agent -s)"

Expected output:

Agent pid 12345

Add your key (use id_ed25519 or id_rsa to match the key you generated):

ssh-add ~/.ssh/id_ed25519

If the key has a passphrase, you will be prompted once. You should see:

Identity added: /home/sammy/.ssh/id_ed25519 (your_email@example.com)

Confirm the key is loaded:

ssh-add -l

Example output:

256 SHA256:EXAMpl3+fingerprint+string+here your_email@example.com (ED25519)

The agent holds keys only for the current session. On Linux, you will need to run ssh-add again after each reboot or new login session.

On macOS, you can persist the key across reboots using the system Keychain. Run the following instead of the standard ssh-add command:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

On macOS versions before Ventura, use -K in place of --apple-use-keychain:

ssh-add -K ~/.ssh/id_ed25519

Once added with this flag, macOS stores the passphrase in Keychain and automatically loads the key into the agent when you open a new terminal session. You do not need to run ssh-add again after a reboot.

You must place your public key in the correct file on the server (usually ~/.ssh/authorized_keys in your home directory). The easiest way is ssh-copy-id, which appends your default public key to the remote user’s authorized_keys and sets safe permissions. For full server-side setup (creating ~/.ssh, setting permissions, enabling key auth), see How To Configure SSH Key-Based Authentication on a Linux Server.

Run (replace username with your remote user and 203.0.113.0 with the server’s IP or hostname):

ssh-copy-id username@203.0.113.0

If this is your first time connecting, you will see the host key verification prompt. Type yes and press ENTER. Then enter the remote user’s password once. Example output:

The authenticity of host '203.0.113.0 (203.0.113.0)' can't be established.
ED25519 key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
username@203.0.113.0's password:

Number of key(s) added: 1

After that, you can log in without a password:

ssh username@203.0.113.0

You should get a shell prompt without being asked for a password (unless your key has a passphrase and is not in the agent).

If you see Permission denied (publickey) instead of a shell prompt, the most common causes are: the public key was not written to ~/.ssh/authorized_keys on the server (re-run ssh-copy-id and check the output), or the server’s SSH configuration has PubkeyAuthentication no set in /etc/ssh/sshd_config. To diagnose which key is being offered and whether it is accepted, run:

ssh -v username@203.0.113.0

Look for lines beginning with debug1: Offering public key and debug1: Server accepts key in the verbose output. If no key is offered, confirm the key is loaded with ssh-add -l.

What is an SSH key?

An SSH key is a pair of cryptographic keys (a public key and a private key) used to authenticate you to a remote server over the Secure Shell protocol. The private key stays on your machine; the public key is placed on the server. The server uses the public key to verify that your client holds the matching private key, so you can log in without typing a password.

How do I create an SSH key with OpenSSH?

Run ssh-keygen -t ed25519 -C "your_email@example.com" in a terminal. Accept the default file location (~/.ssh/id_ed25519) and optionally set a passphrase. Your public key is in ~/.ssh/id_ed25519.pub and the private key in ~/.ssh/id_ed25519. Ensure ~/.ssh is 700 and the private key is 600.

What is the best SSH key type?

For new keys, Ed25519 is the best default: it is secure, fast, and supported by modern OpenSSH (7.0+). Use RSA 4096 when you need maximum compatibility with older servers or tools that do not support Ed25519.

Where are SSH keys stored?

By default, OpenSSH stores keys in the ~/.ssh directory. Ed25519 keys are typically ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public). RSA keys are ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. The ~ expands to your home directory (e.g. /home/username on Linux, /Users/username on macOS).

How do I copy my SSH key to a server?

Use ssh-copy-id username@host. It appends your default public key to the remote user’s ~/.ssh/authorized_keys. You need the remote account password once. Alternatively, you can manually append the contents of ~/.ssh/id_ed25519.pub (or id_rsa.pub) to ~/.ssh/authorized_keys on the server.

Do SSH keys replace passwords?

For SSH login, yes: once your public key is in the server’s authorized_keys, you authenticate with the key (and optionally a key passphrase) instead of the account password. You can disable password logins for that account or server to reduce brute-force risk. SSH keys do not replace passwords for other services (e.g. sudo, databases, web apps) unless those services are configured to use the same or additional authentication.

Can I use the same SSH key on multiple servers?

Yes. You can copy the same public key to many servers; each server only needs your public key in its authorized_keys file. Using one key is convenient but means compromise of that key affects every server that has it. In high-security or team environments, consider separate keys per role or service and rotate them periodically.

How do I check if my SSH key is working?

Run ssh username@host. If key-based auth is set up and your key is loaded (or you enter the key passphrase), you get a shell without a password prompt. You can run ssh -v username@host to see which key is offered and whether it is accepted. Use ssh-add -l to confirm your key is loaded in the agent.

You have generated an SSH key pair with OpenSSH, set permissions, optionally used the SSH agent, and copied your public key to a server. These keys are suitable for the next tutorial in the Introduction to the Cloud Curriculum, How To Set Up an Ubuntu Server on a DigitalOcean Droplet.

For more on using SSH in practice, see How To Use SSH to Connect to a Remote Server and SSH Essentials: Working With SSH Servers, Clients, and Keys.