Агенты на облачном сервере

Запуск Claude Code или Codex на облачном сервере: установка инструментов, ключ QCode и endpoint, продолжение задач через tmux и переход на вход по ключу.

Нужен API-ключ? Зарегистрироваться →·Эндпоинты и Base URL →

Last verified: 2026-10-19 · 📄 Per qcode.cc and official docs (tmux / OpenSSH / Ubuntu Server)

ℹ️ Страница конфигурации и консоль облачных серверов сейчас доступны только на китайском и английском языках. Страница продукта: https://qcode.cc/en/cloud

Запуск Claude Code или Codex на машине, которая работает постоянно: задача на полчаса или на несколько часов не должна умирать вместе с SSH-соединением, и к ней нужно возвращаться посмотреть, что происходит. Для этого и нужен облачный сервер. Поставили инструменты, настроили ключ — дальше важны две вещи: чтобы задача переживала разрыв SSH, и чтобы вход был по ключу.

Как купить машину — в статье Облачные серверы: выбор, покупка и запуск, про тарификацию и возвраты — в Тарификации и правилах облачных серверов.

Установка Claude Code / Codex на сервер¶

Страница облачных серверов даёт ровно эти две команды — выполните их на сервере:

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

Сообщения скрипта выводятся на английском (в --lang доступны только zh и en).

Скрипт замеряет доступные домены, спрашивает ваш ключ cr_, записывает конфигурацию, при необходимости ставит Node.js и CLI и в конце отправляет минимальный запрос для проверки связи. Все параметры и порядок отката описаны в статье Скрипт установки в один клик.

Ключ QCode и endpoint¶

Скрипт уже записал конфигурацию за вас. Если хотите написать её руками или просто проверить результат — вот два места, приведённые по оригиналам Переменных окружения и Быстрого старта Codex:

Claude Code (протокол Anthropic):

export ANTHROPIC_BASE_URL="https://api.qcode.cc/api"
export ANTHROPIC_AUTH_TOKEN="cr_ваш_ключ"

Codex (протокол OpenAI Responses) — сначала создайте каталог, затем напишите ~/.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_ваш_ключ"
}

После этого проверьте, что base_url — это https://api.qcode.cc/openai, что ANTHROPIC_BASE_URL — это https://api.qcode.cc/api, а ключ начинается с cr_. Написанный вручную export действует только в текущей оболочке; чтобы уже запущенная сессия tmux его подхватила, выполните его внутри сессии tmux или добавьте его в ~/.bashrc.

Продолжаем задачи после разрыва SSH с помощью tmux¶

Если запустить задачу по обычному ssh root@<IP>, процесс на переднем плане умрёт вместе с соединением. Сессии tmux постоянны — в руководстве сказано:

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

Иными словами, сессия остаётся и когда SSH обрывается неожиданно, и когда вы отсоединяетесь сами клавишами C-b d.

Три команды, которыми вы будете пользоваться постоянно (если tmux ещё не установлен, сначала поставьте его через пакетный менеджер вашей системы; на Ubuntu это sudo apt install tmux):

tmux new -s agent      # создать сессию с именем agent и войти в неё
tmux ls                # показать все сессии на сервере
tmux attach -t agent   # снова подключиться к этой сессии

Чтобы ненадолго отойти, нажмите Ctrl-b, затем d — в руководстве префиксом по умолчанию служит C-b, а d означает "Detach the current client." (отсоединить текущего клиента). Задача продолжает идти внутри сессии; вернувшись, выполните tmux attach. Способ подключиться заново в руководстве указан как $ tmux attach.

Безопасность SSH: сначала ключ, проверка входа, и только потом отключение пароля¶

Порядок важен. Документация Ubuntu прямо предупреждает об этом при описании настройки OpenSSH: если единственный способ попасть на сервер — SSH и вы ошиблись в конфигурации, перезапуск может закрыть вам доступ к собственной машине. Поэтому сначала проверяем, потом отключаем.

В примерах ниже используется Ubuntu. В других дистрибутивах свои имена служб и свои пути к конфигурации — сверяйтесь с документацией именно вашей системы; сам порядок (проверить ключ, затем отключить пароли, перед перезапуском проверить конфигурацию) остаётся тем же.

1. Создайте пару ключей на своей машине (Ubuntu Server documentation, дословно):

bash ssh-keygen -t ed25519

1. Положите открытый ключ на сервер (выполняйте на macOS / Linux либо в WSL на Windows; команду chmod выполняйте на сервере, в домашнем каталоге после входа):

bash ssh-copy-id root@<IP>

На странице Ubuntu сказано, что содержимое id_ed25519.pub нужно дописать в ~/.ssh/authorized_keys на целевой машине, и напоминают проверить права на этот файл — писать в него может только прошедший проверку пользователь; если права неверны, выполните chmod go-w .ssh/authorized_keys.

1. Проверьте, что по ключу вход работает. На странице сказано так: "You should now be able to SSH to the target_machine without being prompted for a password." (на странице Ubuntu target_machine — это адрес вашего сервера; смысл фразы в том, что вход проходит без запроса пароля). На этом шаге откат к паролю запрещён, иначе ключ, который установили неправильно, всё равно пустит вас внутрь:

bash ssh -o PasswordAuthentication=no -o PreferredAuthentications=publickey -i ~/.ssh/id_ed25519 root@<IP>

С -o PasswordAuthentication=no неверный ключ сразу даст Permission denied, без запроса пароля; если вас не пустили, не идите дальше — вернитесь к шагу 2. На этом шаге не закрывайте сессию, в которой вы вошли по паролю — откройте второе окно терминала.

1. Только убедившись, что вход работает, отключайте вход по паролю. Сначала выясните, какие файлы управляют этой опцией — в Ubuntu в начале /etc/ssh/sshd_config стоит Include /etc/ssh/sshd_config.d/*.conf, и настройки из sshd_config.d/ перекрывают основной файл:

bash sudo grep -rEi '^\s*PasswordAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Измените каждую найденную строку на PasswordAuthentication no (включая yes в каком-нибудь файле внутри sshd_config.d/). Только если не найдено ни одной строки, добавьте PasswordAuthentication no в конец /etc/ssh/sshd_config. Причина — в sshd_config(5): «Unless noted otherwise, for each keyword, the first obtained value will be used.» (если не указано иное, для каждого ключевого слова берётся первое полученное значение); файлы, подключённые через Include, обрабатываются в лексикографическом порядке, поэтому более раннее значение выигрывает. В руководстве эти две опции описаны так: PasswordAuthentication — "Specifies whether password authentication is allowed." (разрешена ли аутентификация по паролю); PubkeyAuthentication — "Specifies whether public key authentication is allowed." (разрешена ли аутентификация по открытому ключу).

1. Сначала проверьте синтаксис, потом посмотрите действующие значения, и только затем перезапускайте:

bash sudo sshd -t sudo sshd -T | grep -Ei '^(passwordauthentication|pubkeyauthentication) '

sshd -T печатает конфигурацию, которую sshd действительно применит (sshd(8), «extended test mode»: конфигурация выводится в стандартный вывод). Перезапускайте, только если видите passwordauthentication no и pubkeyauthentication yes; если passwordauthentication всё ещё yes, какой-то другой файл перекрывает значение — вернитесь к предыдущему шагу. Если sshd -t сообщает об ошибке, не перезапускайте — сначала исправьте конфигурацию.

bash sudo systemctl restart ssh.service

1. Проверьте ещё раз после перезапуска, старый сеанс пока не закрывайте. Откройте новый терминал и войдите по ключу ещё раз той же командой, что и на шаге 3; затем попробуйте вход только по паролю — он должен быть отклонён:

bash ssh -o PubkeyAuthentication=no root@<IP>

Сообщение Permission denied означает, что вход по паролю отключён; закрывайте исходный сеанс только тогда, когда обе проверки дали ожидаемый результат.

💡 На этом этапе у вас есть машина, на которой агенты можно держать долго: инструменты установлены, ключ и endpoint заданы, задачи переживают разрыв соединения, а вход сделан по ключу.

Сколько это стоит: два вида расходов¶

• Сервер: оплачивается с баланса за срок, выбранный при заказе (1, 3, 6 или 12 месяцев) — чем длиннее срок, тем дешевле в пересчёте на месяц. Стартовая цена указана в таблице Compare lines на qcode.cc/en/cloud.
• Модели: оплата за токены, цены по моделям — на qcode.cc/models.

Обе суммы списываются с одного баланса аккаунта.

Связанные страницы¶

• Облачные серверы: выбор, покупка и запуск — выбор линии, пробный день, заказ и доставка
• Скрипт установки в один клик — установка инструментов и запись конфигурации
• Переменные окружения — какие переменные читает каждый инструмент
• Быстрый старт Codex — config.toml и auth.json для Codex
• Тарификация и правила облачных серверов — сроки, автопродление, возвраты и допустимое использование

Enterprise →