Autenticação por senha SSH não interativa

Artigo original ↗ Discussão no Hacker News ↗

Automatizar conexões SSH que exigem senha continua sendo controverso, com alguns engenheiros confiando felizmente em ferramentas como `sshpass`, enquanto outros argumentam que essas abordagens são frágeis porque dependem da interpretação de prompts e de um comportamento de TTY instável. Muitos participantes insistem que autenticação por chave pública ou certificada, Kerberos ou certificados SSH de curta duração são mais seguros e escaláveis, mas reconhecem que hardware de rede legado, configurações TACACS/RADIUS e restrições de fornecedores muitas vezes deixam o SSH apenas com senha como a única opção prática. A conversa se amplia para como gerenciar acesso privilegiado em escala — via automação de configuração, produtos PAM, bastions ou agentes personalizados — destacando as compensações entre segurança, complexidade e confiabilidade em infraestruturas do mundo real.

Abordagens de autenticação por senha SSH não interativa

  • Muitos comentaristas argumentam que a autenticação por senha no SSH deve ser evitada; chaves/certificados são preferidos, e alguns desativam completamente os logins por senha.
  • Outros observam que a autenticação por senha não interativa é inevitável com certos dispositivos de rede, BMCs, caixas de fornecedores, configurações TACACS+/RADIUS ou provisionamento inicial em que apenas senhas estão disponíveis.
  • Alguns estão explorando a automação de SSH baseado em OTP/TOTP, mas receitas concretas e robustas não são detalhadas.

sshpass vs alternativas (passh, ASKPASS, expect)

  • Várias pessoas dizem que sshpass é “bom o suficiente”, citando uso em grande escala (dezenas de milhares de máquinas) sem problemas e elogiando sua simplicidade.
  • Críticos apontam que sshpass é frágil porque faz parsing dos prompts de senha; mudanças nos prompts ou no comportamento do TTY podem quebrá-lo.
  • Um padrão alternativo é usar SSH_ASKPASS e SSH_ASKPASS_REQUIRE (em clientes OpenSSH mais novos) para injetar senhas de forma mais controlada, possivelmente tornando ferramentas extras mais simples ou desnecessárias.
  • A ferramenta passh é citada como mais robusta no tratamento de TTY; a acusação de “quebrado por design” contra o sshpass vem desse projeto, não do autor do artigo.
  • Ferramentas tradicionais como expect são mencionadas; elas são poderosas, mas podem ser frágeis, especialmente sob cron ou sem um TTY real.

Chaves, certificados e restrições do mundo real

  • Os comentaristas reiteram que chaves/certificados são “o jeito certo”, mas descrevem obstáculos:
    • Equipamentos de rede (por exemplo, algumas variantes Cisco/Juniper, dispositivos Ubiquiti) em que a configuração de chaves é desajeitada ou não persistente.
    • Autenticação central via TACACS+/RADIUS muitas vezes projetada em torno de senhas, com suporte a chaves limitado ou ad hoc.
    • Muitos stacks SSH embarcados não têm recursos modernos como FIDO2.
  • Alguns sugerem certificados SSH, Kerberos ou FreeIPA, mas reconhecem a complexidade operacional e organizacional.

TTY, scripting e robustez

  • Várias histórias sobre trabalhos em cron, sftp e ferramentas que se comportam de forma diferente sem um TTY de controle.
  • As soluções incluem script, screen, ssh -t, Paramiko e rsync em vez de sftp.
  • Há debate sobre se parsing de TTY e /proc e shell scripting são “triviais se você ler o manual” ou inerentemente cheios de armadilhas; o princípio da menor surpresa é levantado.

Acesso privilegiado e soluções de nível superior

  • Alguns defendem sistemas de gerenciamento de acesso privilegiado, bastions, VPNs associadas ao usuário ou certificados SSH de curta duração (por exemplo, via Vault/Teleport) para evitar incorporar senhas de todo.
  • Outros alertam que esses produtos podem, por si só, ser alvos de alto valor e frágeis, e que um bom design de IAM/PAM pode ser mais importante do que adicionar outra camada de proxy.