PebbleRack

Guide 06 of 25 · beginner

Use SSH keys for lab administration

Set up encrypted remote administration on the local network while keeping console recovery available.

Source-verified · Not lab-testedOfficial sources checked 2026-09-29. No PebbleRack hardware compatibility claim.

Outcome

You can log in to the Ubuntu host from one trusted computer using an SSH key, test the key path, and maintain a local recovery option. SSH will remain limited to your home network in this beginner path.

Before you start

You need local console access to the server, a normal non-root account with sudo, and a trusted client computer with OpenSSH. Know the host address from guide 04. Do not change password authentication until key login works twice from a new session. Do not forward router port 22 to the internet.

Steps

  1. Verify the server. On the Ubuntu host, run systemctl status ssh. If OpenSSH Server is missing, install it with sudo apt install openssh-server, then check status again. Record whether it starts after reboot. Ubuntu's OpenSSH guide describes both package installation and configuration files.
  2. Create a client key. On your trusted client, run ssh-keygen -t ed25519 -C "home-lab-admin". Accept a file path that will not overwrite an existing key. Set a strong passphrase. Keep the private key only on your trusted device and in a secure recovery process. The .pub file is the public half.
  3. Install the public key. From the client, use ssh-copy-id username@host-address if available, replacing both placeholders with your actual values. Alternatively, follow Ubuntu's manual authorized_keys method. Do not send the private key to the server. Log in with ssh username@host-address; verify the server hostname with hostnamectl before continuing.
  4. Test a second session. Keep the first SSH and local console sessions open. Open a fresh terminal and log in again using the key. Run id, hostnamectl, and sudo -v to prove that you are the intended user with working administrative access. Confirm that a failed network connection still leaves you local console access.
  5. Restrict access deliberately. If you use Ubuntu's ufw, allow SSH from the specific trusted LAN scope or host before enabling it, then run sudo ufw status verbose. Do not blindly copy a network range from a tutorial; use your own private inventory. Ubuntu notes that ufw starts disabled. Docker container ports later have separate firewall behavior, so this is not a blanket container protection.
  6. Only then review stronger server settings. Ubuntu permits small snippets under /etc/ssh/sshd_config.d/. If you decide to disable password login, validate the effective config with sudo sshd -t, restart or reload the service, and repeat the fresh-session test before closing local access. Keep a documented break-glass route. On a first home lab, this is an explicit choice, not a step to automate blindly.

Check it worked

A key-based login from the trusted client succeeds twice; sudo -v succeeds under the intended account; an untrusted device has no approved path; and local login still works. Record the key's public fingerprint, not its private contents.

If it fails / rollback

Use the open session or local console to inspect systemctl status ssh, the SSH service log, file permissions, and firewall rules. Restore the previous SSH snippet or firewall rule before closing the console. Never disable your only working login method while testing.

Safety and data notes

SSH key possession can grant administrative access. Do not paste private keys, passwords, host inventories, or full logs with personal data into public forums. Public internet SSH access needs a separate threat model and is outside this guide.

Sources

  • Ubuntu Server, OpenSSH server — package, ed25519 key, and configuration; checked 2026-09-29.
  • Ubuntu Server, firewall — ufw and scoped SSH rules; checked 2026-09-29.
  • Docker, packet filtering and firewalls — container port interaction; checked 2026-09-29.

Next guide

Continue to guide 07, “Establish a patching baseline.”