First-time verification is not a routine click
The host fingerprint is the basis for verifying the remote identity. If the fingerprint changes, stop the connection and check the console details. Do not bypass the warning by deleting local records.
First-Run Session Checklist
From Access Details to
Your First Successful Build
First verify the device status, node, username, host address, and fingerprint in the console, then choose SSH or graphical desktop access. An open port does not mean the environment is ready: the connection is complete only after identity verification, disk checks, and a minimal build.
This guide applies to dedicated HopVM Cloud Macs. Each order provides a dedicated physical machine, not a virtual machine. Access details should be shared only with authorized project members.
5 items
Pre-connection checks
2 options
Access paths
1 step
Minimal build validation
Pre-connection checks
SESSION / FIRST-RUN
- Device status
- Available for connection in the console
- Node
- Matches the order record
- Identity materials
- Username, key, fingerprint
- Local conditions
- System time and network egress are normal
Use the address, port, and credentials currently returned by the console. Do not copy them from chat history or outdated documentation.
Check first, then connect
Complete these four steps for your first connection
The connection process is not “get an address and log in.” Record the status, identity, trust, and environment so you can quickly isolate timeouts, permission errors, or build failures later.
-
01
Read the current run sheet
Sign in to the console and confirm the order ID, actual node, device status, access method, username, address, port, and host fingerprint. If the details differ from older team records, use the current console information.
-
02
Prepare local identity materials
Store the private key in a directory readable only by the current user and restrict its permissions. Never send the complete key by email, group chat, or support ticket. Use a separate connection profile for graphical clients as well.
-
03
Verify the remote identity
On the first SSH connection, compare the fingerprint before accepting the host record. For graphical desktop access, verify the device name, node, and session details to avoid connecting to an untrusted address.
-
04
Establish a development baseline
After entering the system, check the time, disk space, current user, and sessions, then query the Xcode version, fetch from Git, and run a minimal build. Record the commands, exit codes, and duration.
Command-line path
SSH connection: get identity and fingerprints right first
The commands below use a documentation-only address. Obtain the actual username, host address, port, and fingerprint exclusively from the console; do not use the example values for a real session.
SSH checklist
MODE / CLI
From key permissions to a clean exit
A
Restrict private-key permissions
The private key should be readable only by the current local user. If permissions are too broad, the SSH client will usually refuse to use the file.
chmod 600 ~/.ssh/hopvm_ed25519
ls -l ~/.ssh/hopvm_ed25519
B
Start the first connection
203.0.113.24 is a documentation example address. If the console provides a custom port, add the -p parameter.
ssh -i ~/.ssh/hopvm_ed25519 \
-p 22 developer@203.0.113.24
C
Compare the host fingerprint
When the terminal displays the fingerprint, pause and compare it character by character with the fingerprint in the console. Enter yes only when they match exactly to accept the record.
ED25519 key fingerprint is
SHA256:EXAMPLE_ONLY_REPLACE_FROM_PANEL
D
Exit and confirm the session has ended
When the task is complete, stop foreground programs first, then exit the shell normally. Do not simply close the local terminal instead of properly finishing the application.
jobs
exitKeep reproducible records
Record the connection time, time zone, local network, actual node, command parameters, and exit code. During troubleshooting, a redacted record is much more useful than simply saying “can’t connect.”
Graphical session
Use a controlled desktop session when you need Xcode and graphical apps
A graphical desktop is suitable for Xcode projects, signing configuration, simulator checks, and media apps. Its use cases differ from SSH, but you must still verify the device, node, and access details before connecting.
Confirm that the local environment is trusted
Prefer a managed work computer and a trusted network. Check the local system time and disable unnecessary screen recording, clipboard synchronization, and automatic file sharing.
- Device name matches the console record
- Access details are not stored in public documents
- The local network permits the required connection method
Enable only what the task requires
After entering the desktop, first confirm the current user and system time, then open Xcode or the target app. Transfer project materials only through a team-approved path.
- Do not share administrator credentials
- Do not leave sensitive tokens in the clipboard
- Verify file integrity after large transfers
Disable credential saving and exit actively
On public or temporary computers, disable saving of passwords and connection details. When finished, exit the graphical session; do not use screen locking as a substitute for disconnecting.
- Clear temporary downloads and clipboard contents
- Confirm that build and transfer processes have finished
- Return to the console and verify the device status
One reproducible first task
Record connection, build, and delivery in one run log
The terminal sequence demonstrates SSH, an Xcode build, and Fastlane output. It contains no real addresses or credentials; the focus is preserving commands, success markers, and exit codes.
Node SG / First Validation Session / zsh
local % ssh -i ~/.ssh/hopvm_ed25519 developer@203.0.113.24
Host key fingerprint verified against control panel record
Authenticated to documentation host using public key
hopvm % sw_vers && xcodebuild -version
ProductName: macOS
Xcode 16.x
hopvm % xcodebuild -scheme SampleApp -configuration Debug build
Resolve Package Graph
CompileSwift normal arm64
** BUILD SUCCEEDED **
xcodebuild exit code: 0
hopvm % bundle exec fastlane verify_build
Running lane verify_build
Artifact manifest written to ./artifacts/manifest.json
fastlane finished successfully
process exit code: 0
hopvm % exit
Connection closed after task completion
Record the baseline
Node, commands, duration, exit code, artifact path
Submit after redaction
Remove addresses, keys, tokens, repository credentials, and private project content
The first minute after login
Confirm the security baseline before fetching the project
A successful connection proves only that the session was established. Before handling code, models, or assets, check the system time, available disk space, current identity, key permissions, and open sessions.
System time
Run date and systemsetup -gettimezoneto confirm that the time zone and current time match the task record. Time differences can affect certificates, log ordering, and dependency downloads.
Available disk space
Run df -hto check the system volume, project directory, and cache space. Before building, reserve enough capacity for source code, dependencies, derived data, archives, and final artifacts.
Current user
Run whoami and idto confirm that the current identity matches the project’s permission model. Do not share administrator credentials for convenience or run every task in a high-privilege session.
Key permissions
Check permissions for the project’s SSH keys, configuration files, and credential directories. Never write secrets to shell history, build scripts, repository commits, or public directories readable by other members.
Open sessions
Use who,w and the team’s agreed session records to confirm the current connection. If you find an unknown session, pause sensitive operations, save redacted evidence, and submit a console ticket.
Development environment acceptance
Build a comparable baseline with a minimal task
Do not run the full pipeline first. Validate the versions, repository access, and a minimal build separately to distinguish connection, dependency, and project issues.
-
01
Record system and Xcode versions
Save the results of
sw_vers,uname -m,xcodebuild -versionandxcode-select -p. These are the essential environment fields for comparing build differences later. -
02
Test the Git read path
Run
git ls-remoteagainst a low-risk repository first to verify the network, repository permissions, and host trust, then perform a shallow clone. If it fails, retain the exit code instead of repeatedly changing credentials to hide the original issue. -
03
Run a minimal build target
Choose a scheme with few dependencies and a short runtime, explicitly specify the configuration, and record the complete command. Validate the compilation path first, then gradually add tests, archiving, and automated delivery steps.
-
04
Save baseline duration and exit code
Record the start and end times, dependency-resolution duration, build duration, peak disk usage, and exit code. When performance varies, retest the same task rather than comparing unrelated projects.
Troubleshoot by symptom
Five common connection problems: find the breakpoint before changing configuration
Change only one condition at a time and retain the before-and-after results. If support needs to intervene, include the order ID, actual node, incident time and time zone, reproduction steps, expected result, and redacted output.
Connection timed out: where should I start?
- First confirm in the console that the device status and access details have not changed.
- Check the local system time, network egress, target address, and port; do not use details from an old screenshot.
- Switch to a trusted network for a retest and record the local network type and incident time.
- Use a verbose SSH command to identify the connection stage where it stops:
ssh -vvv. - Include redacted output in the ticket; do not submit the private key or complete connection configuration.
The host fingerprint changed: can I delete the old record?
Do not delete the record and continue. Stop the connection immediately and verify the current fingerprint, node, and order ID in the console. If the change has a clear basis, remove only the corresponding host entry. If you cannot confirm it, submit a console ticket with the old fingerprint, new fingerprint, and time first observed.
Permission denied: which layers should I check?
- Confirm that the username matches the console; do not mistake your local username for the remote username.
- Check the private-key path and permissions, and confirm that SSH is loading the expected key.
- Use
ssh -vto see which key the client offers. Do not output secret content in the command. - Confirm that the copied public key was not truncated or given extra line breaks.
- Do not repeatedly try credentials from unknown sources. Preserve the first failure output and submit a ticket.
The graphical session is interrupted, but SSH still works. How should I assess it?
First use SSH to check the system time, available disk space, current user, and relevant processes to confirm that the device still responds. Then check the local graphical client version, network changes, automatic reconnection, and credential-saving settings. Do not troubleshoot by force-quitting unknown processes; when requesting support, provide the interruption time, client type, whether SSH works, and redacted logs.
A company or campus network blocks the connection. How can I narrow it down?
- Determine whether the restriction occurs during address resolution, port establishment, or authentication.
- Subject to your organization’s security rules, retest using another trusted network.
- Give the network administrator the target port and business purpose; do not send private keys or login credentials.
- Record the differences between the restricted and working networks so you do not mistake a local network issue for a node failure.
Still unable to connect?
A console ticket can be linked to the actual order and device. Before submitting, prepare the order ID, node, time and time zone, reproduction steps, last known successful time, and redacted error output.
End session and handoff
Completing the task does not mean simply closing the window
Before ending the session, stop tasks, verify artifacts, remove temporary identity materials, and update the handoff record. The next member should receive controlled access—not a copy of the previous member’s credentials.
-
01
Stop background tasks
Check shell jobs, build processes, upload tasks, and graphical applications. Let tasks finish normally before exiting the session to avoid leaving resource-consuming or incomplete processes.
-
02
Save required artifacts
Verify archives, logs, checksums, and the artifact manifest, then transfer them to a team-approved location. Do not leave the only copy in a temporary directory or only in the current session.
-
03
Remove temporary credentials
Remove temporary keys, short-lived tokens, clipboard contents, and local downloads. Check that no secrets remain in shell history or project configuration.
-
04
Complete a controlled handoff
Record the node, current task status, last successful command, artifact location, and outstanding items. Configure separate permissions for the next member; do not share administrator credentials.
Return to the console and confirm the device status
Verify that the session has ended and that the order and node records are correct. If you find unexpected access or inconsistent status, revoke the relevant permissions immediately and submit a console ticket.
Set up a Mac for your project
Rent a dedicated Cloud Mac by the day, week, month, or quarter
Three Apple Silicon configurations cover builds, everyday development, and large-memory inference. Six nodes run continuously 365 days a year. Orders are settled in USD and support only USDT-TRC20 and Visa / Mastercard / Amex (via Stripe).