Creation-SSH Native SSH operations workspace
Open documentation index
Documentation

This filters titles already loaded on this page. It does not search article text or external sites.

DOCS / TASK GUIDES

Start with your first Creation-SSH host

Documentation and tutorials now share one task-oriented home. Complete one real workflow and use its expected result to verify the path.

Add your first host Review security boundaries

BEFORE YOU START

Confirm the host identity and connection mode

Agent mode provides the full integrated workflow; SSH mode provides native connection capabilities. Verify the host key on first connect and stop on unexpected changes.

01 / QUICK START

Before you connect

Open the installed client and confirm the connection mode, host identity, and data boundary.

MODE

Choose Agent or SSH mode

Use Agent mode for persistent terminals, monitoring, and structured operations. Choose SSH mode when you only need a native connection or the target should not run the agent.

HOST KEY

Verify the host identity

Verify the host-key fingerprint on first connect. If a known host key changes unexpectedly, stop instead of accepting it silently.

DATA

Confirm the Cloud data boundary

The SSH data plane always connects directly from the client to the server. Creation Cloud stores accounts, devices, and allowed sync data only; it never proxies terminals or remote commands.

02–07 / TASK GUIDES

Hands-on guides

02

Add your first host

Save an authenticatable Linux host and establish first-use host-key trust.

Steps

  1. Step 1

    Open Hosts

    Open host management, choose Add host, and give the server a recognizable name.

  2. Step 2

    Enter SSH details

    Enter the SSH target, port, and login user. Treat any display address as separate from the SSH target.

  3. Step 3

    Save and connect

    Save the host and enter the password when prompted. It is used for authentication and encrypted local storage, not sent to Creation Cloud.

  4. Step 4

    Review the host key

    Read the fingerprint before trusting it. Cancel and investigate if it differs from the value supplied by the administrator.

  5. Step 5

    Confirm the host record

    Return to the host list and confirm the name, SSH target, and observed connection result before deploying the agent.

Verify completion

The host can be selected again and authenticated. Its host key is recorded, and any later change requires another explicit decision.

Agent boundary

Host creation, authentication, and host-key checks do not need the agent. Monitoring, persistent terminals, and structured management do.

03

Deploy or repair the agent

Let the client detect server architecture, upload only the matching agent and static tmux pair, and complete the protocol handshake.

Steps

  1. Step 1

    Open maintenance

    Open the target host menu and choose Install agent or Update / repair agent.

  2. Step 2

    Start architecture detection

    After confirmation, the client runs a read-only uname -m over authenticated SSH. Do not select an architecture manually.

  3. Step 3

    Watch deployment progress

    Wait for the matching agent and tmux upload, length and SHA256 validation, atomic installation, and service readiness.

  4. Step 4

    Wait for strict handshake

    The client then reaches the local Unix socket and verifies protocol compatibility and agent readiness.

  5. Step 5

    Handle visible failures

    Fix the reported unsupported architecture, missing resource, permission, or readiness problem and rerun the operation without bypassing its gate.

Verify completion

The maintenance view reports READY. If collection is enabled, a real MetricsSnapshot is fetched instead of merely clearing an error flag.

Agent boundary

Deployment itself uses an SSH bootstrap. After READY, persistent terminal, monitoring, files, AI, and system capabilities use the agent.

04

Create a reconnectable terminal

Create a server-hosted tmux window and verify that its task survives a client disconnect.

Steps

  1. Step 1

    Select persistent mode

    Open Terminal, select the host, and switch the mode to Persistent terminal.

  2. Step 2

    Create a window

    Create a clearly named tmux window or attach to an existing window from the list.

  3. Step 3

    Run an observation task

    Enter the harmless continuous-output command and confirm live output and resize behavior.

  4. Step 4

    Disconnect and return

    Disconnect or leave the page without choosing Close window, then reopen Terminal and attach to the same window.

  5. Step 5

    Check restored state

    Confirm that the previous screen snapshot appears first and new output from the same task continues afterward.

Verify completion

The window ID and name are unchanged, the task continued while disconnected, and both restored screen content and live output are continuous.

Agent boundary

Persistent mode requires the agent and tmux. Without the agent, use an ordinary terminal, which cannot recover after closure or disconnect.

PRODUCT VIEW / REDACTED DEMO

A standard PTY and a persistent terminal are separate paths

The image shows a direct standard PTY. Only persistent-terminal mode uses the client, agent, and tmux to provide a reconnectable session.

Redacted Creation-SSH demo terminal showing an example server and a standard SSH PTY
Redacted demo with an RFC 5737 example address. It explains the UI path only and is not persistent-session or no-mock evidence.
05

Enable monitoring and inspect history

Move from one background snapshot to live detail, then use history and process data to assess the host.

Steps

  1. Step 1

    Enable collection

    Enable monitoring for the host and adjust the interval and cross-host concurrency when needed.

  2. Step 2

    Inspect the host overview

    Return to Hosts and confirm CPU, memory, disk, load, uptime, and state are read from the latest local cache.

  3. Step 3

    Open monitoring details

    Open the host detail and observe the on-demand live subscription. This stream is separate from background short-request concurrency.

  4. Step 4

    Change the history range

    Choose a range that already contains samples and inspect the high- or low-resolution history for continuity.

  5. Step 5

    Correlate top processes

    Read top processes and system information, then relate resource changes to a process before acting.

Verify completion

The overview becomes fresh and its timestamp advances. Live detail, history, and top processes return structured data.

Agent boundary

Monitoring is agent-only and has no shell fallback. An unreachable agent should produce stale or failed state, never simulated online status.

06

Browse and transfer files

Create, edit, upload or download inside a safe remote test directory and use validation to prove transfer integrity.

Steps

  1. Step 1

    Enter a safe directory

    Open Files, choose the host, and use the breadcrumb trail to enter a writable temporary test directory.

  2. Step 2

    Create a test file

    Create a text file, write recognizable content, save it, and reopen it to confirm the content.

  3. Step 3

    Run one transfer

    Upload a non-sensitive file or download the file you just created while watching chunked transfer progress.

  4. Step 4

    Check the commit

    Wait for checksum and commit success. For a larger directory, compress it on the server before download.

  5. Step 5

    Clean up your test data

    After verifying file identity, remove only the test content created by this tutorial.

Verify completion

A refreshed listing shows the right name and size, reopened or downloaded content matches, and validation reports a successful commit.

Agent boundary

The full file workspace requires the agent. An ordinary terminal remains available, but Files does not replace its protocol with shell strings.

07

Configure and run the AI assistant

Use your own model account to perform one read-only diagnosis against the selected host under controlled permissions.

Steps

  1. Step 1

    Configure the model

    Choose the API type and provider in AI settings, enter the API key, and select an available model.

  2. Step 2

    Limit the run

    Choose the target host, set permission to read-only, and review the workspace and tool-loop limit.

  3. Step 3

    Ask for a verifiable task

    For example, request a summary of system information and resource state while explicitly forbidding file changes or destructive commands.

  4. Step 4

    Observe tool steps

    Review every structured read-only tool call and reject any write or execution request that exceeds the selected permission.

  5. Step 5

    Cross-check and retain

    Compare the result with Monitoring or System, then confirm the conversation and redacted audit record remain available.

Verify completion

The assistant returns a host-consistent read-only summary with no write steps, and the conversation and run can be restored after navigation.

Agent boundary

Remote tools require the agent and never expose SSH credentials to the model. Without the agent, remote work cannot fall back to arbitrary SSH execution.

08 / PORT FORWARDING

Use native SSH local forwarding

Port forwarding is an intentional pure-SSH exception and does not depend on the agent.

LOOPBACK

Bind to loopback by default

Map a server-reachable target to 127.0.0.1 on the client. Change the listen address only when you understand the exposure.

127.0.0.1:<local-port> -> <remote-host>:<remote-port>

09 / CLOUD & SECURITY

A Cloud account is optional and SSH remains the data plane

The Creation Cloud production control plane is deployed. A Cloud account is still optional for local SSH workflows.

OPTIONAL

Manage local hosts without a Cloud account

SSH connections, standard terminals, and local workflows do not require Cloud sign-in. Cloud is limited to control-plane data such as accounts, devices, sync, models, and vault envelopes.

BOUNDARY

Cloud never proxies the SSH data plane

Private keys, passwords, and plaintext secrets do not go to Cloud. Only client-side encrypted vault envelopes defined by the dedicated plan may be stored.

10 / TROUBLESHOOTING

Stop safely when something is wrong

Protect identity and remote work first, then diagnose network, architecture, resources, and permissions.

HOST KEY

The host key changed

Stop connecting and verify the new fingerprint and reason through a trusted channel. Do not delete known_hosts entries to skip confirmation.

DEPLOY

Architecture or paired resources are missing

Run real uname -m detection again; the last architecture in SQLite is only a record. Do not upload another architecture or send both sets.

SESSION

The session did not return

Confirm you used a persistent terminal rather than a standard PTY, then inspect agent and tmux ownership. Do not kill sessions or remove unknown sockets without authorization.

NEXT / KEEP EVIDENCE

Preserve the workspace before reporting a problem

Never silently accept a changed host key, end an unauthorized remote session, or submit real addresses, passwords, private keys, tokens, or complete sensitive logs in feedback.

Add your first host Review security boundaries