Secure connection path

Verify your identity before connecting to your Cloud Mac

Use remote desktop for Xcode, graphical debugging, and macOS sessions; use SSH for scripts, file operations, automation, and CI/CD management. Both channels start with the same node details in the console, but use different verification methods.

  • Verify the node, username, and session identity before using remote desktop
  • Compare the host fingerprint on the first SSH connection
  • Disable temporary credentials after independent key authentication succeeds
Rent a Cloud Mac now View setup steps
2
Primary connection methods
6
First-connection checks
1
Console access record
CONNECTION PASS

First-connection checklist

Pending verification
Graphical session Xcode, debugging, desktop operations
Remote desktop
Command channel Scripts, files, runner management
SSH
Node address
From order details
Port
Enter by protocol
Host fingerprint
Compare on first connection
Long-term authentication
Dedicated SSH key
Verification order Address → port → identity → fingerprint → session
Connection overview

Use desktop for graphical work and SSH for automation

You can use both connection methods at the same time. The desktop session handles visual operations, while SSH handles stable, auditable command tasks; do not put all your work on a single session.

Graphical workflow

Remote desktop

Use it to open Xcode, run simulators, inspect graphical interfaces, handle signing materials, and observe debugging that requires visual feedback. Before connecting, verify the node address, session account, and current desktop identity.

  • Interactive Xcode editing and builds
  • Graphical log and performance panel checks
  • macOS sessions that require continuous observation
Command workflow

SSH

Use it for scripts, file synchronization, disk-usage checks, build-process management, and self-hosted runner maintenance. For long-term use, adopt a dedicated key and restrict where it is stored and how it can be used.

  • Repeatable build and deployment scripts
  • File transfers, log extraction, and cache cleanup
  • CI/CD runner registration and maintenance
Combined approach

Verify on desktop, execute with SSH

During initial delivery, use remote desktop to confirm the session and system status, then use SSH to verify the key. For daily operation, run long tasks in resumable command workflows and reserve the desktop for visual operations.

  • Reduce the impact of desktop disconnections on long-running tasks
  • Make commands and results easier to record
  • Separate interactive operations from automation permissions
Identify access details

Use each field for one purpose—never mix them

Find access details in the order or instance details in the console. Preserve the original capitalization and port when copying, and never transcribe long fingerprints manually from screenshots.

Cloud Mac access fields and their uses
Field Used for First check Security boundary
Node address Target host for the remote desktop client and SSH command Matches the node selected for the current order Do not use an address from another order as a backup
Port Distinguishes remote desktop and SSH service endpoints Enter each value from the console; do not guess Do not expose self-added listening ports to the public internet
Username Identifies the macOS user session to sign in to Check spelling, capitalization, and session ownership Team members should not share untraceable account details
Temporary credentials Used only for the first remote desktop or SSH verification Set up long-term authentication immediately after first access Disable temporary credentials after independent key authentication succeeds
Host fingerprint Confirms that SSH connects to the expected physical node Compare character by character with the console record on first connection Stop connecting and submit a support ticket for review if the fingerprint changes
First remote desktop connection

Break your first login into four clear checks

The compatible client name and version depend on your operating system. After downloading it, update to a supported version before entering the connection details provided in the console.

  1. 01

    Prepare the client

    Install a compatible remote desktop client and confirm that your local system allows network access and screen display. Disable old connection profiles that may rewrite the target address.

  2. 02

    Enter node details

    Copy the node address, remote desktop port, and username from the console. Save them first as a configuration dedicated to this order, without sharing aliases with other nodes.

  3. 03

    Verify session identity

    After connecting, check the host information, username, selected node, and order record. If anything does not match, end the session and verify everything again.

  4. 04

    Complete the first login

    Update the temporary credentials, confirm the keyboard layout, resolution, and automatic lock settings, then reconnect once to verify that the new details work correctly.

Secure SSH connection

The connection is complete only after the key, fingerprint, and permissions all pass

Generate separate keys for each operator and automation environment. Never copy someone else’s private key or distribute one long-term key across untraceable devices.

SSH access sequence Generate locally → upload public key → compare fingerprint → test login

1. Generate a dedicated key

ssh-keygen -t ed25519 -f ~/.ssh/ovps_remote

Keep the private key on a controlled device and submit the public key through the console. Give the key a recognizable purpose name for easier replacement and revocation later.

2. Check local private-key permissions

chmod 600 ~/.ssh/ovps_remote

SSH will refuse to use a private key when its permissions are too open. On shared workstations, also check directory permissions and backup-software access.

3. Test login with console fields

ssh -i ~/.ssh/ovps_remote -p "$SSH_PORT" "$SSH_USER@$NODE_ADDRESS"

When prompted for the host fingerprint on the first connection, compare it with the console record first. Confirm only after an exact match; never skip or blindly accept it.

Successful verification criteria

One test should establish four facts

  • The target address matches the order node
  • The host fingerprint matches character by character
  • The dedicated private key authenticates successfully
  • The account can access only the expected working directory
After verification

Disable temporary credentials

After confirming successful key login, disable the temporary credentials used for initial delivery. Record the key owner, purpose, and replacement plan, and delete temporary local copies that are no longer needed.

View connection support
SSH tunnel scenarios

Forward only the services you need and bind them to the local loopback address

Use tunnels for temporary access to internal development services, build reports, or local debugging ports. They are not a substitute for permanently exposing a service to the internet.

Local port forwarding

Create a controlled channel

The following command maps a development service listening only on the loopback address of the Cloud Mac to the operator’s local machine. The browser accesses only the local address, so the service needs no new public listener.

ssh -N \
  -L 127.0.0.1:8080:127.0.0.1:8080 \
  -i ~/.ssh/ovps_remote \
  -p "$SSH_PORT" \
  "$SSH_USER@$NODE_ADDRESS"
Local binding
127.0.0.1:8080
Remote target
127.0.0.1:8080
Authentication method
Dedicated SSH key
Cleanup after disconnecting

Disconnecting is not the same as finishing cleanup

After debugging, confirm in order that the tunnel process, listening port, temporary service, and logs no longer retain unnecessary access paths.

  1. Stop the SSH tunnel process Confirm that the local session has ended and will not reconnect automatically.
  2. Check the local listening port Verify that temporary ports such as 8080 have been released.
  3. Stop the temporary remote service When debugging is finished, shut down temporary services and test proxies.
  4. Revoke temporary authorization Delete public keys or access rules added only for this investigation.
CI runner access

Run a minimal test job before connecting the production pipeline

A self-hosted runner should use a dedicated working directory and the smallest practical project scope. Do not let a test runner access all team repositories, signing materials, or historical build artifacts by default.

Access checklist 4 stages
01

Register a dedicated runner

Create a dedicated runner identity for the target project and record the node, purpose, and owner. Use registration credentials only during configuration.

Identity defined
02

Limit project scope

Allow only the expected repositories and job types to call this runner. Configure labels as required by the workflow and avoid overly broad generic matching.

Scope controlled
03

Set the working directory

Separate source code, dependency caches, build artifacts, and temporary files. Check available disk space and cleanup rules after each job.

Directory isolated
04

Complete a minimal test job

First run environment checks, a code checkout, and a small test build. Confirm that logs, exit codes, and artifact paths are correct before adding production jobs.

Ready to connect
Mobile access

Use your phone for status checks, not complete credentials

A small screen is suitable for checking delivery progress, session alerts, order numbers, and node status. Switch to a controlled desktop device when copying complete access details, managing SSH keys, or performing recovery operations.

Delivery status Available
Session alerts Available
Order information Available
Complete private key Not shown
Suitable for mobile

Quick confirmation

Check whether the order has been delivered, whether the node matches, and whether any session alert needs attention. Record when the issue occurred.

Switch to desktop

Secure operations

Use a controlled desktop device to upload public keys, replace credentials, copy host fingerprints, view complete connection details, and run commands.

Troubleshooting

Check the chain in order; do not change multiple variables at once

Record the result after each step. If you change the network, port, key, and client at the same time, the issue may disappear temporarily without revealing the real cause.

01

Check the local network

Confirm that the current network can access external services normally, disable temporary proxies that may rewrite routes, then retest on a known-good network.

Network recorded
02

Verify the node address

Copy the node address again from the current order. Avoid old orders, saved client entries, or historical addresses in chat records.

Address matches
03

Verify the protocol port

Confirm that remote desktop and SSH use their respective ports, and check whether the local network restricts outbound connections to that port.

Port reachable
04

Check key permissions

Confirm that the private-key path is correct, permissions are sufficiently restrictive, the public key was submitted to the target node, and the client is actually using the expected key.

Authentication passed
05

Check remote session status

Confirm that the username matches the graphical session. If the desktop is unresponsive, establish a new session instead of repeatedly sending large numbers of connection requests.

Session normal
06

Check sleep settings

Confirm that lock and sleep policies during long-running tasks match workflow requirements, and verify that the runner or scripts do not stop when the graphical session disconnects.

Task continues
Prepare to connect

Choose a node and configuration; complete delivery in about 4 minutes

Three tiers of dedicated physical machines cover Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, the US East Coast, and the US West Coast. After delivery, verify remote desktop and SSH in the order shown on this page.

Only USDT-TRC20 and Visa / Mastercard / Amex (via Stripe) are supported. All payments are settled in USD.

Rent a Cloud Mac now View the three plans