Connecting to a Server with an SSH Key (Windows, Mac, Linux)

An SSH key lets you connect to a server with a cryptographic key pair instead of a password. Passwords are guessable and open to brute force; an SSH key is practically unbreakable. This guide covers generating a key pair, adding it to the server and disabling password login, for Windows, macOS and Linux.

How does an SSH key work?

You have a key pair:

Private key (id_ed25519) — stays with you, never shared
Public key (id_ed25519.pub) — copied to the server

When you connect, the server sends a "challenge" using the public key; you sign it with the private key. The private key never leaves your computer.

1. Generate a key pair

Terminal (macOS/Linux) or PowerShell (Windows 10+):

ssh-keygen -t ed25519 -C "yourname@computer"

File location: press Enter (default ~/.ssh/id_ed25519).
Passphrase: a password protecting the private key. Strongly recommended — if your computer is stolen, the key is still safe.

ed25519 is modern and secure. If you are dealing with a very old system, use -t rsa -b 4096.

2. Add the public key to the server

Easy way (macOS / Linux)

ssh-copy-id user@SERVER_IP

Asks for the password once, then adds the key.

Windows / no ssh-copy-id

Display the public key and copy it:

# Windows PowerShell
Get-Content ~/.ssh/id_ed25519.pub
# macOS / Linux
cat ~/.ssh/id_ed25519.pub

Connect to the server and add it:

ssh user@SERVER_IP
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA... yourname@computer" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

If the server asks for a key at first setup

Many providers let you paste your public key while creating the server. This is the cleanest way — the server comes up passwordless directly.

3. Test the connection

ssh user@SERVER_IP

If you can log in without being asked for a password (or only for the key passphrase), it works.

Do this step only after you are sure key login works. Otherwise you can lock yourself out of the server.

sudo nano /etc/ssh/sshd_config

Set these lines:

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

sudo systemctl restart ssh

Now only computers that have the key can connect to the server.

Multiple computers / a team

Each person/computer should have its own key pair. You add their public keys to ~/.ssh/authorized_keys as separate lines. To revoke someone's access, deleting that line is enough.

SSH config file (convenience)

Get rid of long commands with ~/.ssh/config:

Host arcnar-web
    HostName 203.0.113.10
    User arcnar
    IdentityFile ~/.ssh/id_ed25519

Now you only need to type ssh arcnar-web.

Common errors

"Permission denied (publickey)": the public key is not on the server, is on the wrong user, or the authorized_keys / .ssh permissions are wrong (must be 700 and 600).
Still asks for a password: run ssh -v user@ip for verbose output; it shows which key is being tried.
Key not found on Windows: make sure the OpenSSH client is installed (Settings → Optional Features).

At Arcnar: You can add your SSH public key while creating a Compute plan; the server comes up passwordless, ready with the key. The panel console gives recovery access if you have key problems.

Frequently asked questions

Why is an SSH key more secure than password login?

Passwords are guessable and open to brute-force attempts. An SSH key is a 256-bit cryptographic pair; it cannot be cracked by trial in practice. The private key never leaves your computer — only the public key is copied to the server.

Which key type should I choose: ed25519 or RSA?

ed25519 is modern, fast and secure; it is the default choice for new setups (ssh-keygen -t ed25519). Only use RSA 4096-bit (-t rsa -b 4096) if a very old server does not support ed25519.

Should I set a passphrase for my private key?

Yes, strongly recommended. The passphrase prevents the private key from being used if your computer or disk is stolen. Thanks to ssh-agent you only enter the passphrase once per session.

The SSH key is added but the server still asks for a password, why?

Usually a permissions issue: on the server, ~/.ssh must be 700, ~/.ssh/authorized_keys must be 600, and it must be in the correct user's home directory. The command `ssh -v user@ip` shows which key is being tried and why it was rejected.