Abrir um terminal SSH direto no navegador é prático: sem instalar cliente, sem configurar chave em cada computador, com acesso até pelo celular. A dúvida natural é: isso é seguro? A resposta curta: depende inteiramente de como a plataforma foi construída. Veja o que acontece por trás e o que você deve exigir.
Como funciona um terminal SSH web
O navegador não fala SSH diretamente. A arquitetura típica tem três partes:
- Navegador: exibe o terminal (normalmente com a biblioteca xterm.js) e envia o que você digita.
- Gateway da plataforma: recebe a conexão por WebSocket seguro (WSS) e abre a sessão SSH real com o servidor.
- Seu servidor: recebe uma conexão SSH comum, criptografada como qualquer outra.
Ou seja, o ponto crítico é o gateway: é ele que guarda as credenciais e decide quem pode abrir cada sessão.
Os riscos reais
- Vazamento de credenciais se a plataforma armazenar senhas em texto puro ou enviá-las ao navegador.
- Sequestro de conta: sem 2FA, quem descobre sua senha do painel ganha acesso a todos os servidores.
- Acesso entre clientes (cross-tenant) em plataformas que não isolam corretamente os dados de cada conta.
- Sessões reaproveitáveis: URLs ou tokens de conexão que continuam válidos depois de usados.
- Falta de rastreabilidade: não saber quem executou o quê, e quando.
Checklist: 7 controles que a plataforma precisa ter
| # | Controle | Por que importa |
|---|---|---|
| 1 | Credenciais criptografadas em repouso | Um vazamento do banco não expõe suas senhas e chaves. |
| 2 | Credenciais nunca enviadas ao navegador | Extensões maliciosas ou XSS não conseguem capturá-las. |
| 3 | HTTPS + WSS em todo o trajeto | Nada trafega em texto puro. |
| 4 | 2FA obrigatório | A senha do painel sozinha não basta para invadir. |
| 5 | Ticket de sessão de uso único e curta duração | Um link copiado ou interceptado não abre outra sessão. |
| 6 | Isolamento por conta e permissões por servidor | Cada usuário só alcança o que é seu ou foi compartilhado com ele. |
| 7 | Auditoria de comandos | Rastreabilidade para incidentes e conformidade. |
Como o EzServer implementa cada ponto
- Senhas e chaves SSH ficam criptografadas e são usadas somente no servidor da plataforma.
- Para abrir o terminal, o navegador ou o app recebe um ticket de uso único, válido por poucos instantes, e não as credenciais.
- Autenticação em dois fatores protege a conta.
- Compartilhamento por servidor: colaboradores usam a própria conta e nunca veem a senha.
- Os comandos ficam registrados em log de auditoria.
- Conexões com keepalive e reconexão automática; com tmux, a sessão é retomada de onde parou.
Boas práticas no seu servidor
A plataforma é uma camada; o servidor também precisa estar protegido:
# /etc/ssh/sshd_config
PermitRootLogin prohibit-password # root só com chave
PasswordAuthentication no # quando todos usarem chave
MaxAuthTries 3
ClientAliveInterval 60Complete com fail2ban para bloquear tentativas de força bruta e mantenha o sistema atualizado (apt update && apt upgrade).
Resumo: o terminal no navegador não é menos seguro que o SSH local, desde que as credenciais não saiam do servidor da plataforma, a conta tenha 2FA e cada sessão use um ticket descartável.