Agenten auf einem Cloud-Server betreiben
Claude Code oder Codex auf einem Cloud-Server: Werkzeuge installieren, Key und Endpunkt setzen, Aufgaben mit tmux weiterlaufen lassen, Schlüssel-Login.
Brauchen Sie einen API-Key? Registrieren →Endpunkte & Base-URLs →
Auf dieser Seite
Last verified: 2026-10-19 · 📄 Per qcode.cc and official docs (tmux / OpenSSH / Ubuntu Server)
ℹ️ Die Konfigurationsseite und die Konsole für Cloud-Server gibt es derzeit nur auf Chinesisch und Englisch. Produktseite: https://qcode.cc/en/cloud
Claude Code oder Codex auf einer Maschine laufen lassen, die durchgehend läuft: Ein Auftrag, der eine halbe Stunde oder mehrere Stunden braucht, darf nicht mit der SSH-Verbindung sterben, und Sie müssen zwischendurch zurückkommen und nachsehen können. Dafür ist ein Cloud-Server da. Werkzeuge installieren, Key setzen — danach zählen zwei Dinge: dass die Aufgabe einen SSH-Abbruch übersteht, und dass die Anmeldung über einen Schlüssel läuft.
Wie Sie die Maschine kaufen, steht in Cloud-Server: Auswahl, Kauf und Betrieb, Abrechnung und Erstattungen in Abrechnung und Regeln für Cloud-Server.
Claude Code / Codex auf dem Server installieren¶
Die Cloud-Server-Seite nennt genau diese beiden Befehle; führen Sie sie auf dem Server aus:
curl -fsSL https://qcode.cc/install/claude-code.sh | bash -s -- --lang en
curl -fsSL https://qcode.cc/install/codex.sh | bash -s -- --lang en
Die Ausgabe des Skripts ist englisch (--lang kennt nur zh und en).
Das Skript misst, welche Zugangsdomain am schnellsten antwortet, fragt nach Ihrem cr_-Key, schreibt die Konfiguration, installiert Node.js und CLI bei Bedarf und sendet zum Schluss eine minimale Anfrage, um die Verbindung zu prüfen. Alle Parameter und der Rollback stehen im Ein-Klick-Einrichtungsskript.
QCode-Key und Endpunkt setzen¶
Das Skript hat die Konfiguration bereits geschrieben. Wenn Sie sie von Hand schreiben oder nur prüfen wollen, sind das die beiden Stellen, wörtlich aus Umgebungsvariablen und Codex Schnellstart:
Claude Code (Anthropic-Protokoll):
export ANTHROPIC_BASE_URL="https://api.qcode.cc/api"
export ANTHROPIC_AUTH_TOKEN="cr_your_key"
Codex (OpenAI-Responses-Protokoll) — legen Sie zuerst das Verzeichnis an, schreiben Sie dann ~/.codex/config.toml:
mkdir -p ~/.codex
model_provider = "qcode"
model = "gpt-6.1-sol"
model_reasoning_effort = "high"
[model_providers.qcode]
name = "qcode"
base_url = "https://api.qcode.cc/openai"
wire_api = "responses"
requires_openai_auth = true
~/.codex/auth.json:
{
"OPENAI_API_KEY": "cr_your_key"
}
Prüfen Sie danach, dass base_url auf https://api.qcode.cc/openai steht, ANTHROPIC_BASE_URL auf https://api.qcode.cc/api und der Key mit cr_ beginnt. Ein von Hand gesetztes export gilt nur für die aktuelle Shell; damit eine bereits laufende tmux-Sitzung es übernimmt, führen Sie es in der tmux-Sitzung aus oder tragen Sie es in ~/.bashrc ein.
Aufgaben mit tmux nach einem SSH-Abbruch weiterlaufen lassen¶
Starten Sie den Auftrag über ein schlichtes ssh root@<IP>, stirbt der Prozess im Vordergrund mit der Verbindung. tmux-Sitzungen bleiben bestehen — das Handbuch sagt:
Each session is persistent and will survive accidental disconnection (such as ssh(1) connection timeout) or intentional detaching (with the ‘C-b d’ key strokes).
Die Sitzung bleibt also bestehen, ob die SSH-Verbindung unerwartet abbricht oder Sie sich mit C-b d selbst abkoppeln.
Drei Befehle, die Sie ständig brauchen (falls tmux noch nicht installiert ist, installieren Sie es zuerst über den Paketmanager Ihres Systems; unter Ubuntu mit sudo apt install tmux):
tmux new -s agent # eine Sitzung namens agent anlegen und hineinwechseln
tmux ls # alle Sitzungen auf dem Server anzeigen
tmux attach -t agent # wieder an diese Sitzung hängen
Um die Sitzung kurz zu verlassen, drücken Sie Ctrl-b und danach d — im Handbuch ist C-b das Standardpräfix, und d steht für "Detach the current client." (den aktuellen Client abkoppeln). Der Auftrag läuft in der Sitzung weiter; wenn Sie zurückkommen, hängt tmux attach Sie wieder an. Wie man sich erneut anhängt, steht im Handbuch als $ tmux attach.
SSH-Sicherheit: erst auf Schlüssel umstellen, den Login prüfen, dann die Passwörter abschalten¶
Die Reihenfolge ist wichtig. Die Ubuntu-Dokumentation warnt genau davor, wenn es die Konfiguration von OpenSSH beschreibt: Ist SSH Ihr einziger Zugang und Sie konfigurieren etwas falsch, kann ein Neustart Sie aus Ihrem eigenen Server aussperren. Also erst prüfen, dann abschalten.
Die Befehle unten verwenden Ubuntu als Beispiel. Andere Distributionen verwenden andere Dienstnamen und andere Pfade für die Konfiguration — sehen Sie dort in der Dokumentation nach; die Reihenfolge bleibt dieselbe (Schlüssel prüfen, dann Passwörter abschalten, vor dem Neustart prüfen).
- Erzeugen Sie das Schlüsselpaar auf Ihrem Rechner (Ubuntu Server documentation, wörtlich):
bash
ssh-keygen -t ed25519
- Bringen Sie den öffentlichen Schlüssel auf den Server (führen Sie das unter macOS / Linux oder in WSL unter Windows aus; das
chmodläuft auf dem Server, in Ihrem Home-Verzeichnis nach der Anmeldung):
bash
ssh-copy-id root@<IP>
Auf der Ubuntu-Seite steht, den Inhalt von id_ed25519.pub an ~/.ssh/authorized_keys der Zielmaschine anzuhängen und danach die Rechte dieser Datei zu prüfen — schreiben darf nur der authentifizierte Benutzer; sind die Rechte falsch, führen Sie chmod go-w .ssh/authorized_keys aus.
- Prüfen Sie, ob der Schlüsselzugang funktioniert. Auf der Seite steht wörtlich: "You should now be able to SSH to the target_machine without being prompted for a password." (auf der Ubuntu-Seite steht
target_machinefür die Adresse Ihres Servers; der Satz bedeutet, dass die Anmeldung ohne Passwortabfrage gelingt). Auf diesem Schritt darf kein Rückfall auf das Passwort erfolgen, sonst kommen Sie auch mit einem falsch installierten Schlüssel hinein:
bash
ssh -o PasswordAuthentication=no -o PreferredAuthentications=publickey -i ~/.ssh/id_ed25519 root@<IP>
Mit -o PasswordAuthentication=no schlägt ein falscher Schlüssel sofort mit Permission denied fehl, statt nach einem Passwort zu fragen; werden Sie abgewiesen, gehen Sie nicht weiter — zurück zu Schritt 2. Lassen Sie an dieser Stelle die Sitzung offen, in der Sie noch mit dem Passwort angemeldet sind, und öffnen Sie ein zweites Terminalfenster.
- Erst wenn das funktioniert, schalten Sie die Passwortanmeldung ab. Finden Sie zuerst heraus, welche Dateien die Option steuern — unter Ubuntu steht am Anfang von
/etc/ssh/sshd_configdie ZeileInclude /etc/ssh/sshd_config.d/*.conf, und die Einstellungen aussshd_config.d/überschreiben die Hauptdatei:
bash
sudo grep -rEi '^\s*PasswordAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
Ändern Sie jede gefundene Zeile auf PasswordAuthentication no (auch ein yes in einer Datei unter sshd_config.d/). Nur wenn überhaupt nichts gefunden wurde, hängen Sie die Zeile PasswordAuthentication no ans Ende von /etc/ssh/sshd_config. Der Grund steht in sshd_config(5): "Unless noted otherwise, for each keyword, the first obtained value will be used." (sofern nicht anders angegeben, wird für jedes Schlüsselwort der zuerst gelesene Wert verwendet); die über Include eingebundenen Dateien werden in lexikalischer Reihenfolge verarbeitet, es gewinnt also der frühere Wert. Das Handbuch beschreibt die beiden Optionen so: PasswordAuthentication — "Specifies whether password authentication is allowed." (ob die Passwort-Authentifizierung erlaubt ist); PubkeyAuthentication — "Specifies whether public key authentication is allowed." (ob die Public-Key-Authentifizierung erlaubt ist).
- Erst die Syntax prüfen, dann die wirksamen Werte ansehen, dann neu starten:
bash
sudo sshd -t
sudo sshd -T | grep -Ei '^(passwordauthentication|pubkeyauthentication) '
sshd -T gibt die Konfiguration aus, die sshd tatsächlich verwendet (sshd(8), „extended test mode“: die Konfiguration wird auf die Standardausgabe geschrieben). Starten Sie nur neu, wenn Sie passwordauthentication no und pubkeyauthentication yes sehen; steht passwordauthentication noch auf yes, überschreibt eine andere Datei den Wert — gehen Sie zurück zum vorigen Schritt. Meldet sshd -t einen Fehler, starten Sie noch nicht neu.
bash
sudo systemctl restart ssh.service
- Nach dem Neustart noch einmal prüfen und die alte Sitzung offen lassen. Öffnen Sie ein neues Terminal und melden Sie sich noch einmal mit demselben Befehl aus Schritt 3 mit dem Schlüssel an; versuchen Sie danach eine Anmeldung nur mit dem Passwort — die muss abgewiesen werden:
bash
ssh -o PubkeyAuthentication=no root@<IP>
Eine Meldung Permission denied bedeutet, dass die Passwortanmeldung abgeschaltet ist; erst wenn beide Prüfungen wie erwartet ausgehen, schließen Sie die ursprüngliche Sitzung.
💡 Damit haben Sie eine Maschine, auf der Agenten dauerhaft laufen können: Die Werkzeuge sind installiert, Key und Endpunkt sind gesetzt, Aufgaben überstehen einen Abbruch, und Sie melden sich mit einem Schlüssel an.
Was es kostet: zwei Teile¶
- Der Server: wird aus dem Guthaben für die bei der Bestellung gewählte Laufzeit (1, 3, 6 oder 12 Monate) berechnet — längere Laufzeiten kosten pro Monat weniger. Den Startpreis finden Sie in der Compare-lines-Tabelle auf qcode.cc/en/cloud.
- Die Modelle: Abrechnung pro Token, die Preise je Modell stehen auf qcode.cc/models.
Beide Beträge werden vom selben Kontoguthaben abgebucht.
Verwandte Seiten¶
- Cloud-Server: Auswahl, Kauf und Betrieb — Linie wählen, 1-Tage-Test, Bestellung und Bereitstellung
- Ein-Klick-Einrichtungsskript — Werkzeuge installieren und Konfiguration schreiben
- Umgebungsvariablen — welche Variablen welches Werkzeug liest
- Codex Schnellstart — config.toml und auth.json für Codex
- Abrechnung und Regeln für Cloud-Server — Laufzeiten, automatische Verlängerung, Erstattungen und die zulässige Nutzung
Mit QCode starten
Ein API-Key für Claude Code, Codex und mehr – Abrechnung pro Token, Preise je Modell auf qcode.cc/models