Remote Access Guide

Securely connect to a cloud Mac and complete your first readiness check

Use SSH for command-line work, automation, and builds; use VNC for graphical desktop tasks. Verify node details and the host fingerprint first, then establish a session, validate the toolchain, and record the results.

Rent a Cloud Mac Visit Help Center
Command line
SSH and key authentication
Graphical desktop
VNC and controlled clipboard
Validation goals
Connection, toolchain, task, exit
Before connecting READY / VERIFY
Node details Hostname, port, username Retrieved
Authentication material Private key or temporary credentials Keep locally
Trust check Verify host fingerprint Required
First validation Terminal, desktop, build task Record results

Never copy a host fingerprint from chat history or an unknown source. Use the information returned for the current order in the console.

Choose a connection method

Choose SSH or VNC for the task

Both methods connect to the same dedicated physical Mac, but they serve different purposes. Prefer SSH for automation; use VNC when you need to inspect the graphical interface, resolution, or desktop apps.

Command line and automation

SSH: preferred for builds, scripts, and runners

Use it for Git, Xcode command-line tools, Fastlane, dependency installation, log collection, and self-hosted runner tasks. Before connecting, prepare a local SSH client, a protected private key, the node hostname, port, username, and a trusted host fingerprint.

  • The private key is readable only by the current user
  • The local network allows access to the port returned for the order
  • Verify the fingerprint through an independent channel before connecting for the first time
  • Use a separate key for automation and restrict its purpose
Graphical desktop tasks

VNC: inspect desktop apps and display environments

Use it to operate the macOS graphical interface, check the keyboard layout, confirm the resolution, and validate tasks that require a desktop session. Before connecting, prepare a trusted VNC client, the node address, temporary credentials, and a clear clipboard policy.

  • Do not save connection passwords on shared devices
  • Set a suitable resolution for the workload
  • Disable unnecessary file and clipboard synchronization
  • Confirm idle locking and reconnect behavior
First connection workflow

Complete the process in four steps, from node details to validation records

Do not skip host fingerprint verification. A successful connection only proves that the path is reachable; the toolchain, directory permissions, and exit procedure must still be checked separately.

  1. 01 Get node details

    Open the current order in the console and record the hostname, connection port, username, temporary credentials or key instructions, and the host fingerprint returned by the system.

    Acceptance: all fields come from the same order, and the node matches the rental term
  2. 02 Verify the fingerprint independently

    When the fingerprint appears during the first SSH connection, compare it section by section with the console information. If it does not match, stop connecting; do not bypass the warning or clear records to proceed.

    Acceptance: the algorithm and fingerprint text match exactly
  3. 03 Establish the session and update credentials

    After the first login, change the temporary credentials as instructed, register your public key, and remove temporary access materials you no longer need.

    Acceptance: the new session works, and the old temporary materials are no longer used
  4. 04 Record validation results

    Check the system version, Xcode version, disk space, and write access to the working directory, then run a small repeatable build task and exit normally.

    Acceptance: connection, toolchain, write access, task, and exit all produce results
Terminal validation example

Use a reproducible session to check SSH, Xcode, and Fastlane

The hostname, username, and task names below are examples. Read actual connection parameters only from the console. Never put production credentials in scripts, build logs, or tickets.

armcli-session — verification 
$ ssh -p 22022 developer@host.example
The authenticity of host cannot be established.
ED25519 key fingerprint is SHA256:<compare-with-console>
Are you sure you want to continue connecting (yes/no)? yes
Last login: current session

developer@cloud-mac % xcodebuild -version
Xcode 16.x
Build version 16X000

developer@cloud-mac % fastlane test
[✓] Preparing build environment
[✓] Resolving project dependencies
[✓] Test task completed

developer@cloud-mac % exit
Connection to host.example closed.
Checkpoint: fingerprint verified Xcode available Task completed successfully Session exited
Desktop connection checks

VNC availability does not mean the desktop environment is ready for work

After entering the graphical desktop for the first time, check display, input, data exchange, and session recovery in a fixed order. Each item should be reproducible after disconnecting and reconnecting.

01

Resolution and scaling

Choose a resolution that fully displays toolbars and dialogs. Do not check only whether the desktop looks sharp; open the actual development tools and verify that text, sidebars, and pop-ups are not clipped.

02

Keyboard layout

Use a regular text field to verify letters, numbers, symbols, and common shortcuts. If the local and remote layouts differ, align them before editing code or entering commands.

03

Clipboard policy

Enable clipboard synchronization only when the task requires it. Never copy private keys, tokens, or complete environment variables; on shared devices, disable two-way synchronization and clear the history.

04

Idle locking

Confirm that the desktop locks when you leave the device. On shared team workstations, lock it manually after use instead of relying on network disconnection to protect the session.

05

Reconnect after disconnecting

Disconnect once deliberately and reconnect to confirm that the session state behaves as expected. For long-running builds, use a task manager that can detach from the interactive connection.

06

Clean up shared devices

After exiting, delete saved host records, cached credentials, and temporary downloads. Check the browser, VNC client, and password manager separately.

SSH tunnel practices

Forward only the local port required for the current task

Local port forwarding lets local tools access a remote service through an SSH session without exposing its listening address to a wider network. Define clear limits for the port, target address, and duration.

  • Minimum exposure:Prefer having the remote service listen on the loopback address, and forward only the single port used by the current task.
  • Keepalive settings:Configure a reasonable keepalive interval for long-running tasks and set a failure count to prevent disconnected sessions from hanging indefinitely.
  • Separate key:Use a dedicated key for automated tunnels. Its permissions and purpose can be revoked independently, and it must not be shared with everyday interactive keys.
  • Revoke after the task:After forwarding ends, terminate the process, revoke unused public keys, and verify that the local listening port is closed.
Local port forwarding example LOCAL ONLY 
ssh \
  -L 127.0.0.1:9000:127.0.0.1:9000 \
  -o ServerAliveInterval=30 \
  -o ServerAliveCountMax=3 \
  -p 22022 \
  developer@host.example
Local listener
127.0.0.1:9000
Remote target
127.0.0.1:9000
How to exit
End the SSH session normally and confirm that the port is closed
CI/CD integration

Start by running one minimal test pipeline with the runner

When integrating systems such as GitLab CI, do not migrate the full production workflow immediately. First register the runner, set fixed tags, verify directory permissions, and run a small test task with no sensitive data.

01

Register the runner

Use a separate service identity for registration, and record the runner name, executor, working directory, and owning project. Use the registration token only when necessary and never write it to the repository.

Result: runner online
02

Add clear tags

Describe actual capabilities with tags such as macOS, arm64, and the project purpose. Avoid broad default tags that could schedule unrelated tasks on the node.

Result: tasks match precisely
03

Verify the working directory

Check read and write permissions for clones, caches, build artifacts, and temporary directories. The task identity must not receive system permissions beyond what the working directory requires.

Result: controlled directory access
04

Run the first task

For the first run, execute only environment output, dependency resolution, and a small test. Confirm the exit code, log integrity, cache path, and cleanup behavior on failure.

Result: task runs reproducibly
Runner first-run acceptance record
Check How to run Pass condition Check first if it fails
Architecture and system uname -m Output matches the task tag Runner tags and execution node
Xcode toolchain xcodebuild -version Version is readable and the command exits with code 0 Command path and task environment
Working directory Create, read, and delete a test file Only the target directory is writable as needed Directory owner and permissions
Cache behavior Run the same test twice consecutively Cache hits are explainable and do not cross project boundaries Cache key and cleanup policy
Connection troubleshooting

Narrow the scope in order, from DNS to the local network

Validate one variable at a time. Do not change the hostname, port, key, and network simultaneously; even if the connection returns, you will not know the root cause.

01
DNS and hostname

Confirm that you are using the hostname currently returned by the console and check that the resolution is stable. Do not copy the address from an old ticket or historical script.

Resolution result
02
Connection port

Check the port number and protocol, and test reachability from the local device to the target port. If the company network imposes restrictions, cross-check from another trusted network.

Port reachability
03
Key and file permissions

Confirm the key file actually loaded by the client, its file permissions, and the corresponding public key. Redact sensitive data before enabling verbose logs, then inspect the authentication order.

Authentication stage
04
Host fingerprint

If the fingerprint changes, stop connecting and re-verify the node details. Do not simply delete the known-host record and continue logging in.

Trust check
05
Session usage

Check for active desktop sessions, long-running tasks, or local port forwards. Confirm the task status before deciding whether to terminate a process.

Session status
06
Local network

Finally check the proxy, firewall, VPN, Wi-Fi quality, and egress policy. Retest on a trusted alternative network to distinguish a local connection issue from a node issue.

Network scope
Prepare this information before submitting a ticket

Node identifier, time the issue occurred, connection method, complete command structure, error summary, steps already tried, and redacted logs. Remove private keys, tokens, passwords, complete fingerprints, and business data before submitting.

Sign in to the console to submit a ticket Contact the service team
Exit checklist

Before ending the task, close out access, data, and the rental term

Closing the remote window is not a complete exit. End sessions, revoke access materials, clean up sensitive files, confirm backups, and verify the order term.

  1. 01 Exit all sessions

    End SSH, VNC, local port forwarding, and runner interactive sessions, and confirm that no test processes or background listeners remain.

  2. 02 Revoke unused keys

    Remove temporary public keys, test runner credentials, and one-time access materials; retained items must have a clear owner and future purpose.

  3. 03 Clear caches and sensitive files

    Check shell history, temporary directories, build logs, downloads, clipboard history, and configuration files in the workspace. Delete anything that should not be retained.

  4. 04 Verify that backups can be read

    Confirm that the code and required artifacts have been moved off the node, and complete one read verification from an independent location. Do not treat a single file on the node as a backup.

  5. 05 Check the rental term and order status

    Confirm the expiration time, renewal status, and service records in the console. If you need to continue, verify the rental term before scheduling further build tasks.

Get started

Rent a dedicated physical Mac and follow this guide to connect

Three configurations are available for command-line builds, graphical desktops, CI/CD runners, and parallel tasks. Actual availability is based on the live status returned by the console.

SSH and VNC Dedicated physical node Runs 365 days a year
Rent a Cloud Mac View rental plans