SSH as a Sudo Replacement

Original Article ↗ Hacker News Discussion ↗

Scope of the Idea

  • Discussion centers on using a local SSH daemon (often on a Unix socket) as a replacement for sudo/setuid, not about exposing root SSH over the internet.
  • Several note this is conceptually similar to systemd’s run0 and earlier work (e.g., LISA papers).

Security Model: SSH vs sudo/su

  • One camp argues logging in directly as root via SSH (with keys) can be strictly more secure than user→sudo:
    • Fewer accounts that can escalate.
    • Avoids setuid binaries exposed to all users.
    • Reduces attack surface from user processes, daemons, and cron jobs that might have sudo access.
  • Others push back:
    • sshd is larger and more complex than sudo; more code can mean more bugs.
    • su and sudo are also setuid but simpler than sshd; if the goal is less code, su/doas may be better.
    • SSH still has to handle environment, files, and sockets, so the “smaller surface” claim is disputed.

Setuid and Privilege Escalation

  • Supporters emphasize the benefit of removing setuid/setgid entirely; elevating privileges is hard to secure in Unix.
  • Critics respond that something must elevate privileges anyway; setuid isn’t uniquely bad, just another mechanism.
  • Some highlight environment-based attacks on setuid/sudo (PATH, LD_PRELOAD) vs more “obvious” network data handling in daemons.

Auditing, Policy, and Usability

  • Many value sudo for:
    • Fine-grained command control and argument restrictions.
    • Per-user auditing and accountability.
  • SSH-based root sessions lose this granularity unless combined with ForceCommand or related tricks, which are less flexible.
  • Several admit to using sudo bash and regretting poor audit trails, but still see sudo as better for policy enforcement.

Complexity and Operational Concerns

  • Critics view “SSH as sudo” as added complexity and technical debt: extra daemons, sockets, crypto, and edge cases.
  • Concerns raised about:
    • Single-user/recovery mode when root password is disabled.
    • Boot-time failures of sshd leaving the system inaccessible.
  • Some argue that in modern immutable/golden-image setups, any interactive root shell (via SSH or sudo) is itself a failure mode.

Key Management and Access Control

  • Central question: how to handle multiple admins?
    • Sharing root keys is discouraged; per-user keys plus SSH certificates are suggested but add management overhead.
  • Traditional wheel/sudo groups and sudoers rules are seen as simpler for many environments.