Skip to content

[ops] Host hardening on nuc: sshd password auth, RDP on all interfaces, ufw inactive #23

Description

@marsrobertson

Summary

Host hardening for nuc (100.108.29.106). No code change. Recorded so the fleet's host posture is reviewable alongside the app's.

Not reachable via the Funnel — tailscale serve status shows a single handler, 443 -> 127.0.0.1:8787 — but exposed to anything that can route to the NIC.

Findings

  • sshd on 0.0.0.0:22 and [::]:22 with PasswordAuthentication at the OpenSSH default of yes. /etc/ssh/sshd_config is stock and /etc/ssh/sshd_config.d/ is empty, so nothing sets it. Key auth already works, so disabling password auth costs nothing.
  • RDP on *:3389 via a running gnome-remote-desktop.service.
  • ufw inactive — no host firewall in front of either.

Suggested

  • PasswordAuthentication no in a drop-in under /etc/ssh/sshd_config.d/.
  • Disable gnome-remote-desktop if it is not deliberate.
  • Enable ufw, ssh limited to tailnet/LAN.

All require sudo; none were applied.

Not findings, recorded for completeness

  • Secret permissions are correct: .env (single key NODE_SECRETS), ~/.config/Claude/buddy-tokens.json, RDP key all 0600. No world- or group-readable secrets found. .env contents were not read.
  • nft/iptables refused without root, so the actual packet filter could not be confirmed beyond ufw reporting inactive.
  • A stray ssh -N -L 8788:127.0.0.1:8787 nuc is running on nuc, forwarding nuc's 8788 to nuc's own 8787 — a self-loop. Harmless, but almost certainly meant to run on cockpit-1.
  • Only nuc was inspected. cockpit-1 runs the autonomous launchd loops and is the higher-risk host for the airlock issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions