Tailscale SSH trouble, native Dolby Vision on a mini PC, and proving backups actually boot

Homelab Highlights for 2026-10-26: self-hosting and homelab notes worth knowing.

[Audio embed placeholder]

The Lead: Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers

The Hacker News reported unpatched flaws in Tailscale SSH: if port forwarding is enabled, a single compromised device on the tailnet can reach root on other servers without stolen credentials. Tailscale SSH authenticates by device identity and access rules, not passwords or keys. The attack requires a foothold on one trusted device via a vulnerable web app, poisoned package, phishing, or stolen logins. The VP of engineering responded on the Tailscale subreddit, noting the researcher published the report without coordinated disclosure. Mitigations include per-pair SSH rules, disabling port forwarding, and enabling node key expiry.

Why it matters: Tailscale is widely used in homelabs for simple VPN access. This design vulnerability means the convenience of trusted devices also makes them a vector for lateral movement. For homelab operators, disabling SSH port forwarding unless absolutely needed is a low-disruption fix.

Source: r/unRAID

News Roundup

Huge breakthrough for 4K Remuxes: Native Dolby Vision Profile 7 FEL playback on PC (Intel/AMD) via LibreELEC/Kodi

Developer CroqueMr built native Dolby Vision support into an x86 LibreELEC/Kodi build, including proper Profile 7 FEL reconstruction. The FEL is fully processed and output via a native TV-led tunnel using an open-source engine on LibreELEC 13 / Kodi 22 RC1 — no proprietary Dolby SDK. A cheap Intel N100 mini PC plays 4K Profile 7 FEL remuxes with zero dropped frames. Works with Plex for Kodi or Jellyfin-style skins.

Why it matters: This closes the last major gap for PC-based media clients: true Dolby Vision without stripping layers or forcing transcodes. Homelab operators with 4K remux libraries can now use inexpensive x86 hardware instead of certified ARM boxes like the Shield Pro or Ugoos AM6B+.

Source: r/jellyfin

Reclaim your Bambu Lab printer: camera, machine control and G-code in Home Assistant

Bambu Open Network is an open-source HACS extension for ha-bambulab that restores cloud camera feeds, machine control (XYZ movement, homing, temperature, fan), and a multiline G-code console. It works through Bambu Cloud login, not fully local, but brings back features Bambu Lab locked down. The extension adds a Bambu Control sidebar page and exposes cameras as Home Assistant entities for dashboards and automations.

Why it matters: Bambu Lab’s restrictions removed write access and cloud camera feeds from existing integrations. This extension restores control and monitoring for homelab users who rely on Home Assistant for printer management, though it still depends on Bambu Cloud rather than being fully local.

Source: r/homeassistant

CodeNomad 1.0: a self-hosted workspace for OpenCode coding agents, reachable from your phone without opening a port

CodeNomad 1.0 is an open-source (MIT) web and desktop client for OpenCode coding agents. The server runs on your own box (Linux, macOS, Windows, WSL) and talks to OpenCode on that host. Remote access pairs a phone via OpenTunnel relay without opening inbound ports — encrypted end-to-end, revocable. Direct LAN/VPN access also works. Features include multi-project/agent sessions, Git worktrees, and missions where agents plan and delegate tasks with user approval.

Why it matters: For homelab users running coding agents, CodeNomad provides a self-hosted workspace that keeps repos and history local. The remote access model avoids port exposure while allowing phone-based approval of agent actions, useful for long-running tasks.

Source: r/selfhosted

Tool & Software Highlight: PBP: automated restore testing for Proxmox Backup Server (open source, looking for feedback)

PBP (Proxmox Backup Proofing) automates restore testing for Proxmox Backup Server. On a schedule, it takes the newest backup of each guest, protects it from pruning, restores it as a temporary guest on an isolated bridge, boots it, and checks inside for failed systemd units, read-write root, and service profiles (PostgreSQL, nginx, Docker, Redis, etc.). It then destroys the copy, writes a verdict into the backup’s notes, and sends a summary via Proxmox notification targets. Verdicts: PROVEN, FAILED, BOOTED, SKIPPED, ERROR. Safety features include non-root API token, unprivileged SSH user, and bridge isolation verification. Requires Proxmox VE 9 and PBS 4; runs in Docker or .deb (amd64/arm64). Pre-1.0, Apache-2.0 licensed.

Why it matters: PBS’s verify job only checks data integrity, not whether a guest actually boots and runs services. PBP fills that gap, catching failures like a broken gitea-runner service that would only surface during a real restore. For homelab operators relying on Proxmox backups, this provides confidence that backups are actually usable.

Source: r/Proxmox

Community Highlight: I migrated my complete homelab from Proxmox to Nix

A seven-year Proxmox user migrated their entire homelab to Nix, using QEMU for VMs and systemd nspawn for containers. Reasons: uniform configuration (Ansible drift over years), unused HA features in a 3-node cluster (with consumer SSD wear), and backup bloat (450GB full-volume backups dropped to 15-20GB with app-data-only backups). The repo is public on GitHub. Security uses guest UID offset to map container root to unprivileged host ID, though static offsets across containers allow cross-container file access. Replies noted Nix can run inside a Proxmox VM, and de-clustering is an option for those not needing HA.

Why it matters: This is a detailed, real-world migration report from a mature homelab setup. It highlights tradeoffs between Proxmox and declarative Nix configuration, especially around backup efficiency, configuration drift, and cluster overhead. The public repo and honest security discussion make it a valuable reference for anyone considering a similar move.

Source: r/homelab

Sources

Transcript

Host A: Welcome to Homelab Highlights, the show that surfaces practical homelab wins and useful self-hosted tools.

Host A: A security story that hit homelab nerves over the weekend: The Hacker News reported on flaws in Tailscale SSH that are still unpatched. The short version is rough: if Tailscale SSH is set up to allow port forwarding, a single compromised device on the tailnet could reach root on other servers. The mechanics matter here, because it is not a classic credential attack. Tailscale SSH does not authenticate with passwords or keys at all — it identifies the device, and a single access rule decides whether that device can open an SSH session to a target. So the attack needs no stolen credentials whatsoever. What it needs is a foothold on one device the access rules already trust, which the report says an attacker gets the usual ways: a vulnerable web app, a poisoned package, phishing, or stolen logins.

Host B: And that is the uncomfortable part for anyone running Tailscale on a homelab — which is most of this audience. The convenience of Tailscale SSH is that a trusted device just works. But that design means a trusted compromised device works just as well for the attacker. Someone in the discussion put it bluntly: this is a side effect of the convenience, essentially the same exposure as if every machine shared private keys by design. There is drama around the disclosure, too. The VP of engineering posted a statement over on the Tailscale subreddit, and the community noted the company is unhappy that the researcher apparently published the report rather than going through coordinated disclosure. So treat the details with that caveat — but the reported mitigations are concrete regardless. Per-pair SSH rules instead of broad access, disabling SSH port forwarding where it is not needed, and enabling node key expiry so devices have to re-authenticate. For a typical homelab, turning off port forwarding on Tailscale SSH unless something genuinely requires it is the least disruptive of those.

Host A: Big one for the media server crowd first. A developer called CroqueMr has built native Dolby Vision support into an x86 LibreELEC and Kodi build — including proper Profile 7 FEL reconstruction. Anyone with a library of 4K remuxes knows the pain: PC clients usually strip the enhancement layer, fall back to HDR10, or force a heavy server transcode, and true TV-led Dolby Vision meant buying certified boxes like the Shield Pro or Ugoos AM6B+. And this is not a shortcut hack. The FEL is fully processed and output through a native TV-led tunnel using an open-source processing engine, on a LibreELEC 13 and Kodi 22 RC1 stack — no proprietary Dolby SDK. The impressive bit for homelab budgets: the developer confirmed a cheap Intel N100 mini PC plays a 4K Profile 7 FEL remux with zero dropped frames, benching at 40fps against 24fps film content. Works with Plex for Kodi or a Jellyfin-style skin against the existing server.

Host B: From media servers to printers: Bambu Lab locked down features people already had, so a developer built Bambu Open Network — an open-source HACS extension for the existing Home Assistant Bambu integration that brings back cloud camera feeds, machine control, XYZ movement, temperature and fan controls, and a multiline G-code console. The catch is it works through Bambu Cloud rather than fully local, so it restores access rather than escaping the cloud entirely. Quick one for the agent-curious. CodeNomad hit version 1.0 — a self-hosted web and desktop client for OpenCode coding agents. The server runs on your own box, and the interesting remote-access bit is pairing a phone through a relay without opening an inbound port, with encrypted connections end to end and revocable devices. Fine to skip the relay and stick to LAN or a VPN if that suits better. That closes the feed — more on both of those setups in a moment, because the backup story deserves the full treatment over in the tool highlight.

Host B: Tool highlight time, and this one attacks a habit almost everyone in the audience has. A developer on the Proxmox subreddit released PBP — Proxmox Backup Proofing — an open-source tool that automates the one thing Proxmox Backup Server does not do: proving a backup actually boots. The distinction is the whole point. PBS’s verify job proves the backup data is intact — checksums match, the store is healthy. What it cannot tell anyone is whether the guest will boot, mount its filesystem read-write, and bring its services up. PBP runs on a schedule: it takes a new backup of each guest, protects it from pruning, restores it as a temporary guest into a reserved VMID range with every network interface moved onto an isolated bridge, boots it, and checks inside — failed systemd units, read-write root, service profiles for things like PostgreSQL, nginx, Docker, Redis. Then it destroys the copy, writes a verdict into the backup’s notes, and sends one summary through existing Proxmox notification targets.

Host A: The author’s own lab result sells it: a scheduled run restored a container’s newest backup, booted it, and found the gitea runner service had failed — a backup PBS marked verified, which would only have surfaced the day it was actually needed. The safety design looks thoughtful too: it never logs in as root, using a narrow API token and an unprivileged SSH user locked to a single helper command, and it verifies the proof bridge is genuinely isolated before use. Practical notes before anyone rushes in: it is version 0.8.2, pre-1.0, Apache-2.0 licensed, and needs Proxmox VE 9 with PBS 4. It runs in Docker or from a deb package, and the author explicitly recommends a separate host rather than the PVE node itself — a lab environment can stretch that. One community edge case worth watching: full-disk-encrypted guests with network unlock do not work with full isolation, and the author is weighing the permission tradeoffs there. It is not failover or live restore — purely the proof that restores work. That is a gap worth filling, and the author is actively asking for feedback on which checks are missing.

Host A: Community highlight, and this is a big swing: a seven-year Proxmox user posted about migrating the entire homelab off Proxmox to Nix — QEMU for VMs, systemd nspawn for containers, the whole repo public on GitHub. The reasoning is what makes it interesting. First, uniform configuration: Ansible to initialize containers plus years of manual changes had produced serious drift, with some services better configured than others. Second, the three-node Proxmox cluster was mostly unused for HA — and the author found Proxmox in cluster mode harsh on consumer SSDs and did not want to fight it. Third, backups: Proxmox was backing up whole volumes without deltas, and after the move backup sizes dropped from around 450 gigabytes to 15 or 20, with app-data-only backups now easy to adjust.

Host B: The security detail in the thread is worth pulling out. With default container setups, root inside maps to root on the host, so an escape plus privilege escalation is game over. With a guest UID offset, container root maps to an unprivileged host ID. The author notes the limitation honestly — a static offset shared across containers means an escaped attacker can still read other containers’ files, and per-container randomized offsets would fix that at the cost of fiddly permissions on shared volumes. The replies had the usual mix of solidarity and second thoughts. One commenter who had just installed Proxmox asked, half joking, whether another research rabbit hole was now mandatory — and the sensible answer came back that these solve different problems; Nix can even run inside a Proxmox VM. Someone else described de-clustering their own three nodes after corosync kept dropping during nightly backups, which validates the author’s HA reasoning. Worth flagging as attributed experience: this is one person’s migration that worked for their services, not a verdict that Proxmox is wrong — the status page auto-generated from service definitions is a genuinely neat demonstration of what declarative config buys, though, and the repo is public for anyone planning a similar move.

Host A: That’s Homelab Highlights for Monday. Until next time, happy hosting!