After ordering a VDS, the provider sends an IP address, a login (usually root), and a password or an SSH key. All further server administration happens over SSH — there is no graphical panel on the server itself, only a console and a terminal.

Connecting to a VDS over SSH

SSH (Secure Shell) encrypts the channel between your computer and the server and listens on port 22 by default. The first connection is simply confirming that the access details are correct and the server responds.

Connecting from Linux/macOS

ssh root@your-server-ip

# If the provider issued a non-standard SSH port
ssh -p 2222 root@your-server-ip

# Connecting with a key, if password login is disabled
ssh -i ~/.ssh/id_ed25519 root@your-server-ip

Connecting from Windows

Starting with Windows 10, there is a built-in SSH client right in PowerShell or Command Prompt — nothing extra needs to be installed:

ssh root@your-server-ip

An alternative for those used to a graphical interface is PuTTY: enter the IP address in the Host Name field, keep the default port 22, choose SSH as the connection type, and the terminal window opens separately.

First Steps After Logging In

Update the system: apt update && apt upgrade -y — fresh security patches matter more than any other setting.
Create a new user instead of working under root permanently: adduser myuser && usermod -aG sudo myuser.
Generate an SSH key on your machine and copy the public half to the server: ssh-keygen -t ed25519, then ssh-copy-id myuser@your-server-ip.
Disable password login and direct root login in /etc/ssh/sshd_config, only after confirming key-based login already works.
Set up the UFW firewall: ufw allow 22 && ufw enable — a detailed breakdown of ports and rules is in the article on configuring UFW on a VDS.

Common Connection Errors Explained

The error Connection refused means the packet reached the server, but nothing is listening on port 22, or the firewall actively rejects it right away. Causes: the SSH daemon is not running (systemctl status sshd), or you are connecting to the wrong port if it was changed.

ssh: connect to host 203.0.113.10 port 22: Connection timed out

Unlike refused, a timed out error usually means the packets are not arriving at all: the server is off, the IP is wrong, or a firewall on the provider's side (a Security Group) or on the VDS itself is silently dropping packets instead of answering with a rejection.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
...
Host key verification failed.

This warning appears when the host key in ~/.ssh/known_hosts does not match what the server sent — usually after reinstalling the VDS with the same IP at a different provider, or after replacing the server itself. If you are certain the server was intentionally rebuilt, remove the old entry with ssh-keygen -R your-server-ip instead of ignoring the warning blindly.

The error Permission denied (publickey) means password login is already disabled on the server, and the client either has no matching private key or the wrong one. Check that you are pointing to the correct key file with -i and that ~/.ssh/authorized_keys on the server holds exactly the matching public half.

Comparing Ways to Log Into a VDS

Method	Security	Convenience	When to use
Root password over SSH	Low, vulnerable to brute-forcing	High, nothing to prepare in advance	Only for the very first login right after ordering the VDS
SSH key for a dedicated user	High	Medium, needs one-time setup	Ongoing server work
Provider panel console	High, bypasses the network	Low, the interface is slower than a terminal	Restoring access when SSH or the firewall is broken
SSH via VPN/bastion host	Maximum, port 22 is not exposed externally	Low, an extra node in the chain	Corporate access requirements

When a Plain Password over SSH Is Not Enough

The server holds payment data or access to a production database — a single password is not enough here, you need keys and, ideally, a second factor for sudo actions.
Several people connect to the server — a shared root password does not let you tell who did what; separate users with their own keys solve that.
Port 22 is visible from the internet and gets scanned regularly by bots — this shows up in the logs as a stream of failed login attempts; changing the port and adding fail2ban on top of SSH keys helps here, not instead of them.

Verifying the Result

Open a new SSH session in a separate window without closing the current one — if the new session connects with the new user and a key, the old one can be closed safely.
Confirm that root login with a password is truly disabled: attempting ssh root@your-server-ip with a password should be rejected.
Check the SSH daemon's status and listening port: systemctl status sshd and ss -tulpn | grep ssh.
Make sure backup access through the provider's console still works — in case the SSH configuration ever gets broken by a mistaken edit.