Skip to content

Security

SSH & Remote Access

With headless nodes (no monitor, no keyboard), SSH is your only interface.

Theory

SSH (Secure Shell) creates an encrypted tunnel between your admin machine and a remote node. It replaces older, insecure protocols like Telnet and rsh.

Key-based authentication is more secure and more convenient than passwords:

  1. You generate a key pair: ssh-keygen -t ed25519
  2. The public key goes on the server (~/.ssh/authorized_keys)
  3. The private key stays on your machine (~/.ssh/id_ed25519)
  4. When you connect, SSH proves you hold the private key without ever sending it

SCP (Secure Copy) transfers files over SSH:

scp scripts/prep-node.sh leva@192.168.1.51:~

This copies the file to leva's home directory on the remote node.

Remote command execution lets you run commands without an interactive session:

ssh leva@192.168.1.51 "sudo ./prep-node.sh k8s-cp-01"

Obstacles

  • ssh-copy-id vs. manual key deployment. ssh-copy-id is the easy path. If it's not available, you can cat ~/.ssh/id_ed25519.pub | ssh user@host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys".
  • Permissions matter. SSH refuses to use keys if permissions are too open: ~/.ssh must be 700, authorized_keys must be 600. A common "why won't my key work" trap.
  • Host key verification. The first time you SSH to a new IP, you're asked to accept the host fingerprint. This protects against man-in-the-middle attacks. After a node rebuild (same IP, new OS), you'll get a WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! error. Fix with ssh-keygen -R <ip>.

Implementation

  • Deployed MacBook M1's public key to both nodes
  • dev.sh opens persistent SSH sessions via Tmux

Resources

Security Awareness

Building infrastructure from scratch often reveals real security findings and requires several security-conscious decisions.

Theory

Threat modeling for a homelab. Your homelab sits on a private network, but your documentation is public (GitHub). The threat surface includes:

Vector Risk Mitigation
Public repo exposes network topology Attacker learns IPs, MACs, hardware Redact MACs, use generic IPs in public docs
SSH password authentication Brute-force attacks if exposed to internet Key-based auth only
Passwordless sudo Any process running as leva can escalate to root Acceptable for homelab — would use targeted NOPASSWD rules in production
Unpatched OS Known CVE exploitation Regular apt-get update && apt-get upgrade

Defense in depth. No single control is enough. Layer them: SSH keys + firewall + non-root user + sudo restrictions + network isolation.

Obstacles

  • "It's just a homelab." This mindset creates bad habits. Practice security properly now so it's muscle memory in production.
  • MAC address disclosure. You caught this on day 4 — a real DevSecMLOps finding. MAC addresses can be used for network device fingerprinting and spoofing.

Implementation

  • Journal entry 2026-05-26: security review and MAC redaction

Resources