> ## Content Index
> Fetch the complete content index at: https://agarhouse.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Practice SSH Key Login in a Disposable Linux Lab
- URL: https://agarhouse.com/practice-ssh-key-login-disposable-linux-lab/
- Published: 2026-11-13T13:00:00.000Z
- Updated: 2026-11-13T13:00:00.000Z
- Description: Prove that an SSH login uses the key you intended. Build a temporary localhost lab, verify its identity, test key-only access, and revoke it safely.
- Author: Meatball
- Tags: Cybersecurity, Tutorial, #agarhouse-slot-2026-11-13-0800

An SSH login can succeed without using the key you meant to test. Another key in your agent, a saved connection, or a password fallback can hide a mistake. Before changing access to a real server, it helps to make the test small enough that you can explain why it worked.

This lab runs a separate SSH server on your own Linux machine, reachable only through `127.0.0.1`, the loopback address. You will create a dedicated user key, give the lab server its own identity, prove a key-only login, and then remove the authorization to check that the same login fails. Your existing SSH configuration stays untouched.

## What you need

- A disposable Linux VM or lab machine you control, with a normal, usable non-root user account and two Bash terminal windows.
- OpenSSH client tools and the server binary already installed. This guide uses `/usr/sbin/sshd`; it does not install packages or enable a system service.
- A free local TCP port `22222`. Do not open a firewall port, forward a router port, or change the listening address to reach this lab from another computer.

**Test scope:** The core workflow passed on Debian 13.6 with OpenSSH 10.0p2 (Debian package 7+deb13u4): configuration validation, login with a passphrase-protected key, rejection after removing its authorization, and cleanup. The test used a temporary directory and a separate non-root server process. Other Linux distributions, macOS, and Windows were not runtime-tested. This is a local authentication exercise, not a production SSH-hardening configuration.

The remote command will run as your own account, so this is not a sandbox for untrusted commands. Use only the commands below. We will not disable password authentication, restart an existing SSH service, or edit `/etc/ssh` or `~/.ssh`.

## 1\. Give the lab its own directory

Use Terminal A for preparation and client commands. Run each command in order and stop if it fails. In a multiline command, the trailing backslashes join the lines; paste that command as a whole.

```
ssh -V
command -v ssh-keygen
test -x /usr/sbin/sshd && echo "sshd is available"
id -un
id -u
```

You should see an OpenSSH version, a path to `ssh-keygen`, the availability message, your username, and your numeric user ID. If the user ID is `0`, stop and switch to a normal lab account. If a tool is missing, arrange a disposable environment with the OpenSSH client and server installed before continuing. Do not run this lab as root.

```
LAB=$(mktemp -d /tmp/agarhouse-ssh-lab.XXXXXX)
printf 'Lab directory: %s\n' "$LAB"
```

Keep Terminal A open. The `LAB` variable holds a newly created, owner-only directory, so these commands will not overwrite an existing key. Note the printed path for cleanup. If you close this terminal or lose the variable, recover that exact path from your notes before continuing; do not guess it or use a wildcard.

## 2\. Make the two identities explicit

SSH uses different keys for different jobs. Your **user key** proves that you may access an account. A server’s **host key** lets the client recognize the server it is contacting. Mixing those roles makes troubleshooting harder.

First, generate a dedicated Ed25519 user key:

```
ssh-keygen -t ed25519 -a 64 \
  -C "agarhouse-disposable-lab" \
  -f "$LAB/client_key"
```

At the prompts, enter and repeat a nonempty passphrase. Type it only into the prompt, not into a command or a shared note. The file `client_key` is private; `client_key.pub` is its public half. Never upload, paste, or copy the private file to a server.

Now generate a separate host key for this temporary server:

```
ssh-keygen -t ed25519 -N '' -f "$LAB/host_key"
ssh-keygen -lf "$LAB/client_key.pub"
ssh-keygen -lf "$LAB/host_key.pub"
```

The host key intentionally has no passphrase so the lab server can start. The two fingerprint lines should differ: you created two independent key pairs. A fingerprint is a compact identifier for a public key, not a replacement for keeping the private key secret.

## 3\. Authorize the public key and pin the server identity

This lab’s authorization file is new and separate from your normal account settings. Give it the public user key:

```
printf 'restrict ' > "$LAB/authorized_keys"
cat "$LAB/client_key.pub" >> "$LAB/authorized_keys"
```

The `restrict` option limits features such as forwarding and terminal allocation for this key. It still permits the small command we will run. These restrictions are useful boundaries for the exercise, not a complete isolation system.

Because you just generated the lab server’s host key locally, you already have a trusted copy of its public half. Put that exact key into a separate known-hosts file:

```
awk '{print "[127.0.0.1]:22222 " $1 " " $2}' \
  "$LAB/host_key.pub" > "$LAB/known_hosts"
ssh-keygen -lf "$LAB/host_key.pub"
ssh-keygen -lf "$LAB/known_hosts"
```

**Checkpoint:** these two fingerprint lines should match. This avoids blindly accepting a first-connection prompt. For a real remote server, obtain its host fingerprint through a trusted channel, such as its console, and compare it before accepting the connection. A key collected from the same unverified network connection cannot independently establish the server’s identity.

## 4\. Start a separate localhost server

Create the lab configuration in Terminal A:

```
cat > "$LAB/sshd_config" <<EOF_CONFIG
ListenAddress 127.0.0.1
Port 22222
HostKey $LAB/host_key
PidFile $LAB/sshd.pid
AuthorizedKeysFile $LAB/authorized_keys
AllowUsers $(id -un)
UsePAM no
PermitUserRC no
EOF_CONFIG
/usr/sbin/sshd -t -f "$LAB/sshd_config"
```

**Checkpoint:** the validation command should return without an error. That checks the configuration and key files, not whether a login will succeed. This standalone configuration points to the lab files and allows only your current username. PAM is the system’s authentication framework. Debian documents that an SSH server using PAM cannot run as a non-root user, so this separate lab process uses `UsePAM no`. Do not copy that choice into a production configuration. No password-authentication setting is changed.

Print the server command:

```
printf '/usr/sbin/sshd -D -e -f %s/sshd_config\n' "$LAB"
```

Open Terminal B and paste the complete printed command there. Leave it running in the foreground. A successful start should report that it is listening on `127.0.0.1` port `22222`. If it reports a bind or configuration error, stop here. Do not use `sudo` to force the lab to start.

## 5\. Prove that this key can authenticate

Return to Terminal A. This deliberately explicit command ignores your usual client configuration, selects the lab key, avoids an authentication agent, and permits only public-key authentication:

```
ssh -F none -p 22222 \
  -i "$LAB/client_key" \
  -o IdentitiesOnly=yes \
  -o IdentityAgent=none \
  -o PreferredAuthentications=publickey \
  -o StrictHostKeyChecking=yes \
  -o UserKnownHostsFile="$LAB/known_hosts" \
  -o GlobalKnownHostsFile=/dev/null \
  "$(id -un)@127.0.0.1" 'id -un'
```

Enter the passphrase for `client_key` when requested. This unlocks your local private key; it is not the account password. The command should print the same username as step 1 and exit.

Success now means something specific: the selected user key authenticated to a server whose host key matched the lab’s trusted record. The command did not fall back to an account password. Your existing server settings and normal login methods were not changed to achieve that result.

## 6\. Check that removing authorization really blocks it

**This next command empties a file.** It is safe only for the new lab authorization file under the printed `/tmp/agarhouse-ssh-lab...` directory. Never substitute your real `~/.ssh/authorized_keys`.

```
printf 'Removing authorization from: %s\n' "$LAB/authorized_keys"
: > "$LAB/authorized_keys"
```

Run the exact SSH command from step 5 again. This time it should end with a permission-denied error and should not print a successful remote username. The error may list password or keyboard-interactive among the server’s advertised methods; the client still attempted only public-key authentication. You have removed the server’s permission to accept that key, even though the private key still exists on the client.

If you want to repeat the successful test, rerun the two commands in step 3 that write the public key into the lab authorization file. There is no need to restart the server.

## Troubleshoot the stage that failed

- **Address already in use:** another process owns port 22222\. Stop the lab attempt and identify that process before choosing a different lab port. If you change the lab port, update all three places together: `Port` in the lab configuration, the bracketed port in `known_hosts`, and the client’s `-p` value. Do not terminate an unfamiliar service.
- **Server will not start:** read Terminal B’s error. Non-root server behavior can depend on the distribution and account configuration. A missing runtime directory, locked account, or permission error is a reason to resolve the lab prerequisites, not to weaken system settings.
- **Host key verification failed:** confirm both commands refer to the same lab directory and port. Do not disable host-key checking to continue.
- **Permission denied before the intentional removal:** check the username, the lab configuration’s authorization path, and that step 3 copied `client_key.pub`, not the private file. Terminal B may explain an ownership or account problem. Do not relax file permissions or disable ownership checks to make the test pass.
- **Wrong passphrase:** retry the passphrase you chose for the user key. An account password cannot unlock it. For this disposable exercise, starting over in a fresh lab directory is preferable to changing your real keys.

## Stop and remove the exercise

In Terminal B, press Ctrl+C to stop the foreground lab server. Its prompt should return. An attempt to run step 5 again should now fail to connect rather than authenticate.

In your file manager, open `/tmp` and find the exact lab directory printed in step 1\. Check its name and contents, then delete only that directory. It contains the disposable keys and configuration. Do not delete your normal `.ssh` directory. Close the lab terminals afterward.

The lesson transfers to a real server even though this setup does not: identify the server first, authorize only the public user key, and test a fresh connection that cannot quietly use a different authentication method. Keep a working recovery route until that evidence is clear.

## Sources

- [OpenSSH ssh-keygen manual](https://man.openbsd.org/ssh-keygen?ref=agarhouse.com): key generation, passphrases, public-key files, and fingerprints.
- [OpenSSH sshd manual](https://man.openbsd.org/sshd?ref=agarhouse.com): standalone server options, configuration checking, and authorized-key restrictions.
- [OpenSSH server configuration reference](https://man.openbsd.org/sshd%5Fconfig?ref=agarhouse.com): listening address, alternate authorization files, allowed users, and lab configuration directives.
- [Debian OpenSSH server configuration manual](https://manpages.debian.org/trixie/openssh-server/sshd%5Fconfig.5.en.html?ref=agarhouse.com): the Linux-specific PAM limitation for a non-root server process.
- [OpenSSH client manual](https://man.openbsd.org/ssh?ref=agarhouse.com): explicit identity selection, remote commands, and server authentication.
- [OpenSSH client configuration reference](https://man.openbsd.org/ssh%5Fconfig?ref=agarhouse.com): authentication selection, agent control, and known-host verification.