Autenticación de contraseña SSH no interactiva

Artículo original ↗ Discusión en Hacker News ↗

Automatizar conexiones SSH que requieren contraseña sigue siendo controvertido: algunos ingenieros confían felizmente en herramientas como `sshpass`, mientras que otros argumentan que estos enfoques son frágiles porque dependen de analizar prompts y de un comportamiento del TTY propenso a fallos. Muchos participantes insisten en que la autenticación basada en claves públicas o certificados, Kerberos o certificados SSH de corta duración es más segura y escalable, pero reconocen que el hardware de red heredado, las configuraciones TACACS/RADIUS y las restricciones de los proveedores a menudo dejan SSH solo con contraseña como la única opción práctica. La conversación se amplía a cómo gestionar el acceso privilegiado a escala —mediante gestión de configuración, productos PAM, bastiones o agentes personalizados—, destacando las compensaciones entre seguridad, complejidad y fiabilidad en infraestructuras reales.

Enfoques de autenticación SSH por contraseña no interactiva

  • Muchos comentaristas sostienen que la autenticación por contraseña en SSH debería evitarse; se prefieren claves/certificados, y algunos deshabilitan por completo los inicios de sesión con contraseña.
  • Otros señalan que la autenticación por contraseña no interactiva es inevitable con ciertos dispositivos de red, BMCs, equipos de proveedores, configuraciones TACACS+/RADIUS o aprovisionamiento inicial cuando solo hay contraseñas disponibles.
  • Algunos están explorando automatizar SSH basado en OTP/TOTP, pero no se detallan recetas concretas ni robustas.

sshpass vs alternativas (passh, ASKPASS, expect)

  • Varias personas dicen que sshpass es “suficientemente bueno”, citando su uso a gran escala (decenas de miles de máquinas) sin problemas y elogiando su simplicidad.
  • Los críticos señalan que sshpass es frágil porque analiza los prompts de contraseña; cambios en los prompts o en el comportamiento del TTY pueden romperlo.
  • Un patrón alternativo es usar SSH_ASKPASS y SSH_ASKPASS_REQUIRE (en clientes OpenSSH más recientes) para inyectar contraseñas de una forma más controlada, lo que podría hacer que herramientas extra sean más simples o innecesarias.
  • Se menciona la herramienta passh como más robusta en el manejo del TTY; la acusación de “broken by design” sobre sshpass proviene de ese proyecto, no del autor del artículo.
  • Se mencionan herramientas tradicionales como expect; son potentes pero pueden ser frágiles, especialmente bajo cron o sin un TTY real.

Claves, certificados y restricciones del mundo real

  • Los comentaristas reiteran que las claves/certificados son “la forma correcta”, pero describen obstáculos:
    • Equipos de red (p. ej., algunas variantes de Cisco/Juniper, dispositivos Ubiquiti) donde la configuración de claves es incómoda o no persistente.
    • La autenticación central mediante TACACS+/RADIUS suele estar diseñada en torno a contraseñas, con soporte de claves limitado o improvisado.
    • Muchos stacks SSH embebidos carecen de funciones modernas como FIDO2.
  • Algunos sugieren certificados SSH, Kerberos o FreeIPA, pero reconocen la complejidad operativa y organizativa.

TTY, scripting y robustez

  • Varias anécdotas sobre trabajos cron, sftp y herramientas que se comportan de forma distinta sin un TTY de control.
  • Entre las soluciones están script, screen, ssh -t, Paramiko y usar rsync en lugar de sftp.
  • Hay debate sobre si el análisis de TTY//proc y el scripting de shell son “triviales si lees el manual” o si, por naturaleza, están llenos de trampas; se invoca el principio de la menor sorpresa.

Acceso privilegiado y soluciones de más alto nivel

  • Algunos abogan por sistemas de gestión de acceso privilegiado, bastiones, VPN asociadas al usuario o certificados SSH de corta duración (por ejemplo, mediante Vault/Teleport) para evitar incrustar contraseñas por completo.
  • Otros advierten que estos productos pueden ser objetivos de alto valor y frágiles por sí mismos, y que un buen diseño de IAM/PAM puede ser más importante que añadir otra capa de proxy.