Skip to main content
DCHost / Practical guide

Create an SSH key and add it to your Linux server

By the end: You will have created a key pair, added its public key to your server account and tested it in a new connection. Keep the existing connection open until the test succeeds.

An SSH key pair contains a private key, which stays on your computer, and a public key, which you authorize on the server. The file ending in .pub is the public key. Never put the private key in a support ticket, email or the server's authorized_keys file.

Applies to: A standard OpenSSH user account on Ubuntu 24.04 LTS or Debian 13, and a Linux, macOS or Windows computer with an OpenSSH client. You must already be able to sign in to the server. If you have lost all access, start with SSH troubleshooting.

Visual guideTwo files, two different jobs

The .pub ending tells you which file can be authorized on the server.

  • Private key

    dchost_ed25519 stays on your computer. Never paste it on the server, into email or a support ticket.

  • Public key

    dchost_ed25519.pub is added to your server account to authorize sign-in with its matching key.

The key passphrase protects your private key; it is separate from the server account password.

Before you start​

Prepare two windows:

  1. Server window: Your existing SSH connection.
  2. Computer window: A new Terminal or PowerShell window on your computer.

Check which window each step requires. Generate the key on your computer; authorize its public part on the server.

Make an initial SSH connection and keep that server session open. Decide which account should use the key. On the server, whoami should show that account. This guide does not create an administrator account or modify SSH server settings.

Replace the example username, IP address and port with your details. Follow your organization's policy if it requires a different key type or cryptographic setup.

1. Create the key on your computer​

Use the computer window. Choose the block for your operating system; do not run both. Run its lines in order.

Command partMeaning
-t ed25519Selects the key type
-fSets the file path for the key
-C "dchost-access"Adds a label to help identify the key
~ or $env:USERPROFILEYour user folder on your computer

The first line prepares the folder. The second creates the key pair.

In Linux or macOS Terminal:

mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/dchost_ed25519 -C "dchost-access"

In Windows PowerShell:

New-Item -ItemType Directory -Force "$env:USERPROFILE\.ssh"
ssh-keygen -t ed25519 -f "$env:USERPROFILE\.ssh\dchost_ed25519" -C "dchost-access"

Enter a strong passphrase when prompted to protect the key. If a file with that name already exists, do not overwrite it: other services may depend on the existing key. Stop, choose a different filename and use that name throughout the remaining steps.

Expected result: If you kept the example name, two files are created: dchost_ed25519 and dchost_ed25519.pub. The passphrase protects your local private key; it is separate from the server account password.

2. Display only the public key​

Stay in the computer window. Run only the command for your operating system. Make sure the filename ends in .pub.

On Linux or macOS:

cat ~/.ssh/dchost_ed25519.pub

In Windows PowerShell:

Get-Content "$env:USERPROFILE\.ssh\dchost_ed25519.pub"

Copy the entire single line beginning with ssh-ed25519. Visual wrapping is normal, but do not insert actual line breaks inside the key. If you see BEGIN OPENSSH PRIVATE KEY, you opened the wrong file; do not share that content.

3. Add the public key to your server account​

Visual guideAuthorize the public key safely

Keep the old server session open until the new key has been tested.

  1. Copy the .pub line

    On your computer, copy the whole public key line beginning with ssh-ed25519.

  2. Add to the right account

    In the server window, append to authorized_keys while preserving existing keys.

  3. Test in a new window

    From your computer, test a separate key-only connection and verify the account.

If a private key is lost, add and test a replacement before removing the old public key.

Switch to the server window. First run whoami; it should show the account that will use the key. Here, ~ means that account's folder on the server.

The first five lines prepare the key folder and file with suitable permissions. authorized_keys lists the public keys allowed into this account.

In the existing server session, as the intended account, run these commands in order:

umask 077
mkdir -p ~/.ssh
touch ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
cat >> ~/.ssh/authorized_keys

The last command waits for text. A waiting cursor is normal:

  1. Press Enter first. This prevents joining an existing key that has no final newline.
  2. Paste the public key as one complete line.
  3. Press Enter again.
  4. On the empty line, press Ctrl+D.

>> appends while preserving existing keys. Do not use a single >; it replaces the list.

Do not run these steps with sudo against another user's home directory. If the server uses centralized identity management or a custom AuthorizedKeysFile, the standard path may not apply. Ask its administrator for the appropriate method.

Expected result: After Ctrl+D, the server prompt returns. The key has been added to the file; the next step tests whether it works for sign-in.

4. Test key access in a separate window​

Replace the example username, IP and port. If you chose another key filename, update the path after -i.

-i selects the private key file. IdentitiesOnly=yes limits other automatically offered keys.

Open a new window on your computer. On Linux or macOS:

ssh -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -i ~/.ssh/dchost_ed25519 -p 22 server_user@203.0.113.10

In Windows PowerShell:

ssh -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -i "$env:USERPROFILE\.ssh\dchost_ed25519" -p 22 server_user@203.0.113.10

For this test, PreferredAuthentications=publickey prevents a failed key attempt from falling back to the server account's password. Enter passphrase for key instead asks for the passphrase that unlocks your local key. Run whoami in the new session to verify the account. Close the older session only after this key-authenticated connection works.

If the server requires a password or second factor in addition to a key, a key-only test may not complete. Follow your organization's authentication procedure; do not disable the additional check just to pass this test.

Success check: If whoami in the new session shows the correct account, the key sign-in test is complete. Keep the old session open if the test fails.

Common errors and removing a key​

For Permission denied (publickey), check the username, selected private key and whether the public key was copied as one complete line. The target user must own .ssh and authorized_keys. Do not grant 777 permissions to fix an access issue.

This guide leaves password access, root access and firewall rules unchanged. Before changing them later, verify both a separate key-authenticated session and a recovery method you can actually use. To undo this key addition, use a working session to remove only the public key line you added; do not delete the entire authorized_keys file. If a private key is lost or exposed, authorize and test a replacement before removing the old public key.