Connecting to your server

Everything you do on a server after the build finishes happens on the machine itself, not in the panel, so this is the step between a freshly built server and a working login.

How you get in depends on what the server runs. A Linux server takes an SSH session. A Windows server takes a Remote Desktop session. The panel tells you which one you have, and the sections below are labelled by operating system so you only need to read your half.

Finding your server's address

The Quick connect card on the Overview tab carries everything you need to open a session:

• Assigned IPv4 is the server's public address, with a copy button next to it.
• Below it the card shows the way in for this server's operating system. On a Linux server that section is headed SSH and shows the exact command, ssh root@ followed by the address, with a button that copies the whole command. On a Windows server it is headed Remote Desktop and shows Administrator@ followed by the address, with a button that copies the address and a Download .rdp link beneath it.

Which of those two you see is the fastest way to tell which half of this page applies to you. The System card further down the Overview tab names the image itself under Operating system.

If the card reads "IP assigned after provisioning." instead, the server does not have an address yet. That means the build has not finished, or the server has never had an operating system installed. See While your server builds.

The Network tab lists the same address again under Address, along with its Gateway and any IPv6 addresses on the server. Use the Overview card for connecting and the Network tab when you need the surrounding detail.

Signing in to a Linux server

The username is root. For the first password, the panel points you at your activation email: "Use the credentials sent in your activation email, or open the VNC console from the Options tab." If you do not have that password, you can set a fresh one from the panel under Resetting the root password, or reach the machine through the browser console instead.

If you picked SSH keys during the build, those keys are already installed on root and you can connect without the password at all.

Connecting to a Linux server over SSH

The examples below use 203.0.113.10. Substitute your own Assigned IPv4. The next two headings describe the computer you are sitting at, not the server: the server is Linux either way.

From macOS or Linux

Open Terminal and run:

ssh root@203.0.113.10

The first time you connect to a new server, SSH shows you the server's host key fingerprint and asks whether to continue. Type yes and press Enter. It only asks once per server, and being asked again later means the key changed, which is worth understanding before you accept it. A rebuild generates a new host key, so after reinstalling you will see a loud warning about a changed key. Remove the stale entry and reconnect:

ssh-keygen -R 203.0.113.10
ssh root@203.0.113.10

Then enter the root password when prompted. Nothing appears on screen while you type a password into SSH, not even asterisks. That is expected.

From Windows

Windows 10 and Windows 11 include an OpenSSH client, so the command is identical. Open PowerShell or Command Prompt and run:

ssh root@203.0.113.10

If you prefer a graphical client, PuTTY works too. Put the Assigned IPv4 in the host name box, leave the port at 22, connect, and enter root as the username when it asks.

If SSH is not on port 22

SSH listens on port 22 by default and the panel does not change that. If you have moved it yourself, pass the port explicitly:

ssh -p 2222 root@203.0.113.10

Password or key on a Linux server

Both work. A key is the better habit: it cannot be guessed, it cannot be shoulder-surfed, and it does not have to be retyped.

Using the password

The panel points you at your activation email for the first one. You can change it from inside the server with passwd, or reset it from the panel under Resetting the root password.

Using a key

If you already have a key on your machine, point SSH at its private half:

ssh -i ~/.ssh/id_ed25519 root@203.0.113.10

If you do not have one, create it locally. This writes id_ed25519 and id_ed25519.pub into ~/.ssh, on Windows C:\Users\<you>\.ssh:

ssh-keygen -t ed25519

The panel can also generate a keypair for you and store the public half against your account. See SSH keys. That page is for Linux servers only: the keys it holds are injected into /root/.ssh/authorized_keys at build time, and a Windows server has no such file.

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh root@203.0.113.10 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Signing in to a Windows server

The username is Administrator. For the password, the panel points you at your activation email. The Quick connect card tells you to sign in as Administrator "with the password from your activation email", and the card's footer repeats "Use the credentials sent in your activation email, or open the VNC console from the Options tab."

If you do not have that password, reset it from the Options tab. The control is labelled "Reset root password", but on a Windows image the panel resets Administrator rather than root. Verify the result by signing in with the new password rather than trusting the confirmation screen. See Resetting the root password.

There is no key-based equivalent on Windows. Remote Desktop signs in with a username and a password, and the panel's SSH keys page does not apply here.

Connecting to a Windows server over Remote Desktop

Remote Desktop listens on TCP port 3389 by default. The examples below use 203.0.113.10. Substitute your own Assigned IPv4.

With the .rdp file

From a Windows PC

If you would rather type the address yourself, use Remote Desktop Connection, which ships with Windows. Open it from the Start menu, put the Assigned IPv4 in the computer box, connect, and sign in as Administrator with the password.

To skip straight to the connection dialog, run:

mstsc /v:203.0.113.10

Remote Desktop may warn that it cannot verify the identity of the remote computer before it connects. That warning is about the certificate the machine presents, not about the address or your credentials.

From a Mac

macOS has no built-in Remote Desktop client, so install one first. Add a connection using the Assigned IPv4 as the address, then sign in as Administrator with the password. A client that reads .rdp files can import the one from Quick connect instead, which fills in the address and the username for you.

First-login checklist

Do these three things in your first session, before you install anything.

If you cannot connect

Work down this list in order.

Check the server is running. The power bar at the top of the Overview tab shows the Power state. If it reads Stopped, click Boot and wait. See Power controls.

Open the console. The console is a screen attached to the machine itself, so it works when the network stack is down and when the firewall inside the server is blocking you. On Linux it also covers SSH not running and locking yourself out with a bad sshd_config. On Windows it covers Remote Desktop being turned off or blocked by Windows Firewall, which is the same dead end from the other direction. This is the tool for exactly the situation where SSH or Remote Desktop gives you nothing. See Console access.

Check the port is reachable. SSH needs TCP port 22 and Remote Desktop needs TCP port 3389. Default for unlisted ports starts on Allow, so both are reachable on a new server without you doing anything. If you have switched that default or added rules, check that the port you are connecting on is still covered. See Port rules.

Check what the error actually says. A connection that hangs and then times out is a network or firewall problem. A connection that is refused immediately means the address is reachable but nothing is listening on that port, usually because SSH or Remote Desktop is not running on the server. Getting as far as a credentials prompt and being rejected, Permission denied over SSH or a rejected sign-in over Remote Desktop, means you reached the server and the username or password was wrong, which is not a connectivity problem.

If it is your players rather than you. When you can reach the server yourself but clients cannot reach the service you run on it, that is a protection or rule problem rather than a connection problem. Go to When players cannot connect.

Related