Connecting to a Server with SSH
When you rent a server in the cloud (often called a VPS, short for Virtual Private Server — a small virtual machine you rent by the month), it has no screen, mouse, or keyboard you can touch. You control it entirely over the network using a tool called SSH (Secure Shell — an encrypted way to run commands on a remote computer). This page walks you through the very first thing every DevOps engineer does with a new server: logging in. We will cover the basic command, the scary-looking fingerprint prompt, connecting on a custom port, and how to fix the two errors you will hit most often.
What the ssh command looks like
The ssh command is already installed on Ubuntu, macOS, and modern Windows. You do not need to install anything to connect. The pattern is always the same:
ssh username@host- username is an account that exists on the server (for example
root,ubuntu, ordeploy). - host is the server’s address — either a public IP address (like
203.0.113.42) or a domain name (likeapp.example.com).
A real first login to a fresh Ubuntu VPS usually looks like this:
ssh [email protected]Many providers (AWS, DigitalOcean, etc.) disable the root account and give you a regular user instead. On Ubuntu cloud images that user is almost always called ubuntu:
ssh [email protected]When to use a username other than root: Always prefer a normal user (like
ubuntu) and usesudofor admin tasks. Logging in asrootdirectly is convenient but risky — one wrong command runs with full power and there is no safety net. Most managed Ubuntu images block direct root login on purpose.
Accepting the host key fingerprint
The very first time you connect to a server, SSH does not yet recognise it, so it shows a warning and asks you to confirm:
Output:
The authenticity of host '203.0.113.42 (203.0.113.42)' can't be established.
ED25519 key fingerprint is SHA256:abc123XyZ987dEfGhIjKlMnOpQrStUvWxYz0123456789.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? This is a security check, not an error. The fingerprint is a short summary of the server’s unique identity key. SSH is asking: “I have never seen this server before — is this really the one you meant?” This protects you from a man-in-the-middle attack (where an attacker pretends to be your server to steal your password).
Type yes and press Enter. SSH then saves the server’s key so it never asks again:
Output:
Warning: Permanently added '203.0.113.42' (ED25519) to the list of known hosts.
[email protected]'s password:The saved keys live in a file in your home directory: ~/.ssh/known_hosts.
Gotcha: If you later rebuild the server (same IP, brand-new install), SSH will see a different key and refuse to connect with a loud “REMOTE HOST IDENTIFICATION HAS CHANGED!” warning. That is expected. Remove the old saved key, then reconnect:
ssh-keygen -R 203.0.113.42.
Connecting on a custom port
SSH listens on port 22 by default. A port is just a numbered “door” on a server that a specific service listens behind. Sometimes an administrator moves SSH to a different door (for example “2222”) to cut down on automated attacks. When the port is not “22”, you tell ssh which one to use with the -p flag:
ssh -p 2222 [email protected]Note the capitalisation: lowercase -p is for the SSH port. (The uppercase -P belongs to a different tool, scp.) Here are the flags you will use most:
| Flag | What it does | Example |
|---|---|---|
-p | Connect on a non-default port | ssh -p 2222 ubuntu@host |
-i | Use a specific private key file | ssh -i ~/.ssh/id_ed25519 ubuntu@host |
-v | Verbose mode — print debug detail | ssh -v ubuntu@host |
-l | Specify the username separately | ssh -l ubuntu -p 2222 host |
Typing the port and key every time gets old fast. The clean fix is an SSH config file (covered in SSH config), which lets you connect with a short nickname instead.
Troubleshooting the two common errors
Connection refused
ssh [email protected]Output:
ssh: connect to host 203.0.113.42 port 22: Connection refused“Connection refused” means your computer reached the server, but nothing was listening on that port. The usual causes:
-
You used the wrong port. SSH was moved; try the real port with
-p. -
The SSH service is not running on the server. If you have another way in (a provider web console), check it and start it:
sudo systemctl status ssh sudo systemctl start ssh(
systemctlis Ubuntu’s tool for managing background services.)
A different but related message, Connection timed out, means the packets never arrived at all — usually a firewall is blocking the port or you have the wrong IP. Check that port 22 is open in both the provider’s cloud firewall and Ubuntu’s own firewall, ufw (see Firewall with ufw).
Permission denied
Output:
[email protected]: Permission denied (publickey,password).This means you reached SSH fine, but it rejected your login. Common reasons:
- Wrong username. Using
rooton an image that only allowsubuntuwill fail. Double-check which user your provider created. - Wrong password, or the server only accepts SSH keys, not passwords. The
(publickey,password)part tells you which methods the server allows. - Wrong key. If key login is required, point at the right private key:
ssh -i ~/.ssh/your_key ubuntu@host. Setting this up properly is covered in SSH key authentication.
To see exactly where a login is failing, run with -v and read the lines about which authentication methods were tried:
ssh -v [email protected]Best Practices
- Prefer a normal user plus
sudoover logging in asrootdirectly. - Use SSH keys instead of passwords — they are far harder to guess (see SSH key authentication).
- Read the fingerprint prompt; do not blindly type
yeson a server you cannot verify. - When a brand-new server refuses to connect, suspect the cloud firewall and the wrong port before anything else.
- Use
ssh -vwhenever a login fails — it tells you the real reason fast. - Save common connections in
~/.ssh/configso you typessh myserverinstead of long commands.