SSH Key Setup: Passwordless, Secure Server Login

An SSH key lets you log in to a server with a cryptographic key pair instead of a password. Passwords are vulnerable to brute-force attacks, tedious to type every time, and hard to automate in scripts. Key-based authentication is both more secure and far more convenient: you set it up once, then sign in with a single command on every connection. In this guide you will learn, step by step, how to generate a key from scratch, install it on your server, and add the settings that make daily use effortless.

How an SSH key works

An SSH key consists of two files: a private key and a public key. The private key stays only on your computer and is never shared; the public key is copied to any server you want to log in to. When you connect, the server runs a challenge against the public key and only lets in a client that can prove it holds the matching private key. Thanks to this asymmetric approach, the private key never travels across the network.

• Private key: ~/.ssh/id_ed25519 — keep it secret, share it with no one.
• Public key: ~/.ssh/id_ed25519.pub — copy it freely to servers.

Generating the key pair

On modern systems the preferred algorithm is Ed25519: short, fast, and strong. Run this command in your terminal:

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

The -C flag adds a comment (usually an email) to the key, which makes it easier to tell multiple keys apart. The command asks for a save path and a passphrase. Press Enter to accept the default path (~/.ssh/id_ed25519). The passphrase encrypts your private key with an extra password; it protects the key if your computer is stolen, so leaving it empty is not recommended.

If your system does not support Ed25519 (very old servers), a 4096-bit RSA key is a safe alternative:

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

Installing the public key on the server

The most practical method is the ssh-copy-id tool. It adds your public key to the server's ~/.ssh/authorized_keys file with the correct permissions:

ssh-copy-id user@server-ip

This command asks for your password one last time; once it succeeds you log in with the key from then on. If ssh-copy-id is unavailable (for example on Windows or a restricted host), you can add the key manually:

cat ~/.ssh/id_ed25519.pub | ssh user@server-ip \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Permissions are critical: the ~/.ssh folder must be 700 and the authorized_keys file 600. Wrong permissions make SSH reject the key for security reasons and silently fall back to asking for a password.

Shortening connections with ~/.ssh/config

Instead of typing a long command every time, create a ~/.ssh/config file on your client and define an alias for the connection:

Host myserver
    HostName 46.202.156.61
    User user
    Port 22
    IdentityFile ~/.ssh/id_ed25519

After this definition, ssh myserver is enough; SSH automatically uses the right address, user, port, and key. This is especially handy with hosting providers that use a non-standard port (for example Port 65002).

Entering the passphrase once with ssh-agent

If you set a passphrase, you do not want to type it on every connection. ssh-agent keeps your key in memory for the session:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

On macOS you can store the key in the Keychain to make it persistent: ssh-add --apple-use-keychain ~/.ssh/id_ed25519. On Linux most desktop environments start the agent automatically at login, so running ssh-add once is enough.

Disabling password login and hardening security

Once you have verified that key login works, disabling password login entirely on the server greatly improves security. Edit /etc/ssh/sshd_config on the server:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

To apply the change, restart the SSH service: sudo systemctl restart ssh (on some distributions sshd). Important: before applying this setting, always confirm in a separate terminal that you can log in with the key; otherwise you may lock yourself out of the server.

Using the same key with services like GitHub

You can use the same SSH key with Git hosting services too. Copy the contents of your public key and paste it into the SSH keys section of your GitHub/GitLab settings:

cat ~/.ssh/id_ed25519.pub

Then test the connection with ssh -T git@github.com. This way git push and git pull work securely with the key, without asking for a password.

Frequently Asked Questions

What happens if I lose my private key?

If you have no backup of the private key, you must regain access to every server it logs into by generating and installing a new key. So back up your private key in a safe place and never paste it into a public repository or chat channel.

Can I log in to the same server from multiple computers?

Yes. It is best to generate a separate key on each computer and add each one's public key to the server's authorized_keys file. That way, if you lose a device you only delete its key and the others are unaffected.

Is leaving the passphrase empty safe?

Automated scripts and CI/CD environments may need a passphrase-less key, but on your personal machine you should always use one. A passphrase makes the private key unusable on its own even if the file falls into the wrong hands.

Want to set up your server securely and smoothly? If you need help with SSH hardening, deployment automation, or server management, get in touch with me.