SSH Remote Access & Keys

You've built services that run on your own machine. But production runs on servers you've never touched — and that's exactly where the pain starts. Typing passwords for every login is slow, insecure, and breaks the moment you need to automate a deploy or a backup job. This lesson solves that pain by teaching you how to use SSH for remote access and keys, so you can log in to any Linux server securely, set up passwordless authentication, and unlock smooth automation.

The problem this lesson solves

Imagine you're on call at 3 AM. A service is down, and you need to SSH into a production server to check logs. You type your password, get in, fix the issue, and log out. Fine — once.

Now multiply that by: five servers, daily deploy scripts, SCP transfers, and a colleague who needs temporary access. Password-based SSH quickly becomes a nightmare:

• Passwords get reused across servers and services, so one leak compromises everything.
• Scripts can't use passwords — automation requires non-interactive login.
• Brute-force attacks hammer exposed SSH ports with password guesses 24/7.
• Every manual login breaks flow — you lose context and time.

The world moved to public-key cryptography a long time ago. When you use SSH for remote access and keys, you replace the password with a cryptographically strong key pair. Your private key stays on your machine; the public key lives on the server. No password is ever transmitted — and that changes everything.

Core concept / mental model

Think of SSH keys as a lock and key pair that only you own.

• The private key is your physical house key. It never leaves your pocket.
• The public key is like a lock that you give to the server's door. Anyone can install that lock, but only your private key can open it.

SSH uses asymmetric encryption: a public key encrypts, a private key decrypts. When you connect, the server challenges your client to prove it holds the private key that matches the public key on file. The private key is never sent over the network — only a proof that you possess it.

This mental model covers three key facts:

1. Key pair: ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public).
2. Key placement: public key goes to ~/.ssh/authorized_keys on the server.
3. Trust model: anyone with the private key can log in; losing it means losing access.

💡 Pro tip: Use Ed25519 keys instead of RSA. They're faster, smaller, and cryptographically stronger for the same security level. Modern OpenSSH supports them by default.

How it works step by step

Here's the sequence of events when you use SSH for remote access and keys — from key generation to secure login.

Step 1 — Generate a key pair on your local machine

Open a terminal on your laptop or workstation and run:

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

What happens:

• You're asked for a file location (default ~/.ssh/id_ed25519).
• You're asked for a passphrase — an extra password that protects the private key at rest.
• Two files appear: id_ed25519 (private) and id_ed25519.pub (public).

Step 2 — Copy the public key to the server

Use ssh-copy-id to install your public key on the remote server's authorized_keys file:

ssh-copy-id user@server.example.com

This command asks for your existing password once, then appends your public key to ~/.ssh/authorized_keys on the server.

Step 3 — Connect without a password

Now you can log in simply with:

ssh user@server.example.com

If you set a passphrase, you'll be asked for that (not the server password) — or use an SSH agent to cache it.

Step 4 — Start the agent and add your key (optional)

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

The agent holds your private key in memory, so you don't retype your passphrase on every connection.

Hands-on walkthrough

Let's put this into practice. We'll generate keys, push them to a remote server, and confirm passwordless login — using only commands you'll use every day.

Example 1 — Generate and inspect your key pair

# Generate an Ed25519 key pair with a comment
ssh-keygen -t ed25519 -C "you@example.com" -f ~/.ssh/id_ed25519

# Show the public key (this is what you'll share)
cat ~/.ssh/id_ed25519.pub

Expected output (public key format):

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExamplePublicKey you@example.com

Example 2 — Copy the key to a remote server

# Install your public key on the server (will ask for your password once)
ssh-copy-id user@server.example.com

# Now connect — no password prompt
ssh user@server.example.com

If everything is set up, you'll drop straight into a remote shell.

Example 3 — Run a command without an interactive session

# Run a single command remotely
ssh user@server.example.com "uptime"

# Copy a file securely
scp ./deploy.tar.gz user@server.example.com:/var/www/

Output:

 10:32:45 up 3 days,  2:11,  1 user,  load average: 0.08, 0.03, 0.01

💡 Pro tip: Use ssh -o PasswordAuthentication=no during testing to force key-based auth and catch misconfigurations early.

Compare options / when to choose what

Not all SSH auth methods are equal. Here's a quick comparison for typical DevOps scenarios.

When to choose what:

• Use keys with passphrase for your personal admin logins.
• Use keys without passphrase (or with a dedicated deploy key) for automated jobs — but protect the private key file with restrictive permissions (chmod 600).
• If your organization issues SSH certificates, use those over raw keys for central revocation.

Troubleshooting & edge cases

Even with keys, things can go wrong. Here are the most common issues and how to fix them.

1. "Permission denied (publickey)" even though you added the key

Causes and fixes: - Wrong file permissions on the server: ~/.ssh must be 700, authorized_keys must be 600. bash chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys - SELinux blocking access on some distributions: check restorecon -Rv ~/.ssh. - Key not in the right file: ensure your public key is in the correct user's ~/.ssh/authorized_keys.

2. "Host key verification failed"

This happens when the server's host key changes (often after a reimage). Fix by removing the old entry:

ssh-keygen -R server.example.com

Then reconnect and accept the new host key.

3. Key works from your laptop but not from a script

• The SSH agent isn't running in the script's environment. Start it explicitly or use ssh-agent bash.
• The private key path isn't the default ~/.ssh/id_ed25519. Specify with -i /path/to/key.

4. Passwordless login stops working after a password change

Check that /etc/ssh/sshd_config on the server still has PubkeyAuthentication yes and that the key file hasn't been overwritten.

💡 Pro tip: Always keep a second terminal session open to a server when you change SSH config — that way you can't lock yourself out permanently.

What you learned & what's next

You now understand the core of using SSH for remote access and keys:

• The pain of password-based SSH and why keys are the standard.
• The mental model of public/private key pairs.
• How to generate, deploy, and use SSH keys step by step.
• How to compare auth methods and pick the right one.
• How to troubleshoot common key-based auth failures.

You applied it in a hands-on walkthrough — generating keys, copying them to a server, and running remote commands without a password. This is the foundation for every automation you'll ever write.

What's next: In the next lesson, you'll learn how to secure and modernize remote access — things like disabling password auth entirely, using SSH certificates for team access, and auditing SSH logs. That's where telemetry meets security and you'll see why SSH keys matter even more at scale.