Root auf dem Server bekommen

Der Server in deinem Projekt gehört dir, und root darauf auch. Du brauchst es selten: Die Operationen des Portals laufen über pbx-agent und brauchen keine Shell. Diese Seite ist für die Male, in denen du es doch brauchst, etwa um Logs zu lesen, die das Portal nicht zeigen kann, oder um den Cluster ohne PaaSbox zu betreiben, und dafür, den Weg danach wieder zu schließen.

In Arbeit: noch nicht buchbar

In Arbeit Im Laborlauf vom 2026-10-10 hat ein privilegierter Pod, gestartet mit einer Admin-Kubeconfig, das Dateisystem des Servers erreicht. Auf diesem Weg einen Schlüssel hinzuzufügen und sich per SSH anzumelden, ist auf einem PaaSbox-Cluster noch nicht gelaufen. Die Oberfläche des Portals ist englisch, darum stehen ihre Beschriftungen hier auf Englisch. Sag mir, wenn es buchbar ist.

Wie der Server eingerichtet ist

• Das Node-Image hat einen SSH-Server, der root nur mit Schlüssel annimmt. Passwörter gibt es auf dem Image nicht.
• Das Portal hinterlegt beim Anlegen des Servers keinen SSH-Schlüssel, und die Firewall des Clusters hält Port 22 zu.
• Die Schlüssel für root stehen in /etc/ssh/authorized_keys.d/root. Diese Datei übersteht Neustarts und Upgrades; /root nicht.

Die Web-Konsole von Hetzner ist kein Weg hinein. Sie braucht ein root-Passwort, und das Image setzt keines.

Was du brauchst

• Deinen öffentlichen SSH-Schlüssel.
• Die öffentliche Adresse, von der aus du arbeitest.
• Für den ersten Weg: eine admin-Kubeconfig (Eine Kubeconfig holen) und kubectl.
• Zugang zum Projekt des Clusters in der Hetzner-Konsole.

Deinen Schlüssel über den Cluster hinzufügen

Dieser Weg geht, solange der Cluster läuft.

1. Einen Pod auf dem Node starten, der das Dateisystem des Servers sieht. Der Node heißt nach dem DNS-Label des Clusters, etwa upcheck-prod-cp-1:

   kubectl debug node/upcheck-prod-cp-1 -it --profile=sysadmin --image=busybox

   --profile=sysadmin startet den Pod privilegiert, so wie der Pod des Labors auf dem Node lief.

2. Deinen Schlüssel hinzufügen. Im Pod liegt das Dateisystem des Servers unter /host. Setz deinen eigenen öffentlichen Schlüssel zwischen die Anführungszeichen:

   mkdir -p /host/etc/ssh/authorized_keys.d
   echo 'ssh-ed25519 AAAA... you@laptop' >> /host/etc/ssh/authorized_keys.d/root
   exit

3. Den Debug-Pod löschen. kubectl get pods zeigt ihn; sein Name beginnt mit node-debugger-.

   kubectl delete pod <sein Name>

4. Port 22 für deine Adresse öffnen, mit einer eigenen Firewall. Leg in der Hetzner-Konsole unter Firewalls eine Firewall mit einer eingehenden Regel an, TCP-Port 22 von deiner Adresse (etwa 203.0.113.7/32), und wende sie auf den Server an. Trag die Regel nicht in die Firewall des Clusters ein: Deren Regeln schreibt das Portal neu, sobald die API-Bereiche gespeichert werden (Festlegen, wer die API erreicht).

5. Anmelden.

   ssh root@<IPv4 des Servers>

Das Rescue-System von Hetzner nutzen

Dieser Weg ist für die Fälle, in denen der Cluster nicht läuft oder pbx-agent sich nie registriert hat. Das Rescue-System ist ein Linux, das Hetzner statt von der Platte des Servers über das Netz bootet, mit der Platte angehängt. Der Server startet dafür neu, der Cluster und deine Apps sind also weg, solange du darin arbeitest.

1. Öffne Port 22 für deine Adresse mit einer eigenen Firewall, wie in Schritt 4 oben. Die Firewall des Clusters gilt auch für das Rescue-System.

2. Öffne in der Hetzner-Konsole den Reiter Rescue des Servers, wähle deinen SSH-Schlüssel und schalte das Rescue-System ein; es wirkt beim nächsten Start, also starte den Server hart neu (Power Cycle).

3. Melde dich mit ssh root@<IPv4 des Servers> an. Die Platte des Servers ist angehängt, aber nicht eingehängt; lsblk listet sie.

4. Wenn du fertig bist, starte neu. Hetzner nutzt das Rescue-System nur für einen Start, der Server bootet also wieder das Node-Image, und k3s und pbx-agent starten von selbst.

Den Weg wieder schließen

• Port 22 schließen. Nimm deine Firewall in der Hetzner-Konsole vom Server, oder lösche sie. Das Löschen des Clusters entfernt sie nicht: Sie trägt kein Label des Clusters.
• Deinen Schlüssel entfernen. Das Image fügt Schlüssel immer nur hinzu. Lösch deine Zeile aus /etc/ssh/authorized_keys.d/root, per SSH, bevor du den Port schließt, oder über einen Debug-Pod wie oben.

Was du auf dem Server beachten solltest

• Das Portal verbindet sich nie mit dem Server, und nichts, was du dort tust, läuft über es.
• Was du auf dem Server von Hand änderst, verantwortest du (So funktioniert es).
• Bearbeite nicht die eigenen Dateien des Images in /etc. /etc ist ein Overlay auf dem dauerhaften /var: Eine dort geänderte Datei verdeckt die Fassung jedes späteren Images, für immer. Leg eine eigene k3s-Einstellung in ein eigenes Drop-in, etwa /etc/rancher/k3s/config.yaml.d/60-mine.yaml; die Drop-ins 50-pbx-*.yaml gehören pbx-agent, der sie wieder schreibt.

Ohne PaaSbox weiterbetreibenWas du auf dem Server brauchst, um den Cluster selbst weiterzubetreiben.

FehlerbehebungWas ein Zustand bedeutet, und was zu tun ist, wenn der Cluster nicht bereit wird.