SSH

Capturado em 2026-07-28 de um CE desta implantação. sitecli/capture-manifest.json registra qual nó, e scripts/capture-sitecli.sh --check reverifica a superfície de comandos em um CE ativo.

O SSH alcança a conta admin do appliance, cujo shell de login é o Site CLI (/opt/bin/vpmu). Esta é a única rota para a superfície completa de comandos no appliance — a API de debug expõe 34 comandos, e o próprio appliance oferece muito mais que não estão nessa API.

cd terraform
SLI=$(terraform output -json ce_sli_private_ips | jq -r '.eastus01')
ssh -tt -i ~/.ssh/id_ed25519 -J azureuser@<operator-vm> "admin@$SLI"

Cada parte dessa linha de comando é indispensável, e as próximas três seções explicam qual falha cada uma previne.

Não há prompt de shell ao qual chegar: o shell de login de admin é o Site CLI, portanto você chega ao seu prompt >>>. Execute comandos no appliance como execcli <nome> ali — consulte comandos no appliance.

Consulte o endereço interno — nunca reutilize um de uma sessão anterior

O Azure reatribui a sub-rede interna a cada reconstrução, e não na ordem dos nós. Após a reconstrução mais recente, f5-xc-ce-vm-01, -02 e -03 têm 10.0.3.7, 10.0.3.5 e 10.0.3.4; uma build anterior os tinha em uma ordem completamente diferente, e a NIC do cliente de teste está na mesma sub-rede e já teve um endereço que um CE havia ocupado antes. Conectar-se a um endereço memorizado, portanto, resulta no nó errado, em uma VM que não é um CE, ou em lugar nenhum — e o último desses casos é idêntico a “SSH não está habilitado”.

terraform output -json ce_sli_private_ips é o mapeamento. Sem o estado disponível, o nome da NIC é estável mesmo que o endereço não seja:

az network nic show -g "$(terraform output -raw resource_group_name)" \
  -n "$(terraform output -json ce_vm_names | jq -r '.eastus01')-internal-nic" \
  --query ipConfigurations[0].privateIPAddress -o tsv

Apenas na inicialização — um CE existente não pode ganhar SSH sem ser recriado

O write_files do cloud-init é executado uma vez, na primeira inicialização. Depois disso, um marcador /etc/cloud/cloud-init.disabled existe no nó e o cloud-init não é executado novamente.

Portanto, não há caminho local em um CE em execução. custom_data é somente substituição no Azure, o que significa que adotar isso em uma implantação existente substitui todas as VMs dos CEs. Conceder SSH de operador a nós já ativos é uma reconstrução, não uma mudança de configuração — e o próximo aviso descreve o que essa reconstrução costumava custar, e por que isso não ocorre mais.

Substituir uma VM de CE costumava travar o registro permanentemente — isso foi corrigido, e é por isso que o objeto do site está acoplado à VM

Vale saber antes de planejar uma reconstrução, porque a forma da falha explica o acoplamento que você verá no plano.

Antes, o registro do nó destruído mantinha o índice único (tenant, cluster_name, hostname) do plano de controle, de modo que o registro do nó substituto era recusado com UniqueSecondaryIndexViolationError e repetido indefinidamente. Excluir o registro não era suficiente por si só: um StatusObject remanescente então retornava 500 para a solicitação de workload, e nesse ponto cada nó havia persistido um registration-obj.yml vinculando-o ao registro que você excluiu, então ele entrava em loop em 404 sem autorrecuperação. A recuperação exigia duas reconstruções completas. Durante todo esse processo, o terraform plan reportava “No changes”, porque do ponto de vista do Terraform o estado desejado havia sido atingido.

A Issue 674 está fechada, por meio da PR 693. modules/xc-site agora nomeia a instância da VM do CE em replace_triggered_by, de modo que substituir a VM substitui o objeto do site, e excluir um site leva seus registros consigo — a chave do índice fica livre antes da inicialização do nó substituto. A frota foi reconstruída do zero desde então e os três sites ficaram ONLINE sem intervenção.

O acoplamento é observável, não presumido. Cada site está vinculado a um id de instância de VM, e o registro correspondente reporta o mesmo valor que infra.instance_id:

cd terraform && terraform output -json ce_bound_instance_ids

Discordância entre os dois significa que um site ainda está vinculado a um nó que não existe mais, que é o estado do qual um CE reconstruído nunca consegue se registrar. Ler a metade do registro ainda requer uma chamada direta à API — a issue 1376 do provider é o que colocaria isso na fonte de dados.

Por que o cloud-init escreve a chave, e não a API

admin_user_credentials.ssh_key no objeto do site parece exatamente o campo para isso. Ele é aceito, sobrevive a uma releitura e não configura nada. O vpm controla os usuários locais do nó e recusa-se a alterar este — do próprio log do nó, três vezes durante uma única inicialização:

vpm  users.go:165: Won't do any change for user admin (internal skip)

Tudo o mais decorre dessa única linha. /var/home/admin/.ssh nunca existe, antes ou depois de o site atingir ONLINE. A data da última alteração da shadow de admin permanece na data de build da imagem enquanto vesbkp e vesopcon mostram a data atual, porque o vpm configurou esses dois e pulou o admin. E o vpm não registra nada sobre ssh_key ou authorized_keys em nenhum momento.

Portanto, o arquivo precisa ser escrito fora do vpm. admin é uid 2202, incorporado na imagem do nó, de modo que ele existe antes da execução do cloud-init e owner: admin:admin é resolvido no momento da escrita — sem runcmd, sem correção de propriedade:

- path: /var/home/admin/.ssh/authorized_keys
  permissions: "0600"
  owner: admin:admin
  content: |
    ${ssh_public_key}

O sshd sempre esteve disposto. sshd -T reporta pubkeyauthentication yes, e admin aparece em AllowUsers nos dois arquivos sshd_config que acompanham o nó. Nunca houve nada para habilitar — apenas um arquivo ausente.

Não re-adicione admin_user_credentials e não edite sshd_config

admin_user_credentials foi integrado em terraform/modules/xc-site e revertido assim que esta evidência foi coletada (#660, PR #663). Não é uma lacuna aguardando preenchimento.

sshd_config é substituído durante o registro, portanto uma edição nele é descartada no momento mais inconveniente.

Por que ele responde em apenas um endereço

O sshd vincula 0.0.0.0:22, mas apenas o endereço interno (SLI) está na pilha de rede do host de uma forma que o sshd responderá. eth0 é renomeado para a-i-eth0 e não carrega nenhum IP do host — o plano de dados Argo é dono dessa interface, e o endereço de gerenciamento/SLO que ele teria carregado aparece em vhost0 em vez disso. As outras duas NICs permanecem na pilha do host com seus próprios nomes.

Sondado a partir de uma VM dentro da VNet, em relação a um CE:

endereço de gerenciamento/SLO    timeout
endereço externo                 timeout
endereço interno/SLI             ABERTO   SSH-2.0-OpenSSH_8.7
um endereço não utilizado        timeout  (controle)

Uma sondagem em relação ao endereço pelo qual você conhece o nó, portanto, retorna exatamente o que um security group fechado retorna. Nada está bloqueando; não há listener nesse endereço.

Não leia o nome da interface do guest para descobrir em qual sub-rede você está

Qual das interfaces eth1 e eth2 carrega o endereço interno difere entre os nós desta mesma implantação. Lido ao vivo dos três CEs:

f5-xc-ce-vm-01    eth1 -> externo     eth2 -> interno/SLI
f5-xc-ce-vm-02    eth2 -> externo     eth1 -> interno/SLI
f5-xc-ce-vm-03    eth1 -> externo     eth2 -> interno/SLI

Apenas dois aspectos se mantêm em todos os nós: a-i-eth0 não tem endereço, e vhost0 carrega o endereço de gerenciamento/SLO. Para qualquer outra coisa, faça a correspondência pelo endereço na saída de ip addr em vez de pelo nome da interface.

Os endereços públicos dos CEs também não têm listener na porta 22, e é por isso que o comando acima usa -J: uma VM de operador dentro da VNet, na mesma sub-rede que os endereços SLI. Esta implantação constrói uma para esse fim — terraform output -raw client_vm_name fornece o nome dela.

-J não passa suas opções para o trecho do salto

As opções fornecidas na linha de comando se aplicam ao salto final. -o UserKnownHostsFile=/dev/null junto com -J ainda consulta e escreve seu known_hosts real para o host de salto, o que é a surpresa se você está tentando manter uma frota reconstruída fora dele. Detalhe o primeiro salto quando isso importar:

ssh -tt -o ProxyCommand="ssh -W %h:%p -o UserKnownHostsFile=/dev/null azureuser@<operator-vm>" \
    -o UserKnownHostsFile=/dev/null -i ~/.ssh/id_ed25519 "admin@$SLI"

Dois erros de medição que produzem respostas erradas com confiança

Sondar eth0, a interface externa ou o endereço público na porta 22 reporta fechado independentemente do estado SSH do nó, portanto não fornece nenhuma informação. Apenas o endereço SLI responde.

E uma sondagem a partir de uma estação de trabalho corporativa pode reportar uma porta aberta que está fechada: o Netskope completa o handshake TCP por conta própria em portas comuns. As portas 80 e 443 aparecem como abertas nos endereços públicos do CE a partir de uma estação de trabalho e estão fechadas quando sondadas de dentro da VNet. Sonde a partir de uma VM na VNet.

O Site CLI precisa de um terminal e de um retorno de carro

O shell de login de admin não é um shell. É uma aplicação go-prompt, que coloca o terminal em modo raw e lê teclas em vez de linhas. Quatro consequências, cada uma das quais falha de um modo que parece um problema diferente:

Mecanismo	O que acontece sem ele
Alocar um terminal (ssh -tt)	panic: no such device or address do go-prompt.NewStandardInputParser, que parece um appliance com falha
Enviar um retorno de carro, não uma alimentação de linha, para Enter	A linha nunca é submetida, e a sessão fecha ao fim da entrada sem ter imprimido nada
Manter a entrada padrão aberta	A conexão termina antes de o comando ser renderizado, então um comando funcionando parece silencioso
Escrever o texto do comando e o byte Enter separadamente	A nova linha chega ao buffer como um caractere literal e o CLI responde unknown command, o que parece indicar que o comando não existe

ssh host 'some-command' portanto não funciona: o argumento é ignorado e o prompt interativo inicia de qualquer forma. Use-o como terminal ou não use. scripts/sitecli_ssh_harvest.py é a implementação de referência.

Um panic com 'no such device or address' significa que a autenticação TEVE ÊXITO

O vpmu o emite após o login, quando não encontra terminal para se conectar. Lido como uma falha, parece o pior resultado possível, e na verdade é o último erro antes do sucesso. Adicione -tt e conecte-se novamente.

A chave de host de um CE muda por dois motivos diferentes

A próxima conexão avisa REMOTE HOST IDENTIFICATION HAS CHANGED e recusa. Limpe a entrada antiga para aquele endereço e reconecte. Dois eventos a desencadeiam:

• Substituição do nó. O substituto apresenta uma chave diferente no mesmo endereço. Como conceder SSH substitui as VMs, espere isso na primeira conexão após adotá-lo.
• Uma atualização de sistema operacional no local, sem nenhuma substituição. Observado em 2026-07-28: um nó cuja atualização de ce_os_version foi concluída apresentou uma nova chave de host no mesmo endereço, na mesma máquina virtual.

StrictHostKeyChecking=accept-new não ajuda em nenhum dos casos. Ele aceita chaves para hosts que nunca foram vistos; uma chave modificada é exatamente o que ele recusa. Apenas remover a entrada obsoleta resolve.

Os endereços também podem mudar. Recriar uma implantação os reatribui da mesma sub-rede, de modo que um CE e um jump host podem acabar trocando de endereço — após o que uma entrada obsoleta não está apenas desatualizada, mas associada à máquina errada.

O banner é uma verificação de saúde gratuita

Antes de você digitar qualquer coisa, o banner de login já respondeu a várias das perguntas nas quais você gastaria comandos. De f5-xc-ce-vm-01, arte ASCII e IP público omitidos:

UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED
All actions performed on this device are audited

Using https://register.ves.volterra.io
OS: rhel-9.2024.6
Memory: 32768MiB
Storage: sda: 31GiB
CPU: Model: Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz | CPUs: 8
Software: crt-20250613-3382
DNS: 168.63.129.16: OK
NTP: Synced
Uptime: 0 days, 5 hours, 20 minutes
Registration Status: PROVISIONED
SLO IP: 10.0.1.4/26
WELCOME IN SITE CLI

Registration Status distingue um nó ainda inicializando (PROVISIONING) de um que concluiu (PROVISIONED). Software é a string de build que determina quais comandos existem. DNS e NTP cobrem as duas dependências que quebram o registro primeiro, portanto um nó que nunca ficou online geralmente já informou aqui o motivo — antes de chronyc-sources ou dig serem necessários.

Fornecendo o par de chaves

1. Gere um par de chaves, caso ainda não tenha um. Ed25519 em vez de RSA: mais curto e aceito pelo sshd do appliance.

   ssh-keygen -t ed25519 -C "ce-operator" -f ~/.ssh/id_ed25519

2. Aponte a implantação para a metade pública. O módulo raiz lê o arquivo uma vez e passa a string para cada nó:

   terraform/terraform.tfvars

   ssh_public_key_path = "~/.ssh/id_ed25519.pub"

   ssh_public_key recebe o material diretamente, que é o que os testes de plano usam. A metade privada nunca sai da sua estação de trabalho.

3. Aplique. Leia o aviso no topo desta página primeiro — em uma implantação existente, isso substitui as VMs dos CEs.

O admin_ssh_key da própria VM é uma coisa diferente

azurerm_linux_virtual_machine.admin_ssh_key em modules/ce-node autoriza o administrador da VM do Azure, não a conta admin do appliance. Ele não concede acesso ao Site CLI, e tê-lo configurado não é evidência de que o SSH do CE está configurado.

O que isso não é

Cada um desses foi testado e descartado enquanto a rota ainda era considerada impossível. Cada um é plausível o suficiente para custar um dia.

Não é a causa	Como foi descartado
A credencial só se aplica no momento da criação	O sshd inicia cerca de 90 segundos na primeira inicialização, antes de o objeto do site existir. admin_user_credentials também está presente em ReplaceSpecType e se aplica no local.
block_all_services	O fechamento da porta 22 no endereço de gerenciamento é idêntico seja os serviços bloqueados ou não.
Uma nova linha no final da chave	Testado de ambas as formas, sem alteração. O cloud-init ainda a remove, porque um bloco literal de outra forma renderizaria uma segunda linha vazia.
Software de CE fixado em versão mais antiga	Reproduzido em três builds, incluindo um executando OpenSSH 9.9.
Uma admin_password ausente	Definir admin_password junto com ssh_key em um CE criado do zero não alterou nada.

Dois campos da API que parecem discriminadores e não são

gc_spec.admin_ssh_key está vazio ou ausente em todos os 58 sites em f5-sales-demo — incluindo os dois que definem admin_user_credentials.ssh_key. Comparar isso entre um site funcionando e um não funcionando não fornece nenhuma informação, porque ele aparece vazio mesmo nos sites em que a credencial está configurada.

registrations_by_site omite o campo completamente e retorna None para ele, o que parece “não configurado” em vez de “não reportado”.

As outras rotas

API de DebugProgramável, não requer acesso dentro da VNet e é a escolha certa para evidências reproduzíveis. Cobre 34 comandos e requer o site ONLINE.

Console do SiteUI de solução de problemas de nós da F5 por meio de um túnel Azure Bastion. Sem chave, sem jump host, e responde antes de o site se registrar.

Console serialPara um nó que nunca se registrou ou não tem caminho de rede funcionando. Requer um terminal ou o harness websocket.

Um site recém-criado precisa de cerca de meia hora antes de a API de debug responder

Por aproximadamente 25 a 30 minutos após um novo site reportar ONLINE, os endpoints vpm/debug retornam uma página 503 do BIG-IP com a mensagem The requested URL was rejected. Isso parece um bloqueio de firewall de aplicação web, ou um token revogado, e não é nenhum dos dois: o site ainda não está pronto para retransmitir. Aguarde e tente novamente em vez de alterar qualquer coisa.

O SSH não tem esse período de aquecimento. Ele responde assim que o sshd está ativo, e é por isso que é a rota que funciona enquanto um nó ainda está se registrando.