M5Cardputer-SSHClient

A pergunta que me levou a esse repositório não foi "dá para rodar SSH num microcontrolador?". Dá, e isso já foi provado por outras pessoas. A pergunta foi: quanto do que eu tomo como garantido num cliente SSH desaparece quando a máquina tem algumas centenas de KB de RAM, uma tela minúscula e um teclado de 56 teclas?

O M5Cardputer, da M5Stack, é um alvo bom para essa pergunta. É um ESP32 com Wi-Fi, teclado físico, tela e bateria, tudo num formato de cartão. Ele já é usado como brinquedo de hardware e como ferramenta de bancada; um shell remoto nele vira algo prático: checar um serviço no homelab, reiniciar um container, ler um log, sem tirar o notebook da mochila.

O repositório é declaradamente um experimento. Ele está no meu portfólio na trilha de embarcados, IoT e ferramentas de desenvolvedor, ao lado de projetos de arquitetura em nuvem, porque o raciocínio é o mesmo: entender o custo real de cada camada quando o recurso é escasso. Não trate como produto pronto. Trate como ponto de partida bem delimitado para quem quer um terminal remoto no Cardputer e prefere ler o código a começar do zero.

A arquitetura cabe em quatro peças, e nenhuma delas sai do dispositivo.

Entrada: o firmware lê o teclado matricial do Cardputer e converte cada tecla em caractere. Sem teclado completo, combinações como Ctrl+C e setas dependem de mapeamento por tecla de função; é aí que a experiência mais difere de um terminal comum.

Rede: o ESP32 conecta no Wi-Fi e abre uma conexão TCP com o host, normalmente na porta 22. Não há servidor intermediário: se o seu notebook alcança o host, o Cardputer na mesma rede também alcança.

Sessão SSH: o handshake, a troca de chaves e a cifra rodam no próprio ESP32. É a parte mais cara em CPU e memória, e a razão de eu chamar isso de experimento: algoritmos pesados de troca de chave aumentam o tempo de conexão de forma perceptível num microcontrolador.

Saída: o texto devolvido pelo shell é desenhado na tela. Numa tela desse tamanho cabem poucas colunas, então comandos com saída larga, como htop ou docker ps sem formatação, quebram linha ou ficam ilegíveis. Comandos curtos e saída filtrada com tail, grep ou --format funcionam bem.

Confira no código a biblioteca SSH e a versão do pacote de placas usadas; elas definem quais algoritmos de chave e cifra o cliente aceita.

Ser honesto sobre o que não funciona é a parte mais útil de um experimento.

Programas de tela cheia: vim, htop e tmux dependem de um emulador de terminal com sequências de escape completas e de uma janela de pelo menos 80 colunas. Numa tela de 240 por 135 pixels isso não cabe, então espere ver caracteres de controle ou layout quebrado.

Tempo de conexão: a troca de chaves num microcontrolador leva segundos, não milissegundos. Para uso pontual é aceitável; para abrir e fechar sessão dezenas de vezes, não.

Algoritmos aceitos: servidores OpenSSH recentes desabilitam algoritmos antigos por padrão. Se o handshake falhar, o primeiro lugar a olhar é o /var/log/auth.log do host, que diz qual algoritmo foi recusado.

Validação de host: num cliente de bolso, conferir a chave do servidor é fácil de esquecer e é exatamente o que separa SSH de telnet cifrado. Verifique no código se o fingerprint é checado antes de usar fora da sua rede.

O repositório segue as convenções do platform, o mesmo que governa os meus outros projetos.

Branch: <tipo>/<escopo>, com feat/, fix/, chore/ ou docs/.

Commit e título de PR: Conventional Commits. Não é preciosismo: a versão sai dos commits, e ninguém escreve número de versão à mão.

Pipeline: pr-lint, CI, segurança e release vêm dos workflows reutilizáveis do platform. Se a régua estiver errada, a correção é num arquivo lá, não aqui. Manter uma esteira por repositório parece barato no primeiro dia e custa caro no vigésimo repositório, quando cada um diverge um pouco.

Contribuições que mais ajudariam: mapeamento de teclas especiais, rolagem de saída na tela e verificação explícita de fingerprint do host.