SSH e Telnet em automação: acesso remoto, chaves e migração segura
Compare SSH e Telnet pelo que trafega na rede, autenticação, chaves, algoritmos, salto administrativo, auditoria e estratégia segura para equipamentos legados.
Comparação operacional de acesso remoto
| Critério | SSH | Telnet / legado |
|---|---|---|
| Proteção em trânsito | Sigilo e integridade negociados | Sem proteção nativa |
| Identidade do servidor | Host key verificável | Não autenticada pelo protocolo |
| Usuário | Senha, chave e integração possível | Geralmente senha em claro no fluxo |
| Uso recomendado | Administração controlada | Exceção segmentada e temporária |
| Evidência | logs, host key e negociação | logs e captura altamente sensível |
O suporte nominal a SSH não basta; versões e algoritmos também precisam ser aceitos.
SSH e Telnet entregam terminal, mas não a mesma proteção
Telnet oferece um terminal virtual e negociação de opções, porém não protege nativamente credenciais e comandos contra observação ou alteração no caminho. SSH cria um transporte com negociação criptográfica, autentica o servidor, protege integridade e sigilo e oferece canais para terminal, execução e outros serviços. Trocar a porta 23 por outra não transforma Telnet em protocolo seguro.
Em automação, o risco não é apenas vazamento de senha. Um acesso administrativo pode mudar VLAN, lógica, firmware, relógio ou parâmetros de proteção. Por isso o fluxo deve partir de estação controlada ou bastion, atravessar zonas previstas e terminar em serviço explicitamente habilitado, com identidade individual e registro de ação.
O handshake SSH tem decisões verificáveis
Cliente e servidor negociam versões, troca de chaves, cifra, integridade e compressão. Depois o cliente valida a host key do servidor e autentica o usuário. Um alerta de chave alterada pode significar substituição legítima, reinstalação, IP reutilizado ou ataque; aceitar automaticamente apaga uma proteção central.
Mantenha inventário de host keys e procedimento de troca. Algoritmos antigos podem ser a única opção de um equipamento legado, mas não devem ser reabilitados globalmente no notebook. Quando a exceção for inevitável, limite-a a perfil, origem e janela específicos e planeje atualização ou compensação.
Senha, chave pública e conta de serviço
Senha individual com política adequada é melhor que credencial compartilhada, mas chaves públicas podem reduzir exposição quando protegidas e gerenciadas. A chave privada precisa de proteção, passphrase quando compatível, inventário, validade e revogação. Copiar a mesma chave para toda a equipe remove atribuição e amplia o impacto de perda.
Contas de automação devem ter comando e escopo mínimos. Uma rotina de backup não precisa de shell administrativo completo. Se o equipamento só oferece conta privilegiada única, registre a limitação, proteja o caminho e use controle compensatório no bastion e no cofre de credenciais.
Bastion e acesso de contingência
O jump server concentra entrada administrativa, MFA, ferramentas aprovadas e logs. Ele não deve virar ponto único sem backup, hardening e acesso break-glass. O desenho precisa impedir que uma sessão saltada abra túneis ou encaminhamentos não autorizados para outras zonas.
Conta local de emergência deve existir quando a indisponibilidade do AAA ou bastion impedir manutenção crítica, mas precisa de proteção, teste periódico e uso alarmado. Contingência não pode significar senha padrão permanente. Após uso, revise logs e renove segredo conforme procedimento.
Migração de Telnet sem perder capacidade operacional
Comece inventariando quem usa Telnet, para qual tarefa e a partir de onde. Confirme se firmware suporta SSH, quais algoritmos e se a configuração pode ser revertida localmente. Habilite SSH em paralelo, valide comandos, backup e recuperação; então restrinja Telnet por ACL antes de desabilitá-lo.
Equipamentos sem SSH podem ficar em zona protegida acessada por terminal server seguro, console serial ou bastion com controle rigoroso. O encapsulamento protege parte do caminho, não muda o trecho Telnet final; documente a fronteira. Substituição do ativo continua sendo a solução estrutural.
Timeout, keepalive e sessões abandonadas
Sessões administrativas ociosas devem expirar, mas um timeout curto demais pode interromper transferência ou manutenção. Diferencie keepalive de aplicação e TCP; manter sessão viva não comprova que o operador ainda está presente. Limite sessões simultâneas e revise comportamento após perda de rede.
Uma sessão órfã pode manter lock de configuração. Teste desconexão abrupta, reconexão e liberação de recursos. Se o equipamento não registra usuário e origem, o controle deve ser reforçado no acesso intermediário.
Diagnóstico por camada e por log
Se TCP não completa, verifique rota, ACL e porta. Se o banner aparece e a negociação falha, compare versões e algoritmos. Se a host key diverge, valide inventário antes de aceitar. Se autenticação falha, diferencie usuário, chave, horário, AAA e autorização. Se o shell abre sem comando permitido, a rede já funcionou; o foco é privilégio.
Capture apenas o necessário e proteja o arquivo. SSH esconde conteúdo, mas metadados e logs revelam handshake e encerramento. Em Telnet, a captura pode conter credenciais; trate como informação sensível e evite reproduzir em relatórios.
Comissionamento e recuperação
Valide host key, usuário individual, comandos autorizados, comandos negados, timeout, logs e origem. Teste perda do servidor AAA e acesso break-glass em ativo de laboratório ou janela aprovada. Exporte configuração antes de alterar serviços remotos e mantenha console local disponível.
Após migrar, confirme que porta Telnet foi realmente fechada, regras temporárias removidas e clientes atualizados. Revogue contas e chaves de teste. A evidência final deve mostrar acesso seguro e capacidade de recuperação, não apenas um prompt SSH.
Referências técnicas e normas
As explicações do Portal são autorais. Normas e fontes oficiais são priorizadas; materiais acadêmicos e documentação pública de fabricantes complementam a implementação e não substituem a edição normativa aplicável ao projeto.
- IEC 62443-3-3:2013 — System security requirements and security levels — IEC. Requisitos técnicos de segurança para sistemas de automação e controle industrial.
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security — NIST. Arquiteturas, ameaças e controles aplicáveis a ambientes OT.
- RFC 1122 — Requirements for Internet Hosts — Communication Layers — RFC Editor / IETF. Requisitos de IP, ICMP e camadas de comunicação em hosts.
- RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification — RFC Editor / IETF. Especificação vigente do IPv6.
- RFC 9110 — HTTP Semantics — RFC Editor / IETF. Semântica atual de métodos, campos e códigos HTTP.
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 — RFC Editor / IETF. TLS 1.3, handshake, autenticação e proteção do transporte.
- RFC 9325 — Recommendations for Secure Use of TLS and DTLS — RFC Editor / IETF. Recomendações atuais para versões, algoritmos e configuração TLS.
- RFC 4251 — The Secure Shell (SSH) Protocol Architecture — RFC Editor / IETF. Arquitetura SSH e separação entre transporte, autenticação e conexão.
- RFC 5424 — The Syslog Protocol — RFC Editor / IETF. Formato, facility, severity, timestamp e dados estruturados de Syslog.
- RFC 3411 — Architecture for Describing SNMP Management Frameworks — RFC Editor / IETF. Arquitetura do framework SNMP.
- RFC 3414 — User-based Security Model (USM) for SNMPv3 — RFC Editor / IETF. Autenticação e privacidade do SNMPv3 USM.
- IEEE 802.1AB-2016 — Station and Media Access Control Connectivity Discovery — IEEE Standards Association. LLDP e descoberta de conectividade em camada 2.
- RFC 4253 — The Secure Shell Transport Layer Protocol — RFC Editor / IETF. Negociação, autenticação do servidor, sigilo e integridade do SSH.
- RFC 854 — Telnet Protocol Specification — RFC Editor / IETF. Especificação do terminal virtual Telnet, sem proteção criptográfica nativa.
- RFC 959 — File Transfer Protocol — RFC Editor / IETF. FTP, canal de controle e conexões de dados.
- RFC 4217 — Securing FTP with TLS — RFC Editor / IETF. Uso explícito de TLS no FTP.
- RFC 1350 — The TFTP Protocol (Revision 2) — RFC Editor / IETF. Transferência simples sobre UDP, sem autenticação nativa.
Continue estudando
Os próximos conteúdos foram escolhidos para formar uma sequência técnica, relacionando fundamento, configuração, diagnóstico e aplicação.