SSH as a Sudo Replacement

Original Article ↗ Hacker News Discussion ↗

Using SSH as a local replacement for sudo or su sparks debate over whether it actually improves security or just trades one attack surface for another. Proponents like that it avoids setuid binaries and can reduce local privilege-escalation risk, especially when combined with key-based auth and restricted sockets. Critics counter that it adds complexity, weakens fine-grained access control and auditing compared to sudo, and can complicate recovery, arguing that better configuration of existing tools (or alternatives like doas or systemd’s run0) is usually preferable.

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.