Rent a Cloud GPU with SSH: Your Key, One Command, VS Code Included

Until today a ParalonCloud rental opened one way: JupyterLab in the browser. It is a good way to start, and a poor one for the work many people rent a GPU to do: a training script started from your own terminal, a dataset pushed with rsync, a repository opened in VS Code as if it were local.

Now you choose at Rent. JupyterLab works as before. SSH gives you a root shell on the machine from your own terminal, logged in with your SSH key. It works on every machine whose rental image is current, which is nearly all of them; the node page says "JupyterLab or SSH" where it does.

What you get

• A root shell in the rental's container, with every GPU of the machine, nvidia-smi, Python and PyTorch. Install anything else with pip, conda or apt.
• Keys only. There is no password to guess and none to leak: the machine accepts the public keys saved on your account and nothing else.
• Nothing opened on the provider's side. The machine is usually someone's computer behind a home router; SSH reaches it through the rental's own encrypted tunnel, the same one JupyterLab uses, so no port is forwarded and no address is exposed. How that tunnel works.
• The same billing as any rental: per minute, from the moment the machine answers, at the price shown when you start.

Step by step

1. Add your public key

If you have no key yet, make one:

ssh-keygen -t ed25519
cat ~/.ssh/id_ed25519.pub

Copy the line that starts with ssh-ed25519 and paste it on the SSH keys page (Account → SSH keys), or right on the GPU's page when you pick SSH. It is the public half; the private key never leaves your computer. ed25519, ecdsa and RSA keys of 2048 bits or more are accepted.

2. Start an SSH rental

Pick a GPU, and under How you connect choose SSH. Accept the terms and start. The page shows each step; in our test this morning an RTX 4090 in Bucharest was answering 9.7 seconds after the start, and another one 20 seconds after.

Every key saved on your account goes onto the machine when it starts. A key you add later is not on a rental that is already running.

3. Install cloudflared, once

You connect through cloudflared, Cloudflare's small client for the tunnel:

brew install cloudflared                      # macOS
winget install --id Cloudflare.cloudflared    # Windows

On Linux, download the binary from Cloudflare's releases page. It is one file, installed once.

4. Connect

When the machine is up, the page (and My Rentals, and the "rental ready" email) gives you the command:

ssh -o ProxyCommand="cloudflared access ssh --hostname %h" [email protected]

Answer yes to the host key question the first time. If your key is not one of the default files in ~/.ssh, add -i path/to/private_key. You land in /workspace.

root@r-c1589649…:/workspace# nvidia-smi --query-gpu=name,memory.total --format=csv,noheader
NVIDIA GeForce RTX 4090, 24564 MiB

scp, rsync and VS Code

The same ProxyCommand works for everything that speaks SSH. Put it in ~/.ssh/config once per rental:

Host paralon-gpu
  HostName r-c1589649009441f2b32d.paraloncloud.com
  User root
  ProxyCommand cloudflared access ssh --hostname %h

Then:

ssh paralon-gpu
scp model.safetensors paralon-gpu:/workspace/
rsync -av data/ paralon-gpu:/workspace/data/

In VS Code, install Remote-SSH, run "Remote-SSH: Connect to Host…" and pick paralon-gpu. The editor runs locally, the code and the GPU are on the rented machine. Cursor and other VS Code-based editors work the same way.

From code and from AI agents

The Rental API has the same choice. Save a key with POST /api/v1/ssh-keys, rent with "type": "ssh", and GET /api/v1/rentals/{id} returns connection.ssh_command:

curl -X POST https://paraloncloud.com/api/v1/ssh-keys \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d "{\"public_key\": \"$(cat ~/.ssh/id_ed25519.pub)\"}"

curl -X POST https://paraloncloud.com/api/v1/rentals \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"node_id": "<node_id from /gpus>", "type": "ssh"}'

GET /api/v1/gpus marks the machines that take SSH with "ssh": true. The details, errors included, are in Create & manage rentals.

For agents this is the bigger change. With JupyterLab an agent can start a GPU and hand you a link; with SSH it can use the machine itself. The MCP server (@paraloncloud/mcp 1.4.0) has add_ssh_key, and create_rental takes type: "ssh". Ask Claude Code "rent a 4090 over SSH, run nvidia-smi on it, then stop it", and it makes a key, saves it, rents the machine, runs the command and stops the rental. That is the test we ran this morning, end to end, through the published package. Setting up the MCP server takes a minute.

What to know

• Your keys go on every SSH rental. Delete a key you no longer use from the SSH keys page; new rentals stop accepting it at once, a running one keeps it until it stops.
• It is a container, not the host. You are root inside it. Docker does not run inside a rental, and no other port is reachable from outside.
• Everything is wiped when the rental ends. Copy results off with scp or rsync before you stop it.
• Processes survive a dropped connection only if you start them that way: use tmux (installed) or nohup for long jobs.

Ready? Pick a GPU, or see the RTX 4090 and RTX 5090 pages for what each card measured on our network.