Secure Multi-User SSH Access on Persistent GPU Instances

The Multi-User Access Challenge on Shared GPU Compute

Shared GPU compute creates access management challenges for engineering teams. Multiple developers often need direct terminal access to run custom environments, debug CUDA setups, or fine-tune models. Adding a cloud virtual private network (VPN) adds network latency and complex client configurations. Exposing a bare SSH daemon to the internet without proper cryptographic controls invites unauthorized access.

The solution is not more cloud network theater. Secure access relies on public key cryptography, explicit host verification, and distinct user permissions on the instance. When choosing between request-based serverless models and persistent instances, access architecture determines your operational overhead. You can review choosing a GPU deployment model: serverless, instances, or hyperscalers to understand when dedicated instances fit your workflow.

Preparing Public Keys and Wallet-First Authorization

Access control starts before your compute starts. Hostnot GPU uses a wallet-first authorization model where server-side rate calculations determine the exact rate before an instance launches. Available wallet balances exclude active reservations, preventing compute halts mid-experiment.

To configure access, engineering leads must register public SSH keys in the workspace settings before initiating deployment. The platform never holds private key material. Generating a clean key pair locally keeps credentials safe on developer workstations.

1. Generate a 4096-bit RSA or Ed25519 key pair on your local development machine.
2. Copy the public key string from your local public key file.
3. Register the key string within your platform workspace controls.
4. Select a capacity offering across 30 GPU types and 9 available regions.

Once authorized, the system injects the public key into the target instance during initial setup. This design enforces zero-trust boundaries without managing static password databases.

Verifying Host Fingerprints and Connecting Directly

When an instance provisions, the control plane displays connection parameters. These include the assigned SSH host address, the target username, the dedicated port number, and a unique SHA256 host fingerprint.

Connecting safely requires verifying this cryptographic fingerprint on the first connection attempt. Skipping fingerprint verification creates vulnerability to interception attacks across public networks.

To establish a secure direct SSH connection:

• Inspect the connection string: Retrieve the specific host, port, and user string provided by the provisioning engine.
• Initiate the SSH session: Execute the connection command from your terminal, pointing explicitly to your local private key file.
• Compare the fingerprint: When prompted by your local client, verify that the terminal key signature matches the exact SHA256 fingerprint rendered in the platform workspace.
• Confirm connection: Accept the host key only after verifying the SHA256 hash string matches.

If connection attempts fail or fingerprints mismatch, capture the current instance status and log outputs before attempting a reconnect. Private access relies on verifying these details prior to passing commands.

Establishing Workspace Boundaries for Team Members

Once logged into a persistent GPU instance, teams must establish internal boundaries. Sharing a single root session across multiple engineers leads to broken dependencies, overwritten model checkpoints, and accidental process termination.

Instead, use standard Linux user management and environment isolation directly on the instance:

• User Isolation: Create separate Linux user accounts for each engineer who requires shell access. Add their individual public keys to their respective ~/.ssh/authorized_keys files on the instance.
• Shared Storage Directories: Configure dedicated data volumes or directory permissions for shared model weights and dataset caches, keeping system-level configurations read-only for non-administrative users.
• Isolated Runtime Environments: Direct every engineer to use virtual environments or container instances. This prevents conflicting CUDA dependencies and Python library version mismatches.

For teams building reproducible multi-user workflows, building on standardized deployment configurations streamlines setup. Read our guide on how to set up a repeatable fine-tuning environment on Hostnot GPU to maintain consistent environment setups across deployments.

Instance Lifecycle and Proper Teardown Protocol

A common mistake in GPU cloud management is assuming an SSH session controls the underlying compute lifecycle. Closing a terminal window or disconnecting an active SSH connection does not terminate the GPU instance.

Compute resources, storage volumes, and server-side rate billing remain active until explicit termination actions are executed in the workspace controls. Unattended GPU instances continue to deduct from your wallet balance as long as they remain provisioned.

Follow a strict lifecycle protocol to safeguard project artifacts and manage compute overhead:

1. Offload Workload Artifacts: Transfer trained checkpoints, logs, and export artifacts off the instance to local storage or external object repositories using secure file transfer protocols.
2. Verify Active Processes: Terminate running processes cleanly within the terminal to ensure no background threads lock persistent file systems.
3. Execute Instance Termination: Navigate to the workspace control panel and trigger an explicit instance termination request.
4. Audit Completed Transactions: Review completed usage windows and billing details in the workspace ledger to confirm resource release.

Managing access boundaries directly at the SSH layer provides fast, reliable access to on-demand GPU capacity without unnecessary network infrastructure.