LLamjinLab
Net BasicsWords 938Read time≈ 3 min

SSH Keys for Beginners: What Public Keys, Private Keys, and config Actually Do

A beginner's guide explaining the differences between SSH public keys, private keys, passphrases, and host keys, using dedicated keypairs and SSH config to simplify VPS logins.

VPSLinuxSSHServers

In the previous lesson, we connected to our VPS using SSH. While password authentication is intuitive, it is vulnerable to weak passwords, credential reuse, and brute-force attacks. The standard production approach is using SSH key-based authentication.

Encountering "public keys, private keys, and host keys" can be confusing. Remember this foundational distinction: **User keys prove *who you are*; host keys verify *which server you are talking to*.** They serve completely different roles.

1. How Public and Private Keys Work Together

Think of an SSH keypair as a physical lock and key:

FileLocationCan It Be Shared?Purpose
Private KeyYour local computerNEVERProves the client possesses the authentic credential
Public Key (typically .pub)Installed on the serverYESInforms the server which private key is allowed in
Key PassphraseMemorized or in system KeychainNEVERProtects the private key file if your device is compromised

The server stores your public key; it never needs your private key. During login, cryptographic challenge-response authentication verifies your possession of the private key without transmitting it across the network.

Whenever a tutorial instructs you to "upload your private key to the server," halt and re-evaluate. Private keys must never be committed to public Git repos, blog screenshots, chat logs, or cloud storage links.

2. Generating a Dedicated Keypair for Learning

On your local Mac or Linux machine, generate a modern, standalone Ed25519 keypair:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_vps_learning -C "vps-learning"

Command breakdown:

  • -t ed25519: Specifies the modern, high-security Ed25519 cryptographic algorithm;
  • -f: Sets a distinct file path to avoid accidentally overwriting existing keys;
  • -C: Appends a descriptive comment for easy identification.

When prompted, enter a strong passphrase. For daily workstations, passphrases add defense-in-depth against local credential theft; using your system Keychain or ssh-agent prevents having to type the passphrase repeatedly.

This creates two distinct files:

~/.ssh/id_ed25519_vps_learning       Private key (NEVER share)
~/.ssh/id_ed25519_vps_learning.pub   Public key (Installed on servers)

3. Installing the Public Key on the Server

The cleanest method is pasting your .pub file contents into your provider's management console during VPS provisioning. If you already have working password access, utilities like ssh-copy-id can automate this, though macOS does not bundle it by default.

Under the hood, all methods simply append your public key string to:

~/.ssh/authorized_keys

SSH enforces strict filesystem permissions. Standard requirements require ~/.ssh to be accessible only by the owner (chmod 700) and authorized_keys to be writable only by the owner (chmod 600). If permissions are too permissive, the SSH daemon will refuse key authentication for safety.

Ensure three things:

1. The public key is installed under the correct Linux user account; 2. You copied the .pub file content, NOT the private key; 3. Key-based authentication is verified in a second terminal window before disabling password authentication.

4. Simplifying Connections with SSH Config

Typing long commands like ssh -i ~/.ssh/id_ed25519_vps_learning admin@203.0.113.10 each time is tedious.

Create or edit your local ~/.ssh/config file to define an alias:

Host learning-vps
  HostName 203.0.113.10
  User admin
  Port 22
  IdentityFile ~/.ssh/id_ed25519_vps_learning
  IdentitiesOnly yes

Now connect with:

ssh learning-vps

Host is your local shorthand alias; HostName is the actual IP or domain. IdentitiesOnly yes ensures SSH offers only the specified identity file, preventing authentication failures caused by offering too many keys.

The example IP 203.0.113.10 is an RFC 5737 reserved address. Replace it with your actual VPS IP, but avoid sharing your config with real IPs and usernames publicly.

5. Do Not Conflate User Keys and Host Keys

TypeWho Holds the Secret?Question Answered
User KeyThe client user"Does this user have permission to log in?"
Host KeyThe SSH server daemon"Am I connecting to the authentic, expected server?"

The SHA256 fingerprint displayed on your initial connection belongs to the server's host key. It should be validated against the hosting provider's dashboard. If a host key fingerprint suddenly changes in the future, investigate before deleting known_hosts entries.

6. Safe Transition Sequence

When migrating from password login to key authentication:

1. Verify web console rescue access works; 2. Create a standard administrative user and install the public key; 3. Keep your active session open, and test key login from a second terminal window; 4. Confirm the new user has working sudo privileges; 5. Assess whether to disable root login and password authentication in sshd_config; 6. Test every configuration change in a fresh session while observing authentication logs.

Avoid changing ports, firewalls, user accounts, and authentication methods simultaneously. Keeping an open session guarantees you maintain an instant recovery path if something misbehaves.

7. Key Maintenance Best Practices

  • Use dedicated, descriptive keys per workstation and workload;
  • Revoke public keys from authorized_keys when devices are retired or team members leave;
  • If private key compromise is suspected, generate a replacement, install the new public key, and immediately remove the old one;
  • Encrypt local private key backups and test restoration;
  • Remember that "keys do not expire automatically" does not mean they should never be rotated.

8. Summary

SSH keys are not simply longer passwords. They mathematically separate the public lock (.pub) from the private secret key. The ~/.ssh/config file structures connection metadata cleanly.

A secure transition requires two prerequisites: your private key never leaves your local machine, and your new login workflow is verified in an independent session before closing existing access.

Frequently Asked Questions

Is it safe to share .pub files?

Public keys are designed to be distributed, but should only be installed on systems you trust and need access to. Private keys must never be shared under any circumstance.

How do automated scripts connect if the private key has a passphrase?

Use dedicated restricted keys, ssh-agent, short-lived tokens, or secret management infrastructure. Avoid distributing unencrypted high-privilege private keys across multiple systems.

Should password authentication be disabled entirely?

It is recommended once you confirm SSH keys, sudo access, and web rescue consoles operate reliably. Avoid disabling passwords based solely on copy-pasted commands without verification.

Sources

Share

Share this article