Secure Connection Workbook

Connect your Cloud Mac to your development terminal, graphical desktop, and CI queue

ZoneMini provides dedicated physical machines, not virtual machines. Use SSH to run build commands, macOS Screen Sharing for graphical tasks, or register a fixed host as a CI Runner. Verify your connection details first, then choose an access method. Never expose credentials in chat history or pipeline logs.

3 access methods
Command line, graphical desktop, and automated Runner
5 locations
Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the US East Coast
1 principle
Assign credentials by person and purpose, with least-privilege access
Access methods at a glance

Choose the access method for the task—don't treat the graphical desktop as your only channel

All three methods can coexist. Prefer SSH or a Runner for routine automation; open Screen Sharing only when you need the Xcode interface, system settings, or graphical diagnostics.

LOW OVERHEAD

Best for continuous builds and remote administration

Use it to clone repositories, install dependencies, run tests, execute Xcode command-line builds, inspect logs, sync artifacts, and check disk space. Stable scripts should use key-based authentication, with a host alias stored in your local SSH configuration.

  • Ideal for scriptable, auditable operations
  • Easier to recover than a graphical session on weak networks
  • Can run long jobs with a session persistence tool
First connection setup

Complete these six checks after receiving your connection details

Connection failures are often caused not by the host, but by mismatched host addresses, usernames, network policies, or order status. Follow the checks below in order to avoid repeated guesswork.

  1. 01

    Confirm order status

    Sign in to the console to verify that the instance has been delivered, then confirm the model, location, and rental period for the current order. Match each connection detail to that instance.

  2. 02

    Verify the host address

    Copy the host address from the console. Do not reuse an address from an old ticket, script, or team chat. Teams with multiple hosts should add purpose-based labels to each address.

  3. 03

    Verify the login username

    The SSH username and graphical-session username may differ by access method. Do not guess the default username or hard-code temporary passwords in scripts.

  4. 04

    Prepare temporary credentials

    Use temporary credentials only for the first login. Update them immediately after signing in, and store the new credentials through your team's approved password-management process.

  5. 05

    Check your local network

    Confirm that your current network permits outbound traffic to the target port. Corporate networks, proxies, and security software may restrict SSH or graphical connections; check with your network administrator first.

  6. 06

    Create a host record

    Record the host, purpose, owner, host fingerprint, and credential-rotation date. After the first connection, do not dismiss warnings about host-fingerprint changes.

Connection details are sensitive information

Do not paste temporary credentials, SSH private keys, repository tokens, or signing certificates into public issues, complete pipeline logs, or unencrypted documents. When requesting support, provide only redacted command output.

Open the console to verify connection details
SSH connection steps

Verify the host identity first, then switch to key-based login

The commands below use placeholders and contain no real host addresses or credentials. Replace the placeholders with the information supplied in the console, and run them on a trusted network.

STEP 01

Collect and verify the host fingerprint

Before connecting for the first time, collect the ED25519 host public key, calculate its fingerprint, and compare it with the delivery details. Never ignore a warning before verification.

STEP 02

Create a dedicated key

Create a separate key pair for the ZoneMini host. Keep the private key on a controlled local device, then add the public key to the remote authorized-key list.

STEP 03

Configure a readable alias

Store the host address, username, key path, and session-keepalive settings in your SSH configuration to avoid manual entry and accidental use of the wrong host.

STEP 04

Verify access, then stop relying on passwords

Confirm that key-based login works before updating the temporary credentials. Do not remove the only working login method before the key has been verified.

Host fingerprint verification
ssh-keyscan -t ed25519 <node-address> > zonemini_hostkey
ssh-keygen -lf zonemini_hostkey
Create a key and connect
ssh-keygen -t ed25519 -f ~/.ssh/zonemini_ed25519
ssh-copy-id -i ~/.ssh/zonemini_ed25519.pub <user>@<node-address>
ssh -i ~/.ssh/zonemini_ed25519 <user>@<node-address>
~/.ssh/config
Host zonemini-build
  HostName <node-address>
  User <user>
  IdentityFile ~/.ssh/zonemini_ed25519
  ServerAliveInterval 30
  ServerAliveCountMax 3

macOS Screen Sharing

Use the graphical interface for tasks that require seeing the desktop

Screen Sharing is useful for graphical Xcode debugging, checking system settings, and reviewing archives. Run build scripts, collect logs, and process batch jobs through SSH whenever possible.

FINDER / CONNECT

Start a connection from Finder

In macOS Finder, choose “Go” and “Connect to Server,” enter the server address from your delivery details, and start the session with the authorized username and credentials.

Example address format vnc://<node-address>
  1. 01

    Open Connect to Server

    Use Finder's Connect to Server option. Do not save credentials through shortcuts from unknown sources.

  2. 02

    Enter authorization details

    Verify the username and host address, then enter your credentials. For collaboration, do not share one set of long-term login details.

  3. 03

    Adjust display quality

    When the network is unstable, lower the resolution or color quality first. A high-resolution desktop increases data transfer and input latency.

  4. 04

    Limit clipboard contents

    Do not copy private keys, complete tokens, or plaintext passwords. Before pasting across sessions, verify the target window and current user.

  5. 05

    Lock the session when finished

    Closing the client does not necessarily log you out of the desktop. Lock the session when finished and close sensitive windows you no longer need.

Cross-platform graphical access

For non-macOS clients, verify the protocol, network, and display capabilities first

Windows or Linux workstations need a compatible graphical connection client. Clients may differ in shortcut keys, clipboard behavior, color, scaling, and multi-monitor support, so test with a non-sensitive task first.

Client preparation

Choose a client that supports the target connection protocol, encrypted transport, and custom resolutions. The installation source should be team-approved, and the client should be kept up to date.

  • Verify keyboard layout and special-key mappings
  • Verify whether clipboard controls are supported
  • Verify how to exit full screen and lock the session

Network preparation

Verify DNS, routing, and the target port before testing the graphical session. Corporate proxies, egress firewalls, and wireless-network changes can all interrupt a session.

  • Prefer a stable wired or trusted network
  • Avoid switching networks repeatedly during a connection
  • Keep SSH as an independent diagnostic channel

Display settings

Start verification with one display at a medium resolution, then increase the canvas size gradually. If the screen is blank or cropped, return to a lower resolution and reconnect.

  • Adjust scaling to the client window size
  • Disable unnecessary animations and transparency effects
  • Compare locally first for color-critical work

Cross-platform connection criteria

A setup is ready for daily use only when it supports stable input, clear log reading, correct mapping of common shortcuts, and safe session termination. If the task can be fully scripted, prefer SSH or a CI Runner.

CI Runner integration

Assign fixed hosts to reproducible queue jobs

Use a separate account, working directory, and restricted token for the Runner. Start with one minimal test pipeline, then add signing builds, caching, and archiving steps.

  1. 01

    Create a dedicated working directory

    Separate source code, dependency caches, build intermediates, and final artifacts to simplify cleanup rules and disk-usage troubleshooting.

  2. 02

    Register a restricted Runner

    Authorize the token only for the target repository and required operations. Do not reuse a personal access token or write the token to the repository or build output.

  3. 03

    Set queue tags

    Tag jobs by Xcode version, project type, model, or workload to prevent incompatible jobs from being scheduled on the wrong environment.

  4. 04

    Run tests and archive

    Run dependency checks and unit tests before archiving. On failure, retain necessary logs, but never upload the entire user directory unconditionally.

  5. 05

    Return artifacts and clean up

    After confirming that artifacts reached the target storage, delete temporary credentials, temporary keychains, expired caches, and obsolete build directories.

RUN / ARCHIVE / CLEAN Minimal job skeleton
set -euo pipefail

WORK_DIR="$HOME/ci-work/project"
RESULT_DIR="$HOME/ci-results"

mkdir -p "$WORK_DIR" "$RESULT_DIR"
cd "$WORK_DIR"

git fetch --prune
git checkout "$CI_COMMIT_REF"

xcodebuild \
  -scheme "$CI_SCHEME" \
  -destination "generic/platform=iOS" \
  test

xcodebuild \
  -scheme "$CI_SCHEME" \
  -archivePath "$RESULT_DIR/App.xcarchive" \
  archive

find "$WORK_DIR" -name "*.tmp" -delete
Inputs: repository, branch, restricted environment variables Job: tests, archiving, and log collection Artifacts: archive file, redacted logs, and exit status
Security checklist

Manage access like a build dependency

Every permission should have an owner, purpose, and expiration date. Shared accounts, repository tokens, and temporary files left unmanaged over time make a fixed build environment increasingly difficult to audit.

A1

Enable key-based authentication

Each maintainer should use a separate key. When someone leaves the project, remove that public key without affecting anyone else's access.

A2

Restrict shared accounts

When a shared environment is necessary, still distinguish personal logins from automation accounts. Never let a Runner use an administrator's everyday account.

A3

Rotate tokens regularly

Maintain rotation records for repository tokens, Runner registration tokens, and temporary access credentials, and delete expired tokens promptly.

A4

Minimize repository permissions

Build jobs should receive access only to the required repositories and branches. Use separate credentials for uploading artifacts and reading source code.

A5

Lock graphical sessions

Lock the session before leaving the desktop, close windows containing sensitive content, and clear clipboard contents you no longer need.

A6

Remove unused credentials

When a job ends, delete temporary private keys, one-time tokens, temporary keychains, and authorization files that are no longer needed.

Connection troubleshooting

Classify the issue first, then collect the smallest useful evidence set

Don't randomly change passwords, addresses, and clients in succession. Record the error type, time, local network, host, and access method first, then run the relevant checks.

Common SSH, Screen Sharing, and remote-session troubleshooting checklist
Symptom Check first Action to take Include with support request
Connection timeout Host address, local network, egress rules, and target port Switch to a trusted network; test port connectivity; confirm that you are not using an old address Time, host, client network type, and redacted probe results
Authentication failure Username, key path, file permissions, and whether credentials were updated Use verbose SSH logs to identify the selected key; verify the authorized public key Error lines, username, and key fingerprint—never the private key or full password
Host fingerprint changed Whether the host address was changed, the instance rebuilt, or the local alias modified Stop connecting; recheck the fingerprint in the console; update the record only after confirmation Host, old fingerprint, new fingerprint, and time first detected
Blank graphical session Whether the session is locked, display resolution, and client compatibility Lower the resolution; reconnect; use SSH to check system status Client OS, client version, display settings, and redacted screenshot
Incorrect resolution Client scaling, multi-monitor mode, and window size Return to one display and medium resolution, then restore settings one by one Expected resolution, actual resolution, scaling ratio, and client type
Frequent session interruptions Wireless changes, proxy, idle policy, and link instability Use a stable network; enable SSH keepalives; run long jobs in a persistent session Interruption frequency, duration, network changes, and relevant log excerpts
Port and route checks
nc -vz <node-address> 22
route -n get <node-address>
Verbose SSH logs
ssh -vvv zonemini-build 2>&1 | tee ssh-debug.log
Support ticket package

Give the support team everything needed to start troubleshooting

Provide the order number, one of ZoneMini M4 Core / ZoneMini M4 Plus / ZoneMini M4 Pro, host, time, connection method, reproduction steps, expected result, and redacted logs. Do not upload certificate private keys, repository tokens, or full passwords.

Before you order

Choose the task entry point, model, and location, then create a connection record

Prepare the use case, concurrent job count, memory requirements, target location, and rental period. View connection details for existing orders in the console; check the Help Center first for configuration questions.