Show HN: Ruroco – like port knocking, but better

Original Article ↗ Hacker News Discussion ↗

Purpose and Design of Ruroco

  • Presented as an improved, cryptographically protected alternative to naive port knocking.
  • Client sends a single UDP packet containing encrypted data (time, command, random bytes).
  • Server maps authenticated commands to preconfigured actions (e.g., open/close ports, toggle services), not just SSH.
  • Author emphasizes convenience for personal, infrequent access and use from restrictive networks (e.g., only 80/443 or DNS 53 allowed).

Cryptography and Key Usage

  • Uses RSA; client “encrypts with private key,” server “decrypts with public key.”
  • Multiple commenters note this is conceptually “signing” rather than traditional public-key encryption, and discuss hybrid encryption vs signing.
  • Some confusion in the docs about terminology (encrypt vs sign) is flagged as potentially misleading.

Replay Attacks and Threat Model

  • Encrypted payload includes a high‑resolution deadline; server adds that deadline to a blocklist after first use.
  • This makes exact packet replays ineffective: any second packet with the same deadline is rejected, regardless of time.
  • However, interception-and-modification attacks are a concern: thread points out that an attacker could replay with a different source IP to whitelist themselves.
  • Including source IP in payload is suggested, but NAT and shared networks complicate this; overall protection against on‑path attackers remains limited.
  • Author acknowledges some attacks aren’t currently prevented and plans improvements.

Relation to Port Knocking, SPA, and Similar Tools

  • Compared with classic port knocking, Single Packet Authorization (e.g., fwknop), Ostiary, and Moxie’s knockknock.
  • Distinctive aspects: single UDP packet, arbitrary server-side commands, time-based one‑time use.
  • Others note older tools already handle replay protection and use simpler or more formally discussed crypto.

Security Value vs Obfuscation

  • Several comments frame it as primarily hiding services and reducing SSH log noise, not replacing SSH hardening.
  • Debate over whether this is “security through obscurity” vs legitimate attack-surface reduction.
  • Running an extra daemon increases attack surface; reading firewall logs (no open port/sniffer) is cited as safer but less flexible.

Alternatives: VPNs and Zero‑Trust

  • Many suggest WireGuard, Tailscale SSH, or “no inbound ports”/overlay networks (e.g., zssh) as more robust for sensitive or multi-user environments.
  • Counterpoints: VPNs add operational complexity, may be overkill for a single personal server, and don’t help when the goal is temporarily exposing HTTP to a local network without configuring clients.