Segurança · SSH · PAM · Acesso privilegiado · Atualizado em 20 ago. 2026

Acesso SSH temporário com software open source

Como sair de chaves estáticas e chegar a credenciais curtas, aprovação explícita e auditoria útil.

Chaves SSH resolvem autenticação, mas não resolvem sozinhas quem pode entrar, em qual servidor, com qual escopo e por quanto tempo. A arquitetura mais segura separa identidade, autorização JIT e evidência — porque “tem uma chave no servidor” não é exatamente uma política de acesso.

TL;DR Para humanos, o melhor candidato OSS estrito encontrado foi o Warpgate, com SSO, MFA, tickets e gravação de sessão. Para CI/CD e workloads, OpenBao SSH CA ou step-ca + OpenSSH emitem certificados temporários sem distribuir chaves estáticas. Teleport é tecnicamente completo, mas a Community Edition e os recursos Enterprise têm diferenças importantes de licença e funcionalidade.

Veredito rápido

Solução	O que ela é	JIT	Melhor uso	Leitura
Warpgate	Bastion/proxy	Tickets e solicitações	Operadores humanos e conexões não interativas	Primeiro piloto OSS estrito
OpenBao	Secret manager + SSH CA/OTP	TTL, lease e OTP	Máquinas, CI/CD e emissão controlada	Melhor building block
step-ca	CA online	Certificados curtos	OpenSSH, OIDC e identidade de workloads	Exige workflow ao redor
Teleport	Access plane	Completo em Enterprise; parcial na CE	Plataforma única para infraestrutura	Validar edição e licença
Open Bastion	Bastion + PAM/NSS	Grupos e certificados	SSO, sudo e contas Linux centralizados	Nicho interessante
FreeIPA/SSSD	Diretório + HBAC	Não nativo	Identidade Linux e política por host	Fundação, não produto JIT
Boundary	Proxy de acesso	Sim	JIT e credenciais por sessão	BSL 1.1: fora do OSS estrito

O modelo certo: identidade, autorização e credencial

Uma solução moderna não precisa transportar a chave privada do usuário para cada servidor. O padrão preferível é o cliente gerar uma chave efêmera localmente e receber um certificado assinado por uma CA confiável. O certificado carrega principal, validade e restrições; o SSHD só precisa confiar na CA e validar o certificado.[12][13]

Para humanos, isso deve ser combinado com SSO, MFA, RBAC e aprovação. Para sistemas, a identidade deve vir do workload — CI, Kubernetes, cloud ou outro mecanismo de attestation — e não de uma chave humana copiada para um pipeline.

Certificado curto não é workflow JIT. Um TTL de 30 minutos reduz a janela de abuso, mas não diz quem aprovou o acesso nem se o operador podia acessar aquele alvo. A CA cuida da credencial; o broker, o IdP e o workflow cuidam da decisão.

Warpgate: o candidato mais próximo de um produto pronto

Warpgate é um bastion transparente para SSH, Kubernetes, bancos e desktops remotos. A documentação e o repositório descrevem OIDC, TOTP, RBAC, clientes nativos, gravação e replay de sessões.[14][16][19]

O recurso mais alinhado ao requisito é o sistema de tickets: um administrador pode conceder acesso de um usuário a um alvo específico, com duração e quantidade de usos limitadas. O projeto também documenta solicitações de ticket, incluindo o caso de conexões não interativas em que um fluxo de MFA no momento da conexão não é conveniente.[15][17]

O código traz Apache-2.0 no arquivo de licença.[18][20] Isso o torna o candidato mais interessante quando “open source” significa usar todas as funções sem depender de uma camada Enterprise por tamanho da organização.

Bom para: acesso humano aprovado, fornecedores, suporte temporário e automações que precisam de um segredo com escopo.
Exigir no piloto: SFTP, SCP, `ProxyJump`, port-forwarding, multiplexação, clientes de CI e exportação das gravações.
Risco: o bastion implementa/proxyfica o protocolo SSH e se torna um componente crítico. Fazer threat modeling e revisar releases não é opcional.

OpenBao: credenciais efêmeras para pessoas e sistemas

O SSH secrets engine do OpenBao oferece dois modos: certificados SSH assinados e senhas SSH de uso único. O projeto é MPL-2.0 e trabalha com leases, renovação e revogação.[26][27][28][29]

No modo de certificado, a chave privada continua no cliente. O OpenBao assina a chave pública, a role define usuários, extensões e TTL, e os hosts confiam na CA por meio de `TrustedUserCAKeys`; a documentação usa uma role com TTL de 30 minutos como exemplo.[29][30]

No modo OTP, o servidor emite uma senha de uso único e um helper no host remoto valida o segredo durante o login. O OTP é consumido após o uso, e o fluxo é correlacionável ao lease e ao audit log do OpenBao.[31]

Limite importante: OpenBao é motor de emissão, política e lease; não é, por si só, um portal de aprovação JIT com reviewers e UI de solicitação. Para humanos, é preciso integrar autenticação, autorização e workflow externo.

Minha escolha para workloads: certificado SSH com TTL curto, principal explícito e autenticação do workload no OpenBao. OTP fica para legado; instalar um helper em todos os hosts e depender de uma validação online aumenta a superfície operacional.

step-ca + OpenSSH: CA especializada, broker por conta própria

`step-ca` é uma CA online Apache-2.0. O projeto documenta certificados SSH para pessoas autenticadas por SSO e para hosts autenticados por identidade de instância/cloud.[6][10]

Provisioners OIDC autorizam a emissão via um provedor de identidade; os tutoriais mostram o `step` CLI solicitando certificados SSH de curta duração.[7][8]

usuário ou workload gera uma chave efêmera;
autentica-se no provisioner apropriado;
solicita a assinatura da chave pública;
recebe certificado com principal e validade curta;
o SSHD valida CA, principal, validade e restrições.[12][13]

É uma solução limpa quando vocês querem manter o OpenSSH nos alvos e não obrigar o tráfego a passar por um bastion. A contrapartida é explícita: aprovação por ticket, reviewers, trilha de decisão, gravação e encerramento de sessão precisam ser construídos ao redor. O README do projeto separa UI administrativa, RBAC fino e integração profunda com IdP como capacidades comerciais.[10]

Teleport: completo, mas não confundir Community com Enterprise

Teleport usa autoridades certificadoras e certificados de curta duração para usuários e serviços. Os certificados SSH carregam principals, TTL e extensões, e expiram automaticamente.[3]

Na Community Edition, o fluxo documentado de Access Request é limitado a solicitações de roles via CLI, revisadas por um administrador com `tctl` no Auth Service. O fluxo completo de Just-in-Time Access Requests, incluindo solicitações por recurso e UI pesquisável, está documentado como Enterprise.[1][2]

O repositório principal está sob AGPL-3.0, mas a licença atual dos binários Community Edition impõe condições adicionais: organizações com menos de 100 empregados e menos de US$ 10 milhões de receita anual, salvo a exceção específica para patches críticos de segurança.[4][5]

Decisão de arquitetura e jurídica: Teleport pode ser a plataforma tecnicamente mais completa, mas não deve ser tratado como “OSS livre para qualquer empresa” sem revisar a licença da edição e os recursos que ficarão atrás de Enterprise.

Alternativas que completam ou não o requisito

Open Bastion

Open Bastion integra Linux ao LemonLDAP::NG com PAM/NSS. O SSO decide SSH e sudo, grupos concedem ou removem direitos, certificados assinados são usados no caminho do bastion para backends e sessões podem ser gravadas.[21][22][23] É interessante para substituir `authorized_keys`, contas e `sudoers` espalhados, mas eu o classificaria como governança Linux/SSO, não como workflow JIT completo.

FreeIPA/SSSD

FreeIPA fornece HBAC para restringir acesso a hosts e serviços por usuário, grupo e host, além de armazenar chaves SSH de usuários e hosts.[24][25] É uma ótima fundação para identidade Linux, grupos, sudo e política por ambiente. Não o escolheria sozinho para solicitação/aprovação JIT com ticket, TTL de minutos e uso único.

Boundary

Boundary oferece OIDC, acesso JIT a recursos e credenciais únicas por sessão via Vault.[32][33] Porém o repositório usa Business Source License 1.1, não uma licença OSI open source hoje.[34] Fica como comparativo técnico, não como candidato quando OSS é requisito formal.

Arquitetura que eu recomendaria

Uma divisão saudável: broker e aprovação para humanos; identidade de workload e certificado curto para sistemas.

Eu começaria com Warpgate para acesso humano e OpenBao SSH CA ou step-ca + OpenSSH para sistemas. Essa separação evita usar a mesma credencial, o mesmo fluxo e o mesmo blast radius para pessoas e máquinas.

Controles mínimos

Escopo: principal, host/serviço, ambiente e operações permitidas; evitar acesso amplo à rede.
TTL: humanos com validade curta e explícita; workloads com certificados ainda menores e renovação automática.
Restrições SSH: sem agent forwarding, port forwarding ou PTY quando não forem necessários; usar `force-command` quando o caso permitir.[12]
Aprovação: motivo, mudança/ticket, reviewer e proibição de autoaprovação em produção.
CA: chave privada fora dos hosts, backup protegido, rotação testada e acesso administrativo separado.
Auditoria: solicitação, aprovação, emissão, fingerprint/serial, alvo, conexão, comandos quando possível e encerramento.
Incidente: lembrar que expirar uma credencial não necessariamente mata uma sessão já estabelecida; prever lock/kill de sessão.
Break-glass: conta de emergência separada, protegida, monitorada e testada — não uma chave root esquecida no `authorized_keys`.

Plano de piloto

Inventariar as chaves atuais por proprietário, alvo, uso humano/máquina e último uso.
Escolher dez alvos não críticos: um caso de operador humano e um pipeline.
Testar Warpgate para humano e OpenBao/step-ca para pipeline, sem trocar toda a frota.
Validar expiração, renovação, revogação, clock skew, queda do IdP, SFTP/SCP, port-forwarding e rollback.
Enviar eventos de autorização e sessão ao SIEM antes de ampliar o escopo.
Migrar chaves de máquinas primeiro e remover as antigas somente após observar um ciclo real.
Fazer rotação da CA e um exercício de incidente antes de declarar a migração concluída.

Minha recomendação final: piloto comparativo Warpgate versus OpenBao/step-ca. Se a prioridade for experiência pronta para operadores, Warpgate vence. Se a prioridade for manter OpenSSH e emitir credenciais efêmeras para workloads, OpenBao ou step-ca vencem. Teleport entra como terceira opção apenas depois de resolver edição, recursos e licença.

Fontes consultadas

Pesquisa baseada em documentação e repositórios oficiais consultados em 20 de agosto de 2026. Licenças e recursos comerciais mudam; valide a versão exata antes de uma decisão de compra ou implantação.