SSH

Erfasst am 28.07.2026 von einem CE dieser Bereitstellung. sitecli/capture-manifest.json enthält den betreffenden Knoten, und scripts/capture-sitecli.sh --check überprüft die Befehlsoberfläche erneut gegen einen laufenden CE.

SSH erreicht das Appliance-Konto admin, dessen Login-Shell die Site CLI ist (/opt/bin/vpmu). Dies ist der einzige Zugang zur vollständigen On-Box-Befehlsoberfläche — die Debug-API stellt 34 Befehle bereit, während die Appliance selbst viele weitere anbietet, die in dieser API nicht vorhanden sind.

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"

Jeder Teil dieser Befehlszeile ist wesentlich. Die nächsten drei Abschnitte erläutern, welchen Fehler jeder Teil verhindert.

Es gibt keine Shell-Eingabeaufforderung, auf der man landet: Die Login-Shell von admin ist die Site CLI, sodass man direkt an deren >>>-Eingabeaufforderung landet. Führen Sie On-Box-Befehle dort als execcli <name> aus — siehe On-Box-Befehle.

Die interne Adresse immer nachschlagen — niemals eine Adresse aus einer früheren Sitzung übernehmen

Azure weist das interne Subnetz bei jedem Neuaufbau neu zu, und zwar nicht in Knotenreihenfolge. Nach dem letzten Neuaufbau halten f5-xc-ce-vm-01, -02 und -03 die Adressen 10.0.3.7, 10.0.3.5 bzw. 10.0.3.4; ein früherer Build hatte sie in einer anderen Reihenfolge, und die NIC des Testclients befindet sich im selben Subnetz und hat bereits eine Adresse gehalten, die ein CE zuvor hatte. Eine gespeicherte Adresse zu verwenden landet daher auf dem falschen Knoten, auf einer VM, die kein CE ist, oder nirgendwo — und der letzte Fall sieht identisch aus wie „SSH ist nicht aktiviert”.

terraform output -json ce_sli_private_ips ist die Zuordnung. Ohne verfügbaren State ist der NIC-Name stabil, auch wenn die Adresse es nicht ist:

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

Nur beim Bootstrap — ein bestehender CE kann SSH nicht ohne Neuerstellen erhalten

cloud-init write_files wird einmalig beim ersten Start ausgeführt. Danach existiert ein /etc/cloud/cloud-init.disabled-Marker auf dem Knoten, und cloud-init wird nicht erneut ausgeführt.

Es gibt daher keinen In-Place-Weg auf einen laufenden CE. custom_data ist in Azure nur durch Ersetzen änderbar, was bedeutet, dass die Übernahme auf einer bestehenden Bereitstellung jede CE-VM ersetzt. Operator-SSH auf bereits laufenden Knoten zu gewähren ist ein Neuaufbau, keine Konfigurationsänderung — und die nächste Warnung beschreibt, was dieser Neuaufbau früher kostete und warum das jetzt anders ist.

Das Ersetzen einer CE-VM hat die Registrierung früher dauerhaft blockiert — das ist behoben, und das ist der Grund, warum das Site-Objekt an die VM gekoppelt ist

Es lohnt sich, dies vor einem geplanten Neuaufbau zu wissen, weil die Form des Fehlers die Kopplung erklärt, die im Plan sichtbar wird.

Früher behielt die Registrierung des gelöschten Knotens den eindeutigen (tenant, cluster_name, hostname)-Index der Steuerungsebene, sodass die Registrierung des Ersatzknotens mit UniqueSecondaryIndexViolationError abgelehnt und endlos wiederholt wurde. Das Löschen der Registrierung allein war nicht ausreichend: Ein verbliebenes StatusObject gab dann 500 für die Workload-Anfrage zurück, und zu diesem Zeitpunkt hatte jeder Knoten eine registration-obj.yml persistiert, die ihn an die gelöschte Registrierung band, sodass er mit 404 ohne Selbstheilung in einer Schleife lief. Die Wiederherstellung erforderte zwei vollständige Neuaufbauten. Während der gesamten Zeit meldete terraform plan „No changes”, weil aus Terraform-Sicht der gewünschte Zustand erreicht war.

Issue 674 ist geschlossen, durch PR 693. modules/xc-site benennt nun die CE-VM-Instanz in replace_triggered_by, sodass das Ersetzen der VM das Site-Objekt ersetzt, und das Löschen einer Site nimmt ihre Registrierungen mit — der Indexschlüssel ist frei, bevor der Ersatzknoten startet. Die Flotte wurde seitdem von Grund auf neu aufgebaut und alle drei Sites kamen ohne Eingriff ONLINE.

Die Kopplung ist beobachtbar, nicht angenommen. Jede Site ist an eine VM-Instanz-ID gebunden, und die entsprechende Registrierung meldet denselben Wert als infra.instance_id:

cd terraform && terraform output -json ce_bound_instance_ids

Eine Abweichung zwischen den beiden Werten bedeutet, dass eine Site noch an einen nicht mehr existierenden Knoten gebunden ist — ein Zustand, aus dem ein neu aufgebauter CE sich nie herausregistrieren kann. Das Auslesen der Registrierungsseite erfordert weiterhin einen direkten API-Aufruf — Provider-Issue 1376 würde es auf die Datenquelle bringen.

Warum cloud-init den Schlüssel schreibt und nicht die API

admin_user_credentials.ssh_key am Site-Objekt sieht genau wie das Feld dafür aus. Es wird akzeptiert, übersteht ein Read-Back und konfiguriert nichts. vpm besitzt die lokalen Benutzer des Knotens und lehnt es ab, diesen zu ändern — aus dem eigenen Log des Knotens, dreimal während eines einzigen Starts:

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

Alles weitere folgt aus dieser einen Zeile. /var/home/admin/.ssh existiert nie, weder vor noch nach dem Erreichen von ONLINE durch die Site. Das Shadow-Last-Change-Datum von admin bleibt beim Bau-Datum des Images, während vesbkp und vesopcon das aktuelle Datum anzeigen, weil vpm diese beiden gesetzt und admin übersprungen hat. Und vpm protokolliert zu keinem Zeitpunkt etwas über ssh_key oder authorized_keys.

Die Datei muss daher außerhalb von vpm geschrieben werden. admin hat die UID 2202, fest im Node-Image verankert, sodass sie existiert, bevor cloud-init läuft, und owner: admin:admin wird zum Schreibzeitpunkt aufgelöst — kein runcmd, keine Eigentümerkorrektur:

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

sshd war stets bereit. sshd -T meldet pubkeyauthentication yes, und admin erscheint in AllowUsers in beiden sshd_config-Dateien, die mit dem Knoten ausgeliefert werden. Es musste nie etwas aktiviert werden — nur eine fehlende Datei.

admin_user_credentials nicht erneut hinzufügen und sshd_config nicht bearbeiten

admin_user_credentials war in terraform/modules/xc-site eingebunden und nach der Sammlung dieser Erkenntnisse zurückgesetzt worden (#660, PR #663). Es ist keine Lücke, die noch gefüllt werden muss.

sshd_config wird während der Registrierung ersetzt, sodass eine Bearbeitung zum ungünstigsten Zeitpunkt verworfen wird.

Warum nur eine Adresse antwortet

sshd bindet 0.0.0.0:22, aber nur die interne (SLI)-Adresse ist im Host-Netzwerk-Stack des Knotens auf eine Weise vorhanden, auf der sshd antwortet. eth0 wird in a-i-eth0 umbenannt und trägt überhaupt keine Host-IP — die Argo-Datenebene besitzt diese Schnittstelle, und die Management-/SLO-Adresse, die sie getragen hätte, erscheint stattdessen auf vhost0. Die anderen beiden NICs bleiben unter ihren eigenen Namen im Host-Stack.

Von einer VM innerhalb des VNets aus gegen einen CE geprüft:

Management-/SLO-Adresse    Zeitüberschreitung
externe Adresse             Zeitüberschreitung
interne/SLI-Adresse        OFFEN     SSH-2.0-OpenSSH_8.7
eine ungenutzte Adresse    Zeitüberschreitung    (Kontrolle)

Eine Prüfung gegen die Adresse, unter der der Knoten bekannt ist, liefert daher exakt dasselbe Ergebnis wie eine geschlossene Sicherheitsgruppe. Es wird nichts blockiert; es gibt einfach keinen Listener auf dieser Adresse.

Den Namen der Gast-Schnittstelle nicht auslesen, um das Subnetz zu ermitteln

Welche der Schnittstellen eth1 und eth2 die interne Adresse trägt, unterscheidet sich zwischen Knoten in dieser selben Bereitstellung. Live von allen drei CEs ausgelesen:

f5-xc-ce-vm-01    eth1 -> extern      eth2 -> intern/SLI
f5-xc-ce-vm-02    eth2 -> extern      eth1 -> intern/SLI
f5-xc-ce-vm-03    eth1 -> extern      eth2 -> intern/SLI

Nur zwei Dinge gelten für jeden Knoten: a-i-eth0 hat keine Adresse, und vhost0 trägt die Management-/SLO-Adresse. Für alles andere sollte in der ip addr-Ausgabe nach der Adresse und nicht nach dem Schnittstellennamen gesucht werden.

Die öffentlichen CE-Adressen haben ebenfalls keinen Listener auf Port 22, weshalb der obige Befehl -J verwendet: eine Operator-VM innerhalb des VNets, im selben Subnetz wie die SLI-Adressen. Diese Bereitstellung erstellt eine zu diesem Zweck — terraform output -raw client_vm_name nennt sie.

-J übergibt die Optionen nicht an den Jump-Leg

Auf der Befehlszeile angegebene Optionen gelten für den letzten Hop. -o UserKnownHostsFile=/dev/null zusammen mit -J konsultiert und schreibt daher für den Jump-Host weiterhin die echte known_hosts, was überrascht, wenn man versucht, eine neu aufgebaute Flotte daraus herauszuhalten. Den ersten Hop explizit angeben, wenn das wichtig ist:

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"

Zwei Messfehler, die zuverlässig falsche Antworten liefern

Das Prüfen von eth0, der externen Schnittstelle oder der öffentlichen Adresse auf Port 22 meldet unabhängig vom SSH-Status des Knotens „geschlossen” und liefert daher keinerlei Information. Nur die SLI-Adresse antwortet.

Und eine Prüfung von einem Unternehmens-Arbeitsplatz kann einen Port als offen melden, der geschlossen ist: Netskope führt den TCP-Handshake auf gängigen Ports selbst durch. Die Ports 80 und 443 erscheinen auf den öffentlichen CE-Adressen von einem Arbeitsplatz aus als offen und sind geschlossen, wenn sie von innerhalb des VNets aus geprüft werden. Prüfungen von einer VM im VNet aus durchführen.

Die Site CLI benötigt ein Terminal und einen Wagenrücklauf

Die Login-Shell von admin ist keine Shell. Es handelt sich um eine go-prompt-Anwendung, die das Terminal in den Raw-Modus versetzt und Tastenanschläge statt Zeilen liest. Vier Konsequenzen, von denen jede auf eine Weise fehlschlägt, die wie ein anderes Problem aussieht:

Mechanik	Was ohne sie passiert
Terminal zuweisen (ssh -tt)	panic: no such device or address von go-prompt.NewStandardInputParser, was wie ein abgestürztes Appliance aussieht
Wagenrücklauf statt Zeilenvorschub für Enter senden	Die Zeile wird nie abgesendet, und die Sitzung schließt bei Eingabeende, ohne etwas ausgegeben zu haben
Standardeingabe offen halten	Die Verbindung endet, bevor der Befehl gerendert hat, sodass ein funktionierender Befehl still wirkt
Befehlstext und Enter-Byte getrennt schreiben	Der Zeilenumbruch landet als wörtliches Zeichen im Puffer, und die CLI antwortet mit unknown command, was so aussieht, als würde der Befehl nicht existieren

ssh host 'some-command' funktioniert daher nicht: Das Argument wird ignoriert und die interaktive Eingabeaufforderung startet trotzdem. Es muss als Terminal gesteuert werden oder gar nicht. scripts/sitecli_ssh_harvest.py ist die Referenzimplementierung.

Ein Panic mit 'no such device or address' bedeutet, dass die Authentifizierung ERFOLGREICH war

vpmu gibt ihn nach dem Login aus, wenn kein Terminal zum Anhängen gefunden wird. Als Absturz gelesen sieht es wie das schlimmstmögliche Ergebnis aus, und es ist tatsächlich der letzte Fehler vor dem Erfolg. -tt hinzufügen und erneut verbinden.

Der Host-Key eines CE ändert sich aus zwei verschiedenen Gründen

Die nächste Verbindung warnt mit REMOTE HOST IDENTIFICATION HAS CHANGED und wird abgelehnt. Den alten Eintrag für diese Adresse löschen und erneut verbinden. Zwei Dinge lösen dies aus:

• Ersetzen des Knotens. Der Ersatz präsentiert einen anderen Schlüssel unter derselben Adresse. Da das Gewähren von SSH die VMs ersetzt, ist dies bei der allerersten Verbindung nach der Übernahme zu erwarten.
• Ein In-Place-Betriebssystem-Upgrade, ohne jeglichen Ersatz. Beobachtet am 28.07.2026: Ein Knoten, dessen ce_os_version-Upgrade abgeschlossen war, präsentierte einen neuen Host-Key unter derselben Adresse auf derselben virtuellen Maschine.

StrictHostKeyChecking=accept-new hilft bei keinem der beiden Fälle. Es akzeptiert Schlüssel für Hosts, die es noch nie gesehen hat; ein geänderter Schlüssel ist genau das, was es ablehnt. Nur das Entfernen des veralteten Eintrags löst das Problem.

Adressen können sich auch verschieben. Das Neuerstellen einer Bereitstellung weist sie aus demselben Subnetz neu zu, sodass ein CE und ein Jump-Host die Adressen tauschen können — danach ist ein veralteter Eintrag nicht nur veraltet, sondern an die falsche Maschine gebunden.

Das Banner ist ein kostenloser Gesundheitscheck

Bevor etwas eingegeben wird, hat das Login-Banner bereits mehrere Fragen beantwortet, auf die man sonst Befehle verwenden würde. Von f5-xc-ce-vm-01, ASCII-Art und öffentliche IP gekürzt:

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 unterscheidet einen Knoten, der noch hochfährt (PROVISIONING), von einem, der fertig ist (PROVISIONED). Software ist der Build-String, der bestimmt, welche Befehle existieren. DNS und NTP decken die beiden Abhängigkeiten ab, die die Registrierung zuerst unterbrechen, sodass ein Knoten, der nie online kam, den Grund hier meistens bereits mitgeteilt hat — bevor chronyc-sources oder dig überhaupt benötigt werden.

Das Schlüsselpaar bereitstellen

1. Ein Schlüsselpaar generieren, falls noch keines vorhanden ist. Ed25519 statt RSA: kürzer und vom Appliance-sshd akzeptiert.

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

2. Die Bereitstellung auf die öffentliche Hälfte verweisen. Das Root-Modul liest die Datei einmalig und übergibt die Zeichenkette an jeden Knoten:

   terraform/terraform.tfvars

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

   ssh_public_key nimmt das Material stattdessen inline entgegen, was die Plan-Tests verwenden. Die private Hälfte verlässt niemals die eigene Arbeitsstation.

3. Apply ausführen. Zuerst die Warnung am Anfang dieser Seite lesen — bei einer bestehenden Bereitstellung werden dabei die CE-VMs ersetzt.

Der admin_ssh_key der VM ist eine andere Sache

azurerm_linux_virtual_machine.admin_ssh_key in modules/ce-node autorisiert den Azure-VM-Administrator, nicht das Appliance-admin-Konto. Es gewährt keinen Site-CLI-Zugang, und dessen Konfiguration ist kein Hinweis darauf, dass CE-SSH konfiguriert ist.

Was dies nicht ist

Jedes der Folgenden wurde getestet und ausgeschlossen, während der Weg noch für unmöglich gehalten wurde. Jedes ist plausibel genug, um einen Tag zu kosten.

Nicht die Ursache	Wie es ausgeschlossen wurde
Die Berechtigung gilt nur beim Erstellen	sshd startet etwa 90 Sekunden nach dem ersten Start, bevor das Site-Objekt existiert. admin_user_credentials ist auch in ReplaceSpecType vorhanden und wird In-Place angewendet.
block_all_services	Das Port-22-Schließen auf der Management-Adresse ist identisch, unabhängig davon, ob Dienste blockiert sind oder nicht.
Ein abschließender Zeilenumbruch am Schlüssel	Beide Varianten getestet, keine Änderung. Cloud-init entfernt ihn trotzdem, weil ein wörtlicher Block andernfalls eine zweite, leere Zeile rendern würde.
Ältere, festgepinnte CE-Software	Auf drei Builds reproduziert, einschließlich eines mit OpenSSH 9.9.
Ein fehlender admin_password	Das Setzen von admin_password neben ssh_key auf einem neu erstellten CE änderte nichts.

Zwei API-Felder, die wie Unterscheidungsmerkmale aussehen, es aber nicht sind

gc_spec.admin_ssh_key ist bei allen 58 Sites in f5-sales-demo leer oder nicht vorhanden — einschließlich der zwei, die admin_user_credentials.ssh_key tatsächlich setzen. Ein Vergleich zwischen einer funktionierenden und einer nicht funktionierenden Site sagt nichts aus, weil es selbst bei den Sites, bei denen die Berechtigung konfiguriert ist, leer erscheint.

registrations_by_site lässt das Feld vollständig weg und gibt None dafür zurück, was als „nicht konfiguriert” statt „nicht gemeldet” gelesen wird.

Die anderen Zugangswege

Debug-APISkriptgesteuert, benötigt keinen Zugang innerhalb des VNets und ist die richtige Wahl für wiederholbare Erkenntnisse. Deckt 34 Befehle ab und benötigt die Site ONLINE.

Site-KonsoleDie Knoten-Fehlerbehebungs-UI von F5 über einen Azure Bastion-Tunnel. Kein Schlüssel, kein Jump-Host, und sie antwortet, bevor die Site registriert wird.

Serielle KonsoleFür einen Knoten, der sich nie registriert hat oder keinen funktionierenden Netzwerkpfad besitzt. Benötigt ein Terminal oder das WebSocket-Harness.

Eine neu erstellte Site benötigt etwa eine halbe Stunde, bevor die Debug-API antwortet

Für ungefähr 25 bis 30 Minuten nach dem ersten ONLINE-Melden einer neuen Site geben die vpm/debug-Endpunkte eine BIG-IP-503-Seite mit der Meldung The requested URL was rejected zurück. Das sieht aus wie eine Web-App-Firewall (WAF)-Blockierung oder ein widerrufenes Token und ist keines von beidem: Die Site ist noch nicht bereit zum Weiterleiten. Warten und erneut versuchen, anstatt etwas zu ändern.

SSH hat keine solche Anlaufzeit. Es antwortet, sobald sshd läuft, weshalb es der Zugangtsweg ist, der funktioniert, während ein Knoten noch registriert wird.