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 upgradeordnf 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, thentimedatectl, because wrong time breaks certificates and logs - Turn on automatic security updates -
unattended-upgradeson Debian and Ubuntu,dnf-automaticelsewhere - 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
