How to Connect to Your New Cloud Server Over SSH

How to Connect to Your New Cloud Server Over SSH

The server is running, the panel shows an IP address, a login and a password, and now you need to get inside it. This is that first connection, plus the handful of things worth doing before you install anything.

What the panel gives you

Open the server in your control panel and look at the Access block. It holds three things you need: the IP address, the Login and the Password. Two buttons sit next to them. Generate new password makes a fresh random one, and Set new password takes one you choose. Both apply on the running server, so use them if the password has been sitting in a chat window somewhere.

The first connection

On macOS and on any Linux desktop, SSH is already installed. On Windows it has been part of the system since Windows 10 and Windows Server 2019, so the same command works in PowerShell without installing PuTTY:

ssh root@203.0.113.10

The first time, SSH will show a fingerprint and ask whether to continue. That question is not a formality: it is SSH telling you it has never seen this host before and cannot vouch for it. On a server you have just created, type yes. It stores the key in ~/.ssh/known_hosts and never asks again for that address.

Move to keys, then close the door behind you

Passwords get reused, typed into the wrong window and pasted into tickets. Keys do not. Generate one on your own machine, not on the server:

ssh-keygen -t ed25519 -C "you@example.com"
ssh-copy-id root@203.0.113.10

Then confirm a key-only login works in a second terminal window before you change anything. Keep the first one open. If the new setting is wrong, that already-open session is what you use to undo it.

Once the second window logs in without asking for a password, edit /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin prohibit-password

and reload with systemctl reload ssh on Debian and Ubuntu, or systemctl reload sshd on AlmaLinux and Rocky.

The four errors people actually hit

What you see	What it means	What to do
Permission denied (publickey)	The server is no longer accepting passwords and does not have your key	Open the KVM console and check ~/.ssh/authorized_keys and sshd_config
Connection refused	Something answered: the host is up, but nothing is listening on port 22	Console, then systemctl status ssh - the service is stopped or moved to another port
Connection timed out	Nothing answered at all: a firewall is dropping the packets, the address is wrong, or the server is off	Check the power state in the panel, then your firewall rules
REMOTE HOST IDENTIFICATION HAS CHANGED	The host key is different from the one you saved	Expected after an OS reinstall or a snapshot restore. Clear the old entry with ssh-keygen -R 203.0.113.10

The distinction in the middle two rows is the useful one. Refused means the server is reachable and the problem is a service. Timed out means your packets never got a reply, so the problem is between you and it.

The console is how you get back in

Every mistake in this article locks you out of SSH and none of them locks you out of the server. The panel has a KVM console, which is a screen and keyboard wired directly to the VM, and a text console for the systems that support it. Neither goes over SSH, so a broken sshd_config, a firewall rule that dropped your own address, or a key you deleted are all recoverable in about a minute.

That is worth knowing before you start, because it changes what counts as risky. Locking yourself out is an inconvenience here, not an incident.

The first ten minutes

• Update the system - apt update && apt upgrade or dnf upgrade, before anything else goes on the disk
• Create a user and stop using root - adduser you, add it to sudo or wheel, and log in as that from now on
• Set the hostname and check the clock - hostnamectl set-hostname web-01, then timedatectl, because wrong time breaks certificates and logs
• Turn on automatic security updates - unattended-upgrades on Debian and Ubuntu, dnf-automatic elsewhere
• Take a snapshot - before the first install, not after it breaks

Bottom line

The first connection is one command. The part worth slowing down for is the key switch, and the rule that makes it safe is simple: never close the working session until a new one has proved itself. If it goes wrong anyway, the console in the panel is still there.

Cloud servers in Czechia and Portugal, from EUR 15/mo, with the console and password reset on every one: dcxv.com/data-center#cloud