# Agenten auf einem Cloud-Server betreiben

> **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](/docs/getting-started/cloud-servers), Abrechnung und Erstattungen in [Abrechnung und Regeln für Cloud-Server](/docs/reference/cloud-billing).

## Claude Code / Codex auf dem Server installieren

Die Cloud-Server-Seite nennt genau diese beiden Befehle; führen Sie sie auf dem Server aus:

```bash
curl -fsSL https://qcode.cc/install/claude-code.sh | bash -s -- --lang en
```

```bash
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](/docs/getting-started/one-click-install).

## 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](/docs/getting-started/environment) und [Codex Schnellstart](/docs/getting-started/codex-quick-start):

**Claude Code** (Anthropic-Protokoll):

```bash
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`:

```bash
mkdir -p ~/.codex
```

```toml
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`:

```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`):

```bash
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).

1. **Erzeugen Sie das Schlüsselpaar auf Ihrem Rechner** (Ubuntu Server documentation, wörtlich):

   ```bash
   ssh-keygen -t ed25519
   ```

2. **Bringen Sie den öffentlichen Schlüssel auf den Server** (führen Sie das unter macOS / Linux oder in WSL unter Windows aus; das `chmod` lä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.

3. **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_machine` fü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.

4. **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_config` die Zeile `Include /etc/ssh/sshd_config.d/*.conf`, und die Einstellungen aus `sshd_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).

5. **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
   ```

6. **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](https://qcode.cc/models).

Beide Beträge werden **vom selben Kontoguthaben** abgebucht.

## Verwandte Seiten

- [Cloud-Server: Auswahl, Kauf und Betrieb](/docs/getting-started/cloud-servers) — Linie wählen, 1-Tage-Test, Bestellung und Bereitstellung
- [Ein-Klick-Einrichtungsskript](/docs/getting-started/one-click-install) — Werkzeuge installieren und Konfiguration schreiben
- [Umgebungsvariablen](/docs/getting-started/environment) — welche Variablen welches Werkzeug liest
- [Codex Schnellstart](/docs/getting-started/codex-quick-start) — config.toml und auth.json für Codex
- [Abrechnung und Regeln für Cloud-Server](/docs/reference/cloud-billing) — Laufzeiten, automatische Verlängerung, Erstattungen und die zulässige Nutzung