Connect over SSH

Once your server is running and your SSH key is installed on it, you can open a shell from your own terminal. There is nothing to install in the panel for this: you run one command on your computer and you are in. This page covers the everyday connection, pointing at a specific key, IPv6, and what to do when the connection is refused.

What you need

• The server's public IPv4 address, or its IPv6 address. Open the instance in dash.galaxygate.net and read it from the network details on the Overview tab.
• The login user. On most images this is root. Some templates use a distribution default such as ubuntu or debian. The instance page shows the default user for your image.
• The private key on your computer that matches the public key you uploaded to your workspace.

Connect

Open your terminal and run this, replacing SERVER_IP with the address from the instance page:

ssh root@SERVER_IP

The first time you connect, SSH shows the server's fingerprint and asks whether you want to continue. This is normal for a new server. Type yes and press Enter. SSH remembers the server after that, so it only asks once.

The authenticity of host 'SERVER_IP' can't be established.
ED25519 key fingerprint is SHA256:fE0ouVWyyFMhjWs74cKL0UOPygnJXmlCzaJijlNCf.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

Point at a specific key

SSH uses the default key in ~/.ssh automatically. If your private key lives somewhere else, or you keep more than one key, name it with -i:

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

Connect over IPv6

Every instance also gets an IPv6 address. Connect exactly the same way, using the v6 address in place of the v4 one:

ssh root@2001:db8::1234

Use the login user for your image

If the image is not one that logs in as root, swap the user in front of the @. For an Ubuntu image that expects the ubuntu account, run ssh ubuntu@SERVER_IP.

If it will not connect

Work through these in order. Most first-time failures are one of the top three.

Message	Likely cause	What to do
Permission denied (publickey)	The workspace did not have your key when the server was built, or you are offering the wrong key.	Confirm the key is listed under Security then SSH Keys, and retry naming it with ssh -i /path/to/private_key. If the server was created before you added the key, reset the root password and get in through the VNC console.
Connection refused	The SSH service is not up yet, or the server is powered off.	Give a fresh server a minute to finish its first boot. Confirm it is powered on under Power controls, then try again.
Connection timed out	A network or firewall problem, or the wrong address.	Recheck the address on the instance page. If you have added firewall rules on the instance's Firewall tab, make sure TCP port 22 is allowed.
Locked out no matter what	Wrong login user, a broken authorized_keys, or a firewall rule that blocks you.	Open the VNC console. It attaches a screen and keyboard straight to the machine and does not depend on SSH or your key at all.

No password to fall back on?

SSH keys are not used at the VNC console: it is a local login that needs a password. If you have never set a root password, set one first with Passwords & reset, then open the console and log in with it.

Next step

If you can never get a shell, the browser console is your safety net. It works even when SSH is completely broken.

VNC console