Getting started after delivery

Connection Guide: First Login via SSH or RDP

Connect to TcpNode DGX Spark over SSH to access NVIDIA DGX OS. After delivery, check the machine details in the console, then connect using the listed address and credentials.

This guide covers DGX OS access and environment checks first. Separate instructions for dedicated server SSH, RDP and multiple IPs appear below.

From order to development environment

Follow the delivery details for your first DGX login

Payment and delivery are separate steps. Once the delivery email arrives, sign in to the console with the account associated with the order. Find connection details in the machine information.

  1. Configure a rental order

    On the TcpNode DGX order page, choose the rental duration and review and accept the confirmations about architecture, operating system and data handling at expiry.

  2. Complete payment

    Choose a payment method shown at checkout and pay for the order.

  3. Check the delivery email

    Find the delivery notification in the account email inbox and confirm which order it refers to.

  4. Open machine details

    Sign in to the TcpNode console, open the relevant machine and find its IP address and login credentials.

  5. Log in via SSH

    Enter the connection details from the machine information in a local SSH client to access DGX OS.

Use the machine details for the relevant order

The email confirms delivery; connection details are in the console. For multiple orders, check the machine name and order record before copying the address. Do not combine credentials or connection settings from another machine with the current address.

Host
IPv4 address listed in machine details
Login
Username and authentication details for this machine
Connection settings
Use the settings shown in the delivery details
SSH and CUDA checks

Check the architecture and toolchain after your first DGX OS login

NVIDIA DGX OS is based on Ubuntu 24.04, runs on ARM64 and comes with CUDA and the NVIDIA AI software stack preinstalled. DGX Spark includes 1 Gbps unmetered bandwidth and 1 static IPv4 address, with SSH access.

Set the SSH target using the delivery details

In the commands below, LOGIN_USER and SERVER_IP are variable names for the login username and IP address provided in the console. Set the variables in a local terminal before running the commands. Enter the password only at the client’s authentication prompt; do not include it in a command or support ticket.

If the delivery details list separate connection settings, enter them in the client as well. When prompted to verify the host identity on first connection, confirm that the target address matches the order before proceeding.

Local SSH client

ssh "${LOGIN_USER}@${SERVER_IP}"

Do not run this until the variables are set. This example does not specify a username, password or port.

Check the environment remotely before installing dependencies

After connecting, check the system architecture, GPU and CUDA compiler in turn.uname -m checks for an ARM64 environment;nvidia-smi shows GPU and driver details;nvcc --version shows the CUDA compiler version.

The CUDA compatibility version in the driver details and the compiler version are different fields. Neither alone confirms that the development environment is compatible. When deploying Python packages or containers, also check for ARM64 builds and confirm the CUDA version required by the project.

Run after logging in to DGX OS

uname -m
nvidia-smi
nvcc --version

Keep the original output for troubleshooting. If a command is missing or returns an error, record it rather than repeatedly reinstalling drivers and obscuring what happened.

Check ARM64 dependencies separately

Packages and container images must support ARM64. x86 programs cannot run as native applications, and DGX Spark does not support Windows.

Prepare models and experiment files separately

No models are preinstalled. Renters are responsible for downloading model weights, project dependencies and experiment data. Root access is available for installing other development tools.

How to troubleshoot connection issues

First identify whether the issue is connection or environment related

A failed SSH connection and a CUDA program error require different troubleshooting details. In a TcpNode support ticket, describe the last successful step rather than simply saying “it doesn’t work.”

Connection timed out or refused

Check the target IP, delivery details and local network. Include the full client error and note whether the authentication prompt appeared. If the connection was never established, do not start by changing the remote CUDA environment.

Connection

Authentication failed

Recheck the login and authentication details in machine information, and look for extra spaces when copying. The ticket can specify the authentication method, but must not include a password, private key or verification code.

Identity check

CUDA command fails after login

Include the architecture and GPU checks, compiler version and output from the failed command. Note whether a new driver was installed, the toolchain was changed or a dependency without ARM64 support was used.

Environment check

Use the console for emergency access and system operations

The browser-based graphical session in the console is an emergency access option when SSH or RDP is unavailable; it is not a replacement for routine remote access. DGX Spark has no BMC or IPMI. Request hard reboots and OS reinstalls through a TcpNode console support ticket.

In the ticket, include the order, exact error, stage of the failure, recent changes and checks already completed. Redact credentials from screenshots. Back up weights, code and logs, and transfer any data that needs to be kept before the rental expires. Data is deleted after expiry.

Connecting to AMD dedicated servers

Choose SSH or RDP based on the dedicated server’s operating system

After a TcpNode AMD dedicated server is delivered, find its address and credentials in the machine details in the console. Use SSH for Linux, FreeBSD and Proxmox VE; use RDP for Windows Server. The instructions below apply to dedicated servers only.

Linux, FreeBSD and Proxmox VE

Enter the target IP, username and authentication details from the machine information in an SSH client. The SSH command shown above also applies, but replace the variables with the delivery details for this dedicated server.

After your first login, confirm that the installed operating system matches the order before configuring the network, storage or software. Do not confuse the Proxmox VE host system credentials or address with those of a virtual machine.

SSH access

Windows Server Remote Desktop

Open a local RDP client and enter the IP address from the machine details in the Computer field. Enter the account listed in the delivery details, then provide the credentials when prompted.

The operating system language is the English, Traditional Chinese or Simplified Chinese option selected when ordering. After connecting, check the operating system and language before configuring business software. The local client’s display language does not change the remote operating system’s language.

RDP access

With multiple IPv4 addresses, use the first address in the list for the initial connection

Dedicated servers include 1 dedicated IPv4 address. If the order includes additional IPv4 addresses, continue to use the first address in the assigned list for SSH and RDP. Configure the others in the operating system; do not substitute them for the initial login target. Keep the current connection working before making changes, to avoid losing access due to a network misconfiguration.

Check disk configuration separately from remote login

The dedicated server’s 2×1TB NVMe drives are directly attached, with no hardware RAID. Optional additional drives are also directly attached. A successful SSH or RDP login does not mean data redundancy is in place. Renters are responsible for planning software RAID, ZFS mirroring and separate backups.

Report dedicated server issues through a console support ticket

Include the order, first IPv4 address, installed operating system, exact SSH or RDP error, and recent firewall, network or account changes. TcpNode handles hardware and network issues; renters are responsible for system configuration, software and data backups. Before requesting a hard reboot or reinstall, describe the current issue and any data that needs to be preserved.

Start with the machine details for the relevant order

Find the credentials in the TcpNode machine details. If the connection still fails, submit a support ticket with the exact error and checks already completed.

Open TcpNode Console