The Problem: SSH Explained Badly on the Internet

Most SSH guides say "generate a key and copy it to the server" without explaining what actually goes where or why. This leads to common misconceptions:
  • That the private key is ever copied to the server (it is not)
  • That permissions are optional (they are not)
  • That SSH keys are magic rather than basic cryptography
Let’s fix that properly.

How SSH Key Authentication Actually Works

Private Key (Stays on the Client)

The private key lives only on the machine you use to connect from. It is never copied anywhere. It proves your identity by signing a challenge from the server.

Public Key (Lives on the Server)

The public key is placed on the server inside the user's ~/.ssh/authorized_keys file. The server uses it to verify that the connecting client owns the matching private key.

Important Rule

If someone gets your private key, they can log in as you. If someone gets your public key, nothing happens.

Step 1: Generate an SSH Key on Linux (Client Side)

ssh-keygen -t ed25519 -C "your_email@example.com"
When prompted:
  • Accept the default file location
  • Use a passphrase unless the key is for automation
This creates:
  • ~/.ssh/id_ed25519 -> private key
  • ~/.ssh/id_ed25519.pub -> public key

Step 2: Copy the Public Key to the Server

Using ssh-copy-id (Recommended and easiest)

ssh-copy-id user@server_ip
This appends your public key to: 
/home/user/.ssh/authorized_keys
You can always verify this by doing cat ~/.ssh/authorized_keys

Manual Method (If ssh-copy-id Is Not Available)

On the client: 
cat ~/.ssh/id_ed25519.pub
On the server: 

mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys
Paste the public key as a single line.

Step 3: Set Correct Permissions

On the Server


chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Meaning:
  • 700 -> rwx------ (only the user can access)
  • 600 -> rw------- (read/write for user only)
If these permissions are wrong, SSH will silently ignore the keys.

On the Client (Private Key)


chmod 600 ~/.ssh/id_ed25519
SSH refuses to use private keys that are accessible by others.

Step 4: Test Key-Based Login

ssh user@server_ip
If configured correctly:
  • No password prompt (or only passphrase)
  • Login succeeds immediately

Optional but Recommended: Disable Password Authentication

Once key login works, disable passwords to prevent brute-force attacks. 
sudo nano /etc/ssh/sshd_config
Set: 
PasswordAuthentication no
PubkeyAuthentication yes
Then reload SSH: 
sudo systemctl reload sshd

Why This Setup Is Correct

  • The private key never leaves your machine
  • The server only stores public material
  • Permissions prevent SSH from trusting unsafe files
  • Authentication is cryptographic, not secret-based

Access Control: Why the Server Owns Authorization

With SSH key authentication, the server decides who is allowed to log in. It does this by controlling the contents of authorized_keys. Each public key represents one client or device. Removing a single line immediately revokes access for that client. This is intentional:
  • The server never needs private material
  • Access can be granted and revoked centrally
  • Compromised clients can be locked out without changing anything else
If this were done the other way around (the server holding private keys), anyone with a copy of that key would permanently own access. The server would have no way to distinguish or revoke individual clients. Public keys on the server is not a convenience choice. It is the security model.