War Stories #06: O Bloqueio Fantasma de SSH Pós-Upgrade no Cisco ACI 6.x

A janela de manutenção (Gemud) está na reta final. O cluster APIC atualizou e está cravado como Fully Fit. Os switches Spines e Leafs (Nexus 9K) processaram a imagem de 64 bits, reiniciaram com sucesso e o tráfego do Data Plane voltou ao normal.

O ping da rede de gerência (Out-of-Band) para os Leafs responde lindamente a <1ms. Tudo parece perfeito.

Então, você abre o seu terminal na máquina Windows para entrar no Border Leaf e validar o estado do BGP na CLI.

“Connection reset by peer” ou “Server refused key”.

Você tenta novamente. Nada. O acesso SSH está morto a partir do seu desktop. No entanto, se você abrir o SSH por dentro do próprio APIC, o acesso ao switch funciona em milissegundos. O que quebrou?

Bem-vindo à segurança arquitetural da versão 6.x. O seu Fabric não está com defeito; ele apenas evoluiu, e o seu desktop ficou para trás.

---

O Abismo do OpenSSH no NX-OS 10.x

Quando atualizamos o Cisco ACI da família 5.x para a 6.x (neste caso, a 6.1(5e)), não estamos apenas mudando a interface gráfica. O sistema operativo base que corre sob o capô dos Leafs e Spines dá um salto para o NX-OS 10.x. E com esse salto, vem uma atualização massiva no servidor OpenSSH embutido no hardware.

Por forte pressão da indústria de cibersegurança e normas de Compliance globais, a Cisco cortou o mal pela raiz e desativou o suporte a cifras legadas e inseguras.

O principal alvo dessa purga foi o algoritmo de assinatura ssh-rsa (que utiliza o hash SHA-1, já considerado criptograficamente quebrado), além de algoritmos antigos de troca de chaves (Key Exchange), como o Diffie-Hellman Group 1 ou 14 clássicos.

O Diagnóstico: Por que o APIC acessa e o Desktop não?

Este é um problema clássico de Cipher/Host Key Mismatch (Falha de negociação de criptografia).

1. A Visão do APIC: Os seus APICs também foram atualizados. O Linux interno deles agora possui um cliente SSH modernizado. Quando o APIC inicia uma sessão para o Leaf, eles negociam silenciosamente algoritmos robustos (como rsa-sha2-256, aes256-ctr ou ecdsa). A comunicação flui porque ambos falam a linguagem da segurança moderna.
2. A Visão do seu Desktop: Se você ou o seu squad de NOC estão usando uma versão do PuTTY instalada há dois anos, ou um MobaXterm/SecureCRT desatualizado, esse cliente vai bater na porta do Leaf oferecendo o velho ssh-rsa como “cartão de visitas”. O servidor OpenSSH do Nexus 9K olha para o SHA-1, recusa imediatamente a conexão e derruba a sessão na camada de transporte, antes mesmo de pedir o login.

A Solução de Arquiteto (O que NÃO fazer)

O instinto de muito analista de Nível 2 ao ver isso é correr para o APIC e tentar criar uma política (Management Access Policy) para enfraquecer o servidor SSH do switch, forçando-o a aceitar o protocolo legado apenas para o acesso voltar a funcionar.

Não faça isso. Rebaixar a postura de segurança da sua infraestrutura de missão crítica para acomodar um software desatualizado no seu computador é um erro grave de arquitetura.

A solução correta, rápida e definitiva é atualizar o cliente.

• Se você usa PuTTY: Atualize para a versão 0.78 ou superior. A partir dessa versão, o PuTTY passou a suportar e priorizar nativamente o rsa-sha2-256. O acesso volta a ser instantâneo.
• Se usa SecureCRT / MobaXterm: Garanta que está na última release estável com suporte a SHA-2 e ECDSA.
• Terminal Linux / Windows Nativo: Atualize os pacotes do OpenSSH Client.

Lição da Madrugada

Em operações Day-2 de Data Center, os problemas mais assustadores pós-upgrade raramente são falhas de hardware ou bugs de roteamento; geralmente, são mecanismos de proteção rígidos que não compreendíamos totalmente.

A arquitetura moderna exige clientes modernos. Mantenha as suas ferramentas de troubleshooting tão atualizadas quanto os ASICs que você opera.