SSH keys on Linux: connect from your laptop to a server

An SSH key makes regular server work easier to manage. For my website, worldnode provides the concrete context: its checkout lives at /srv/www/dennishilk.github.io. A dedicated key and short host alias can simplify that daily connection.

This guide describes a general Linux/OpenSSH workflow. server.example.com and the client configuration below are examples to adapt. They do not claim to reproduce an existing SSH configuration on my server. You need a server account and an already authorized way to sign in.

Two keys with different responsibilities

ssh-keygen creates a key pair. The private half stays on the laptop. The public half, usually ending in .pub, can be installed for your account on the server.

During authentication, the server checks whether the client possesses the corresponding private key. You do not need to copy that private key to the server. A passphrase additionally protects the local key file; it is separate from the server account password.

Create a dedicated key

Create the local SSH directory if needed:

mkdir -p ~/.ssh

Check through a directory listing or file manager that the following name is unused. Choose a different name otherwise; do not overwrite an existing key.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_worldnode -C "laptop-worldnode"

Choose a passphrase in the interactive dialog. The comment is a readable label, not server authorization. It need not contain an email address. The private file and public .pub file are created separately.

Inspect the public key's fingerprint:

ssh-keygen -lf ~/.ssh/id_ed25519_worldnode.pub

This fingerprint identifies your user key. It is different from the server's host-key fingerprint checked next.

Verify the server before signing in

The first connection often reports an unknown host key. Compare its fingerprint through an already trusted route, such as the server console or established administrative documentation.

A hostname and plausible IP address do not establish identity by themselves. A changed host key also needs an explanation. A reinstalled server is one possible cause, rather than a reason to dismiss every warning or blindly remove the old entry.

Host verification establishes that you are talking to the intended server. The user key then answers a separate question: may you sign in to this account? Both checks belong in the workflow.

Transfer only the public key

Replace server.example.com with the actual server and nebu with your account if necessary:

ssh-copy-id -i ~/.ssh/id_ed25519_worldnode.pub nebu@server.example.com

The command needs a working existing login, often initially the account password. It installs the selected public key in the target account's authorized-key list. The private file is not transferred.

Test explicitly with the new key:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_worldnode nebu@server.example.com

A local passphrase prompt can be expected. Another server-password prompt may indicate a different authentication route. Check the connected account and host. Keep an established working login open until the new route succeeds.

Add a readable host alias

Back up an existing ~/.ssh/config, then add a suitable section with your editor. If Host worldnode already exists, update that section deliberately rather than add competing entries:

Host worldnode
    HostName server.example.com
    User nebu
    IdentityFile ~/.ssh/id_ed25519_worldnode
    IdentitiesOnly yes

Host is a local nickname; HostName is the actual destination. IdentityFile chooses the private key, and IdentitiesOnly limits offered identities. Adapt the domain, username and filename together.

Then connect with:

ssh worldnode

Inspect resolved client settings without signing in:

ssh -G worldnode

The output includes personal destination details; avoid sharing it wholesale without review.

Understand passphrases and the SSH agent

An SSH agent can retain an unlocked key during your session, avoiding a passphrase prompt at every connection. If your desktop already provides a reachable agent:

ssh-add ~/.ssh/id_ed25519_worldnode

Without an agent connection, the command fails. Setup depends on the desktop and shell; do not paste a Bash-specific agent startup into fish without adapting it. This guide does not require starting a new agent because the direct key command already works.

An agent does not replace proper protection of the private key. Keep unlocked sessions protected and never hand the private half to someone else.

Troubleshoot and undo deliberately

Key files and .ssh directories need appropriate owners and permissions. 700 for .ssh and 600 for private files are common restrictive local values. The server's own checks also influence whether authorized_keys is accepted.

If you later remove the exercise key, remove its particular public entry from authorized_keys after confirming another login works. Do not remove the entire file. Changing server authentication policy is outside this exercise.

References and the next server step

After signing in, update the website checkout deliberately. The Git article explains why local server commits sometimes require a rebase or merge.

• OpenSSH manuals.
• ssh-keygen and ssh_config.
• Debian's ssh-copy-id manual.

References checked on 8 October 2026. All server domains in the setup example are placeholders.