SSH é o acesso remoto seguro a shells e túneis. Use chaves (ed25519), desative login por senha, restrinja usuários e considere bastion/SSM em vez de SSH aberto à internet.
Agent forwarding e ProxyJump ajudam em topologias com bastion. Audite chaves autorizadas. Para automação, prefer service users com comandos limitados ou certificados SSH de curta duração.
Em ambientes reais, SSH aparece junto de decisões de arquitetura, custo e operação. Vale documentar no runbook do time: quando usar, quando evitar, métricas de saúde e o que fazer quando falha. Links internos do hub (comandos, erros, comparativos) ajudam a fechar o ciclo entre teoria e prática.
Antes de adotar em produção, monte um teste com dados reais do seu contexto — benchmarks genéricos raramente capturam latência, volume e casos de borda do seu sistema. Prefira evoluir em fatias pequenas, com observabilidade e critério de rollback claros.
Se você está desenhando a solução pela primeira vez, comece pelo caminho mais simples que atende o requisito e só adicione complexidade (mais serviços, mais abstrações) quando a dor for medida, não imaginada.
Em produção, decisões envolvendo SSH afetam custo, latência e confiabilidade. Vale registrar no runbook: pré-requisitos, sinais de degradação e passos de mitigação. Sem isso o conhecimento fica concentrado em poucas pessoas.
Antes de escalar o uso, valide com dados reais do seu ambiente. Benchmarks públicos ajudam a filtrar opções, mas não substituem um teste com o volume e o perfil de tráfego que você tem. Prefira mudanças pequenas e observáveis a grandes reescritas sem métrica de sucesso.
No hub IRN Devs você encontra comandos, erros e comparativos que complementam este verbete — use-os para fechar o ciclo entre definição e operação do dia a dia.