In this beginner-friendly lab, you will learn how to set up passwordless SSH authentication using cryptographic key pairs. You will generate your own public and private key pair, understand the difference between them, deploy your public key to a remote server, and establish a secure connection without ever typing a password. By the end of this lab, you will have mastered one of the most fundamental security skills in IT—the same technique used by system administrators, DevOps engineers, and cloud architects to securely access thousands of servers across enterprise environments.
Don't worry! This lab is designed for absolute beginners. We explain every command, what it does, and why we're using it. Take your time, read each step carefully, and you'll build a solid foundation in secure authentication.
Before we start generating keys, let's understand what SSH key authentication is and why it's more secure than passwords.
SSH (Secure Shell) is a protocol that lets you securely connect to another computer over a network. When you "SSH into a server," you're establishing an encrypted connection that protects all data traveling between your computer and the server.
Think of SSH like a secure phone call. Just as a phone encrypts your voice so others can't listen in, SSH encrypts your commands and data so hackers can't intercept them.
There are two main ways to prove your identity when connecting via SSH:
Password = Telling the doorman a secret word (someone could overhear it). Key = Having a unique physical key that only fits your lock (nearly impossible to duplicate without the original).
SSH key authentication uses asymmetric cryptography, which means you have TWO related keys:
Think of a padlock (public key) and its key (private key). You can give the open padlock to anyone—they can lock things for you. But only YOU have the key to unlock it. In SSH, the server has your "padlock" (public key) and uses it to create a challenge that only your "key" (private key) can solve.
| Factor | Password | SSH Key |
|---|---|---|
| Length | 8-20 characters typical | 2048-4096 bits (hundreds of characters) |
| Brute Force | Can be guessed in hours/days | Would take billions of years |
| Phishing Risk | Can be stolen by fake login pages | Private key never sent to server |
| Reuse Risk | People often reuse passwords | Unique key per device/purpose |
| Transmission | Sent over network (encrypted) | Never sent—only proof of ownership |
Congratulations! You've just started as a Junior Systems Administrator at CloudScale Inc. On your first day, the senior admin hands you a laptop and says: "Here's your workstation. You'll need to access 15 Linux servers for monitoring and maintenance. First thing—set up your SSH keys. We don't allow password authentication on any production server."
This is a real scenario that happens every day in IT departments worldwide. The skills you learn in this lab directly translate to:
Generate, store, and protect keys. Foundation for PKI, TLS certificates, and code signing.
Set correct permissions on sensitive files. Critical for passing security audits.
Connect to any Linux server securely. Required for every sysadmin and DevOps role.
Create shortcuts and tune settings. Improves daily productivity dramatically.
Understand why we protect private keys. Transfers to all security domains.
Debug "Permission denied" errors. Highly valued in support and operations roles.
Unlike Labs 1 and 2, this lab does NOT require any previous labs. You can start fresh! All you need is a computer with a terminal.
| Requirement | Options | Notes |
|---|---|---|
| Computer | Any modern computer | Windows, macOS, or Linux |
| Terminal Access | Built-in terminal | Windows: PowerShell or WSL macOS/Linux: Terminal app |
| Optional: Ubuntu VM | VirtualBox or VMware | For practicing SSH between machines |
If you want to practice SSH between two machines, set up an Ubuntu VM using either:
Refer to Lab 1 for detailed VM installation instructions if needed.
This diagram shows the relationship between your local machine, your key pair, and the remote server.
Stays on YOUR machine
NEVER share this
Used to prove identity
Copied to SERVER
Safe to share anywhere
Used to verify identity
Has private key
+ public key
Encrypted tunnel
Port 22
Has your public key
in authorized_keys
Your private key never leaves your computer. The server doesn't need your private key—it only needs your public key to create challenges. This is why key authentication is so secure!
Code blocks in this lab are tagged with badges indicating where to run commands:
First, open a terminal on your computer. The terminal is where you'll type commands to generate and manage SSH keys. Don't worry if you've never used a terminal before—just follow along and type exactly what's shown.
How to open the terminal:
Win + X, then click "Windows Terminal" or "PowerShell"Cmd + Space, type "Terminal", press EnterCtrl + Alt + T or search for "Terminal" in applicationsCheck that SSH client software is installed on your computer. Most modern operating systems include SSH by default. Run the following command to verify:
Local Machine
Expected output: Something like OpenSSH_8.9p1 or OpenSSH_9.0. The exact version doesn't matter—if you see a version number, SSH is installed!
Windows: SSH is included in Windows 10 (1809+) and Windows 11. If missing, enable it in Settings → Apps → Optional Features → Add a feature → OpenSSH Client.
macOS/Linux: SSH is pre-installed. If somehow missing, run sudo apt install openssh-client (Linux) or reinstall Command Line Tools (macOS).
Before generating new keys, let's check if you already have SSH keys. If you do, you might want to use them instead of creating new ones. Run this command to list any existing keys:
Local MachineIf you see files like:
id_rsa and id_rsa.pub — You have RSA keysid_ed25519 and id_ed25519.pub — You have Ed25519 keys (modern)No such file or directory — No keys yet, we'll create them!Now we'll create your personal SSH key pair. We'll use the Ed25519 algorithm, which is modern, secure, and creates smaller keys than the older RSA algorithm.
Run the following command to generate a new Ed25519 SSH key pair. The -C flag adds a comment (usually your email) to help identify the key later. Replace the email with your own.
You'll be prompted with three questions:
~/.ssh/id_ed25519)Yes, for maximum security! A passphrase encrypts your private key so that even if someone steals the file, they can't use it without the passphrase. Think of it as a password for your key.
For this lab, you can skip the passphrase (just press Enter) for simplicity. But in production, always use a strong passphrase!
After generating the keys, verify that both files were created successfully. You should see two new files in your .ssh directory.
Expected output: You should see:
id_ed25519 — Your private key (permissions should be -rw------- or 600)id_ed25519.pub — Your public key (permissions can be more open)
Let's look at your public key. This is the key you'll share with servers. It's a single long line of text that starts with ssh-ed25519.
Example output:
Your public key is designed to be shared. You can email it, paste it into websites (like GitHub), or add it to any server. It cannot be used to impersonate you—only your private key can do that.
Your private key is stored in ~/.ssh/id_ed25519 (no .pub extension). Let's verify its permissions are secure. The private key should only be readable by you (owner).
Expected output: -rw------- — This means only you (the owner) can read and write the file. No one else on the system can access it.
Your private key is like your house key. Never email it, paste it into websites, commit it to Git, or show it to anyone. If compromised, someone could access all servers that trust your public key.
Now that you have your key pair, you need to put your public key on the servers you want to access. There are several ways to do this.
The ssh-copy-id command automatically copies your public key to a remote server and sets up the correct permissions. This is the easiest method when you have password access to the server.
Replace username with your username on the remote server, and server-ip with the server's IP address or hostname.
Example: ssh-copy-id john@192.168.1.100
You'll be prompted for the server password (this is the last time you'll need it!). After success, you'll see:
If ssh-copy-id isn't available (common on Windows without WSL), you can manually copy your public key. First, display your public key and copy it to your clipboard:
Select and copy the entire output (one long line starting with ssh-ed25519).
Then, SSH into the server using password authentication:
Local MachineOnce logged into the server, add your public key to the authorized_keys file:
SSH Server
Replace PASTE_YOUR_PUBLIC_KEY_HERE with the public key you copied earlier.
Don't have a remote server? You can practice SSH key authentication by connecting to your own computer! First, ensure the SSH server is running on your machine:
Ubuntu VM or LinuxThen copy your key to localhost:
Ubuntu VM or LinuxEnter your user password when prompted. Now you can SSH to yourself without a password!
Now test your passwordless SSH connection! Connect to the server where you deployed your public key. If everything is set up correctly, you'll log in without being asked for a password.
Local MachineSuccess indicators:
If you're logged in without entering a password, you've successfully set up SSH key authentication! This is how professionals access servers securely.
If SSH isn't working as expected, use verbose mode to see exactly what's happening during the connection. The -v flag shows detailed debug information.
Look for lines containing:
Offering public key — SSH is trying your keyServer accepts key — Key authentication succeeded!Permission denied — Key rejected (check permissions)The SSH config file lets you create shortcuts for servers, specify which key to use, and customize connection settings. This makes your life much easier when managing multiple servers.
Create or edit the SSH configuration file in your .ssh directory. This file defines how SSH connects to different hosts.
Add configuration blocks for your servers. Here's an example:
Save the file: Press Ctrl + O, then Enter, then Ctrl + X to exit nano.
The SSH config file must have restrictive permissions to be used. Set the correct permissions:
Local MachineNow instead of typing the full SSH command with all options, you can simply use the shortcut name you defined:
Local MachineMuch simpler! The config file handles all the details for you.
SSH is very strict about file permissions. If permissions are too open, SSH will refuse to use your keys. Run this command to verify and fix permissions:
Local MachineCorrect permissions:
~/.ssh/ directory: drwx------ (700)id_ed25519 (private key): -rw------- (600)id_ed25519.pub (public key): -rw-r--r-- (644)config: -rw------- (600)authorized_keys: -rw------- (600)Cause: Server doesn't have your public key or permissions are wrong
Solutions:
~/.ssh/authorized_keysauthorized_keys permissions: chmod 600 ~/.ssh/authorized_keys.ssh directory permissions: chmod 700 ~/.sshssh -v to see which keys are being triedCause: Private key file permissions are too open
Solution: Fix permissions on your local machine:
Causes and solutions:
ssh -i ~/.ssh/id_ed25519 user@serverssh-copy-id/etc/ssh/sshd_configCause: SSH server not running or firewall blocking
Solutions:
sudo systemctl status sshsudo systemctl start sshsudo ufw allow 22If you want to start fresh or remove test keys, here's how to clean up. Be careful—deleting keys means losing access to any server that only has those public keys!
Local MachineContinue your SSH and cryptography learning journey with these resources:
git push without passwordsssh-agent to avoid re-entering passphrases/etc/ssh/sshd_config to disable password authentication