This lab is organized into logical sections that build upon each other progressively. We begin with foundational concepts, move through hands-on implementation, and conclude with security hardening and professional resources. Each section includes detailed explanations, practical exercises, and real-world context to ensure you develop both theoretical understanding and practical skills.
In this beginner-friendly lab, you will learn how to set up passwordless SSH authentication using cryptographic key pairs. SSH (Secure Shell) is the standard protocol for securely accessing remote systems, and key-based authentication is the gold standard for security in enterprise environments. You will generate your own public and private key pair, understand the mathematical relationship between them, deploy your public key to a remote server, configure SSH for optimal usability, and establish secure connections 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, cloud architects, and security professionals to securely access thousands of servers across enterprise environments worldwide.
Don't worry! This lab is designed for absolute beginners. We explain every command in detail, what it does, why we're using it, and what output to expect. Take your time, read each step carefully, and don't hesitate to re-read sections if needed. Building a solid foundation in secure authentication will benefit your entire IT career. Remember: every expert was once a beginner.
By completing this lab, you will create a complete SSH authentication infrastructure including:
Upon completing this lab, you will be able to:
Before we start generating keys, it's essential to understand what SSH key authentication is, how it works, and why it's significantly more secure than password-based authentication. This conceptual foundation will help you make better security decisions throughout your career and troubleshoot issues more effectively. Cryptography can seem intimidating at first, but the core concepts are straightforward once explained properly. Let's break down these concepts using clear explanations and real-world analogies.
SSH (Secure Shell) is a cryptographic network protocol that provides secure communication between two computers over an untrusted network like the internet. When you "SSH into a server," you're establishing an encrypted tunnel that protects all data traveling between your computer and the server from eavesdropping, tampering, and interception. SSH was designed in 1995 to replace insecure protocols like Telnet and rlogin, which transmitted data (including passwords) in plain text. Today, SSH is used by millions of system administrators, developers, and security professionals daily.
Think of SSH like a secure phone call in a spy movie. Before discussing sensitive information, the spies use a special scrambling device that encrypts their voices. Even if someone taps the phone line, they only hear gibberish. Similarly, SSH encrypts everything you type and everything the server sends back, so even if a hacker intercepts the traffic, they can't understand it.
There are two main ways to prove your identity when connecting via SSH, and understanding the difference is crucial for making good security decisions:
Password authentication is like telling a doorman a secret word to enter a building. It works, but someone could overhear you, trick you into saying it (phishing), or try common words until they guess correctly (brute force). Key authentication is like having a unique physical key that only fits your lock. Even if someone watches you open the door, they can't duplicate the key just by observation. They would need the actual key, which never leaves your possession.
SSH key authentication uses asymmetric cryptography (also called public-key cryptography), which means you have TWO mathematically related but different keys:
Imagine a special padlock (public key) and its unique key (private key). You can manufacture thousands of identical padlocks and give them to anyone—they can all lock things intended for you. But only YOU have the key that opens these padlocks. In SSH, the server has your "padlock" (public key) and uses it to create a cryptographic challenge (locking a random message). Only your "key" (private key) can solve this challenge (unlock the message), proving you are who you claim to be.
The following comparison illustrates the dramatic security advantages of key-based authentication over passwords:
| Security Factor | Password | SSH Key |
|---|---|---|
| Entropy (Randomness) | 8-20 characters typical (40-100 bits) | 256+ bits (Ed25519) to 4096 bits (RSA) |
| Brute Force Resistance | Can be cracked in hours to days with modern hardware | Would take billions of years with all computers on Earth |
| Phishing Risk | High—fake login pages can steal passwords | None—private key is never transmitted |
| Reuse Risk | People often reuse passwords across services | Best practice: unique key per device/purpose |
| Network Transmission | Sent over network (encrypted, but still transmitted) | Never transmitted—only cryptographic proof |
| Keylogger Vulnerability | High—keyloggers capture every keystroke | Lower—key file itself must be stolen |
Understanding theory is important, but seeing how skills apply in actual work environments makes learning more meaningful and memorable. This section presents a realistic enterprise scenario that mirrors what you'll encounter in IT roles, followed by a detailed breakdown of how the skills from this lab translate to daily job tasks across various career paths.
Congratulations! You've just started as a Junior Systems Administrator at CloudScale Inc., a growing SaaS company with 200 employees and infrastructure spanning AWS, Azure, and an on-premises data center. On your first day, the senior admin hands you a company laptop and says:
"Here's your workstation. You'll need to access about 50 Linux servers for monitoring, maintenance, and deployments. First order of business—set up your SSH keys. We have a strict no-password policy on all servers. Password authentication is disabled company-wide because we had a security incident last year where an attacker brute-forced a weak password on a staging server."
This is a real scenario that happens every day in IT departments worldwide. Companies of all sizes have learned (often the hard way) that password-based SSH access is a significant security risk. The skills you learn in this lab directly translate to these job responsibilities:
Generate, store, protect, and rotate cryptographic keys. This foundational skill transfers directly to managing TLS/SSL certificates, GPG keys for code signing, encryption keys for data protection, and PKI infrastructure in enterprise environments.
Understand and set correct permissions on sensitive files using chmod. Critical for passing security audits, protecting configuration files, securing web applications, and maintaining principle of least privilege across systems.
Connect securely to any Linux/Unix server from anywhere in the world. This is the #1 daily task for system administrators, site reliability engineers, DevOps practitioners, and cloud engineers.
Create shortcuts, manage multiple identities, configure jump hosts, and tune connection settings. Dramatically improves daily productivity when managing dozens or hundreds of servers.
Develop habits around protecting secrets, verifying authenticity, and thinking like an attacker. This mindset transfers to all security domains: application security, network security, cloud security, and incident response.
Debug "Permission denied" errors, analyze verbose logs, and systematically identify root causes. Highly valued in support, operations, and engineering roles where problems must be solved under pressure.
One of the advantages of this lab is its accessibility—you don't need expensive hardware, complex software, or completion of previous labs. SSH clients are built into modern operating systems, and you can practice key authentication even without a remote server by connecting to your own machine. This section outlines everything you need to get started and provides options for different learning environments.
Unlike Labs 1 and 2, this lab does NOT require any previous labs to be completed. You can start fresh with just a computer and a terminal! If you've already completed Lab 1 (LDAP) or Lab 2 (SAML), you can use your existing Ubuntu VM for this lab. If not, all exercises can be performed on your local machine or with a free cloud VM.
| Requirement | Options | Notes |
|---|---|---|
| Computer | Any modern computer (2015 or newer) | Windows 10/11, macOS 10.14+, or any Linux distribution |
| Terminal Access | Built-in terminal application | Windows: PowerShell, CMD, or Windows Terminal macOS: Terminal.app or iTerm2 Linux: GNOME Terminal, Konsole, or any terminal emulator |
| SSH Client | OpenSSH (usually pre-installed) | Windows 10 1809+ includes OpenSSH by default macOS and Linux include it in base install |
| Optional: Remote Server | Ubuntu VM, cloud instance, or Raspberry Pi | For practicing SSH between machines; you can use localhost for initial learning |
If you want to create a dedicated practice environment or simulate SSH between two machines, you can set up an Ubuntu VM using either:
Refer to Lab 1 for detailed VM installation instructions if you want to set up a dedicated Ubuntu VM.
This lab is designed for beginners, but having these foundational skills will help you progress faster:
Visual representations make complex concepts easier to understand. This section provides diagrams showing the relationship between your local machine, your key pair, and the remote server, followed by a step-by-step walkthrough of the authentication process. Understanding this flow will help you troubleshoot issues and appreciate why key authentication is so secure.
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 and is never transmitted over the network. The server doesn't need your private key—it only needs your public key to create challenges and verify responses. This is fundamentally different from password authentication, where the password (or a hash of it) must be sent to the server. With SSH keys, even if an attacker intercepts all network traffic, they cannot obtain your private key or replay the authentication.
Before diving into key generation, let's prepare your environment and verify that SSH is properly installed on your system. This section also introduces the device badge system used throughout the lab to clearly indicate where each command should be executed—an important distinction when working with multiple machines.
Throughout this lab, code blocks are tagged with badges indicating where to run commands. Pay attention to these badges—running a command on the wrong machine is a common source of confusion and errors:
The terminal (also called command line, console, or shell) is where you'll type commands to generate and manage SSH keys. If you've never used a terminal before, don't worry—it's simply a text-based way to interact with your computer that's more precise and powerful than clicking through menus. Every IT professional uses the terminal daily, so this is a valuable skill to develop.
How to open the terminal on your operating system:
Win + X, then click "Windows Terminal" or "PowerShell". Alternatively, press Win + R, type cmd or powershell, and press Enter.Cmd + Space to open Spotlight, type "Terminal", and press Enter. Or navigate to Applications → Utilities → Terminal.Ctrl + Alt + T (works on most distributions), or search for "Terminal" in your applications menu.Check that SSH client software is installed on your computer. Most modern operating systems include OpenSSH by default, but let's verify. Run the following command to check the SSH version. If you see a version number, SSH is ready to use.
Local Machine
Expected output: Something like OpenSSH_8.9p1, OpenSSH_9.0p1, or similar. The exact version doesn't matter for this lab—any version from the past 10 years will work. If you see a version number, you're ready to proceed!
Windows: SSH is included in Windows 10 version 1809 (October 2018) and later. If missing, go to Settings → Apps → Optional Features → Add a feature → search for "OpenSSH Client" → Install. Restart your terminal after installation.
macOS: SSH is always pre-installed. If you somehow get an error, reinstall Command Line Tools by running xcode-select --install in Terminal.
Linux: SSH client is almost always pre-installed. If missing, run sudo apt install openssh-client (Debian/Ubuntu) or sudo dnf install openssh-clients (Fedora/RHEL).
Before generating new keys, let's check if you already have SSH keys from previous work, school, or personal projects. If you do, you might want to use them instead of creating new ones. If you don't have any keys yet, that's perfectly fine—we'll create them in the next section.
Local MachineInterpreting the output:
id_rsa and id_rsa.pub — You have RSA keys (older but still secure with 4096 bits)id_ed25519 and id_ed25519.pub — You have Ed25519 keys (modern, recommended)id_ecdsa and id_ecdsa.pub — You have ECDSA keys (another modern option)No such file or directory — No keys exist yet; we'll create them!Key generation is the foundation of SSH security. In this section, you will create your personal cryptographic key pair using the Ed25519 algorithm, which is the current industry recommendation for new keys. Ed25519 provides excellent security (equivalent to RSA-3072) with smaller key sizes and faster performance. Understanding the key generation process empowers you to make informed decisions about algorithm selection, key strength, and passphrase protection—choices you'll face throughout your career when setting up SSH access to cloud instances, Git repositories, and enterprise servers.
Run the following command to generate a new Ed25519 SSH key pair. The -t ed25519 flag specifies the algorithm type. The -C flag adds a comment (typically your email address) to help identify the key later—this is especially useful when you have keys on multiple devices or for different purposes.
You'll be prompted with three questions. Here's how to answer them:
~/.ssh/id_ed25519). Only change this if you have a specific reason, like maintaining separate keys for work and personal use.Yes, for maximum security! A passphrase encrypts your private key file using symmetric encryption. Even if someone steals the file, they cannot use it without knowing the passphrase. This protects you if your laptop is stolen, your backup drive is compromised, or malware copies files from your system.
For this lab: You can skip the passphrase (just press Enter twice) for simplicity while learning. However, develop the habit of using passphrases for any keys that access production systems or sensitive data.
Pro tip: Use a memorable sentence as your passphrase, like "My first car was a 1997 Honda Civic!" — long, easy to remember, hard to guess.
After generating the keys, verify that both files were created successfully. You should see two new files in your .ssh directory. Pay attention to the file permissions shown in the first column—they're important for security.
Expected output (look for these two files):
-rw------- id_ed25519 — Your private key (permissions should be 600, readable only by you)-rw-r--r-- id_ed25519.pub — Your public key (permissions can be more open, 644 is fine)
Let's look at your public key. This is the key you'll share with servers, GitHub, cloud providers, and colleagues. It's a single long line of text that starts with the algorithm name (ssh-ed25519) and ends with your comment (email). The middle section is the actual cryptographic key encoded in base64.
Your public key is designed to be distributed freely. You can email it, paste it into web forms (like GitHub's SSH key settings), post it on your website, or add it to any number of servers. It cannot be used to impersonate you or derive your private key. The mathematical relationship between public and private keys is "one-way"—easy to compute the public key from the private key, but computationally infeasible to reverse.
Your private key is stored in ~/.ssh/id_ed25519 (without the .pub extension). Let's verify that its permissions are secure. The private key file should only be readable by you (owner)—SSH will actually refuse to use a private key with overly permissive permissions as a security precaution.
Expected output: -rw------- — This permission string means only you (the owner) can read and write the file. No group members or other users on the system can access it. If you see different permissions, we'll fix them in the security section.
Your private key is the master key to your digital identity. Treat it like you would treat your house key, bank PIN, or passport. Never email it, paste it into websites, share it on messaging apps, commit it to Git repositories, or show it to anyone including IT support. If your private key is compromised, an attacker can access every server and service that trusts your public key.
If you suspect your private key has been compromised: Immediately generate a new key pair and replace the public key on all servers and services. Then securely delete the compromised private key.
Now that you have your key pair, you need to install your public key on each server you want to access. This is called "deploying" or "copying" your public key. The server stores your public key in a special file called authorized_keys, which contains the public keys of all users allowed to connect. There are multiple methods to deploy keys, each suited to different situations—we'll cover both automated and manual approaches so you're prepared for any environment.
The ssh-copy-id command is the easiest way to deploy your public key. It automatically copies your public key to the remote server, creates the .ssh directory if needed, appends the key to authorized_keys, and sets correct permissions—all in one command. This method requires password authentication to be enabled on the server (which it usually is initially).
Replace username with your username on the remote server, and server-ip with the server's IP address or hostname. You'll be prompted for your password on the server—this is the last time you'll need it!
Example: ssh-copy-id john@192.168.1.100 or ssh-copy-id admin@myserver.example.com
Expected output after entering your password:
If ssh-copy-id isn't available (common on Windows without WSL, or on some minimal Linux installations), you can manually copy your public key. This method involves displaying your public key, copying it to your clipboard, then SSH-ing to the server and pasting it into the authorized_keys file.
Step 1: Display your public key and copy it:
Local Machine
Select and copy the entire output (one long line starting with ssh-ed25519).
Step 2: SSH into the server using password authentication, then create the .ssh directory and authorized_keys file with correct permissions:
SSH Server
Replace PASTE_YOUR_PUBLIC_KEY_HERE with the public key you copied. Make sure to include the entire line including ssh-ed25519 at the beginning and your email at the end.
Don't have a remote server? You can practice SSH key authentication by connecting to your own computer! This is a great way to learn the concepts without needing additional hardware or cloud accounts. First, ensure the SSH server daemon is running on your machine (this allows incoming SSH connections).
Ubuntu VM or LinuxThen copy your key to localhost (you're deploying your public key to your own machine):
Ubuntu VM or LinuxEnter your user password when prompted. Now you can SSH to yourself without a password! This might seem silly, but it's perfect for practicing and understanding the authentication flow.
With your public key deployed, it's time for the moment of truth—testing whether key-based authentication works. This section walks you through connecting to your server and using verbose mode to observe the authentication process in detail. Understanding the connection process helps you troubleshoot issues and verify that security is configured correctly.
Now test your passwordless SSH connection! Connect to the server where you deployed your public key. If everything is set up correctly, you'll be logged in automatically without being asked for a password (though you may be asked for your key's passphrase if you set one).
Local MachineSuccess indicators:
If you successfully logged in without entering a server password, you've completed the core objective of this lab! You now have a working SSH key authentication setup—the same secure access method used by professionals worldwide to manage millions of servers.
If SSH isn't working as expected, or if you want to understand what happens during connection, use verbose mode. The -v flag shows detailed debug information about each step of the authentication process. You can use up to three v's (-vvv) for maximum detail.
Key phrases to look for in the verbose output:
Offering public key — SSH is trying to authenticate with a keyServer accepts key — Key authentication succeeded!Authentication succeeded (publickey) — Confirmation of key authPermission denied — Key was rejected (check troubleshooting section)
Now that you can connect with SSH keys, let's make your daily workflow more efficient. The SSH configuration file (~/.ssh/config) is a powerful tool that lets you create shortcuts for servers, specify which key to use for each connection, configure jump hosts for bastion setups, and customize dozens of connection settings. System administrators managing hundreds of servers rely heavily on SSH config to stay productive.
Create or edit the SSH configuration file. This file uses a simple format: Host followed by a nickname, then indented settings that apply to that host. The Host * block sets defaults for all connections.
Add configuration blocks for your servers. Here's a comprehensive example:
Save the file: Press Ctrl + O, then Enter to confirm, then Ctrl + X to exit nano.
The SSH config file must have restrictive permissions to be used. SSH ignores config files that are readable by other users as a security precaution (the file might contain sensitive information like server addresses).
Local MachineNow instead of typing long SSH commands with all the options, you can simply use the short nickname you defined. SSH reads the config file and fills in all the details automatically.
Local Machine
Much simpler! This also works with scp for file transfers: scp file.txt webserver:/home/admin/
Generating keys and deploying them is just the beginning. Proper key management throughout the key lifecycle—creation, storage, usage, rotation, and revocation—is essential for maintaining security. This section covers the practices that security-conscious organizations require, helping you develop habits that will serve you well in enterprise environments and pass security audits.
SSH is strict about file permissions for security reasons. If your private key, config file, or the .ssh directory have overly permissive settings, SSH will refuse to use them or warn you. Run these commands to set all permissions correctly:
Local MachinePermission reference (what each setting means):
~/.ssh/ directory: drwx------ (700) — Only owner can read, write, enterid_ed25519 (private key): -rw------- (600) — Only owner can read and writeid_ed25519.pub (public key): -rw-r--r-- (644) — Owner can write, everyone can readconfig: -rw------- (600) — Only owner can read and writeauthorized_keys: -rw------- (600) — Only owner can read and writeUnderstanding security vulnerabilities is just as important as building secure solutions. This section examines common attack vectors that target SSH key authentication, explains how attackers exploit these weaknesses in real-world scenarios, and provides specific hardening steps to protect your infrastructure. Whether you're preparing for a security interview, conducting a risk assessment, or simply want to understand the threat landscape, this knowledge is invaluable.
If your private key is stolen or exposed, attackers can impersonate you on every server where your public key is authorized. This is the most severe SSH vulnerability.
An attacker gains access to a developer's laptop through malware or physical theft. They copy the private key from ~/.ssh/, then use it to SSH into production servers, exfiltrate customer data, and deploy ransomware—all while appearing as the legitimate developer in audit logs.
Using deprecated algorithms (DSA, RSA with less than 2048 bits, or ECDSA with weak curves) makes keys vulnerable to cryptographic attacks.
A company still uses 1024-bit RSA keys generated in 2010. A nation-state adversary with significant compute resources factors the key, deriving the private key from the publicly-available public key. They now have persistent, undetected access.
ssh-keygen -l -f key.pubAgent forwarding (-A flag) allows a compromised intermediate server to use your local SSH agent to authenticate to other servers without your knowledge.
You SSH to a jump host with agent forwarding enabled. Unknown to you, that server was compromised last week. The attacker's malware detects your forwarded agent and immediately uses it to connect to production databases, all authenticated as you.
ssh -A unless absolutely necessaryForwardAgent no in ~/.ssh/configssh-add -c to require confirmation for each useWhen connecting to a new server, SSH asks you to verify the host key fingerprint. Blindly accepting creates MITM risk.
An attacker on your network intercepts your connection to a new cloud server. They present their own SSH server with a different host key. You accept without verifying, and now all your traffic passes through the attacker who can capture credentials and modify commands.
StrictHostKeyChecking yes in productionOver time, authorized_keys files accumulate stale keys from former employees, contractors, and decommissioned systems.
A developer leaves the company but their SSH key is never removed from production servers. Six months later, they use their old key (still on their personal laptop) to access sensitive data, either maliciously or accidentally.
Overly permissive file permissions on key files allow other users on shared systems to read private keys or modify authorized_keys.
A junior developer on a shared development server accidentally sets their private key to 644 (world-readable). Another user on the same system copies the key and uses it to access the developer's cloud resources and personal repositories.
StrictModes yes in sshd_config (default)PasswordAuthentication no in sshd_configPermitRootLogin noClientAliveInterval 300 and ClientAliveCountMax 2AllowUsers or AllowGroups| Setting | Lab Value | Production Value |
|---|---|---|
| PasswordAuthentication | yes (for initial setup) | no |
| PermitRootLogin | yes (convenience) | no or prohibit-password |
| Key Passphrase | Optional (learning) | Required (mandatory policy) |
| StrictHostKeyChecking | ask | yes (with pre-seeded known_hosts) |
| Key Algorithm | Any (for learning) | Ed25519 or RSA-4096 only |
| SSH Port | 22 (default) | Non-standard (e.g., 2222) recommended |
| Fail2ban/Rate Limiting | Not installed | Active with aggressive rules |
Even experienced administrators encounter SSH issues. The good news is that SSH problems are usually straightforward to diagnose once you know what to look for. This section covers the most common issues you'll encounter, their root causes, and step-by-step solutions. Bookmark this section—you'll likely reference it many times throughout your career.
Root Cause: The server doesn't have your public key, or file permissions prevent SSH from reading it.
Diagnostic Steps:
~/.ssh/authorized_keyschmod 600 ~/.ssh/authorized_keyschmod 700 ~/.sshssh -v user@serverRoot Cause: Your private key file has permissions that are too open. SSH refuses to use insecure keys.
Solution: Fix permissions on your local machine:
Local MachinePossible Causes and Solutions:
ssh -i ~/.ssh/id_ed25519 user@serverssh-copy-id user@serverPubkeyAuthentication yes in /etc/ssh/sshd_configrestorecon -Rv ~/.ssh on RHEL/CentOSRoot Cause: SSH server isn't running, or a firewall is blocking the connection.
Solutions:
sudo systemctl status ssh (or sshd on some systems)sudo systemctl start sshsudo ufw allow 22 or sudo firewall-cmd --add-service=ssh --permanentWhile you'll likely want to keep the SSH keys you created (they're useful!), there may be times when you need to start fresh, remove test keys, or clean up after experimentation. This section provides commands for various cleanup scenarios. Always be careful when deleting keys—losing access to servers is frustrating and time-consuming to fix.
If you want to start fresh or remove keys created during this lab, use these commands. Warning: Deleting your private key means losing access to any server that only has the corresponding public key. Make sure you have alternative access (like a password or console access) before deleting keys.
Local Machine
To remove your public key from a server's authorized_keys: SSH into the server (using password if key is removed) and edit ~/.ssh/authorized_keys. Delete the line containing your public key.
Congratulations on completing this lab! You've gained foundational security skills that every IT professional needs. This section summarizes what you've learned and points you toward the next steps in your IAM and security journey.
ssh -v to understand what's happeningYour learning doesn't have to stop here. This section provides carefully curated resources to deepen your SSH and cryptography knowledge, practice in real-world environments, and prepare for professional certifications. Whether you prefer reading documentation, watching videos, or hands-on practice, there's something here for you.
-i flag and SSH config.ssh-agent to cache decrypted keys in memory, avoiding passphrase prompts while maintaining security. Use ssh-add -t 3600 for time-limited caching./etc/ssh/sshd_config to disable password authentication, change the port, and enable other security measures. Test that you can still connect!ssh -L), remote port forwarding (ssh -R), and dynamic SOCKS proxy (ssh -D). These are powerful techniques for secure access to internal services.