TinySSH is a small SSH server using NaCl, TweetNaCl

Original Article ↗ Hacker News Discussion ↗

Project scope and goals

  • TinySSH is a minimal SSH server focused on small size, static memory usage, and reduced attack surface.
  • It uses NaCl/TweetNaCl for cryptography and intentionally implements only a subset of SSH features.

Comparison with Dropbear and OpenSSH

  • Compared to Dropbear:
    • TinySSH is more restricted: only key-based auth, a single AEAD cipher, a single elliptic-curve KEX, no RSA, no password auth, no X11/agent/port forwarding, no key restrictions like in OpenSSH.
    • Dropbear aims to be small but still “featureful” and closer to RFC-compliant SSH.
    • TinySSH explicitly trades standards coverage and features for simplicity and a smaller attack surface.
  • Some argue OpenSSH can already meet most needs and that its extra size is negligible for modern systems, including initrd.

Security properties and design

  • TinySSH uses no dynamic memory allocation and has all memory statically allocated (<1 MB), which is claimed to lower risk.
  • It avoids “unsafe features” such as password or hostbased authentication by design.
  • There is skepticism about:
    • Whether ~60–100k “words of code” is truly “easily auditable”.
    • The project’s use of its “own crypto library”.

Use cases: initrd, remote unlocking, embedded

  • Several comments highlight TinySSH (and Dropbear/OpenSSH variants) for:
    • Remote unlocking of encrypted disks during early boot (initramfs/dracut/mkinitcpio hooks).
    • Small static userlands and embedded devices.
  • Multiple tools and approaches are mentioned for automated or remote unlock (Dropbear-based unlockers, Mandos, Clevis+Tang, TPM-based schemes), with debate over trust in the boot chain and threat models.
  • Missing port forwarding is seen as a downside for some embedded/remote scenarios.

Passwords and device enrollment

  • Lack of password auth raises practical questions for shared or constrained devices (printers, routers, cars).
  • Suggested workaround: device-generated keys shown via QR or similar, then user installs their own keys.

Licensing discussion

  • TinySSH is licensed under CC0 1.0.
  • Several comments say CC0 is not ideal for software due to explicit exclusion of patent/trademark rights.
  • Alternatives like very-permissive software licenses are suggested; some propose dual/multi-licensing.
  • The earlier Creative Commons “termination” issue is noted, but commenters state it does not apply to CC0 specifically.

Broader perspective

  • Some see TinySSH as an appealing “small and beautiful” tool for specific niches.
  • Others argue that replacing OpenSSH in general is unlikely, given its maturity, deployment scale, and security track record.