SSH for VPS Beginners: Connect Safely, Use Keys, Copy Files, and Fix Common Errors

You buy your first VPS.

A few minutes later, the provider sends you an IP address and login information.

There is no desktop.

There is no cPanel login unless you installed a control panel.

There is only an address such as:

203.0.113.25

and a word you may have seen before:

SSH

For a beginner, this can make a VPS feel unfinished.

It is not.

SSH is one of the main ways administrators securely control Linux servers over a network. Through one terminal connection you can install software, edit configuration, read logs, move files, restart services and manage an entire web server.

The command itself is simple:

ssh username@server

The important part is understanding what happens around it.

This guide starts from the first connection and builds toward a safe daily workflow.

Our VPS plans are the starting point when your project needs its own server environment. If you would rather manage a website without maintaining Linux services, compare shared hosting and read our VPS introduction before choosing.

What SSH actually does

SSH stands for Secure Shell.

It creates an encrypted connection between an SSH client on your computer and an SSH server running on the VPS.

The OpenSSH project provides common tools including:

• ssh for remote login;
• sshd for the server daemon;
• ssh-keygen for key creation;
• ssh-agent for managing keys;
• scp for file copying;
• sftp for file transfers.

When you type commands in an SSH session, they execute on the remote server, not on your laptop.

That distinction matters.

This command:

rm file.txt

inside an SSH session removes file.txt from the current directory on the VPS.

Linux assumes you mean what you type.

Before connecting: collect four details

You normally need:

1. server IP address or hostname;
2. SSH username;
3. authentication method;
4. SSH port.

A provider may give you:

IP: 203.0.113.25
Username: root
Password: temporary-password
Port: 22

Port 22 is the standard SSH port, but a provider or administrator can configure another one.

If your provider gives a different port, use it.

Your first SSH connection

On Linux, macOS, and current Windows systems with an SSH client available, open a terminal.

Run:

ssh [email protected]

Replace the example address.

If the SSH server uses another port:

ssh -p 2222 [email protected]

On first connection, you may see a message asking whether you trust the server's host key.

Do not treat this warning as meaningless.

SSH is asking you to verify the identity of the server you are connecting to.

What the host key warning means

The first time your computer connects to a new SSH server, it does not yet have a saved host key for that server.

You may see something like:

The authenticity of host '203.0.113.25' can't be established.

The message includes a fingerprint.

Ideally, compare that fingerprint with information from the VPS provider or server console when available.

After accepting a legitimate host key, your SSH client stores it in:

~/.ssh/known_hosts

Future connections can detect if the server presents a different key.

That protection matters because a changed host key can indicate:

• the VPS was reinstalled;
• the IP now points to another machine;
• SSH host keys were regenerated;
• a network or identity problem exists.

Do not automatically delete the warning and reconnect.

First understand why the key changed.

After login: confirm where you are

Once connected, run:

whoami
hostname
pwd

whoami shows the current user.

hostname shows the server name.

pwd shows the current directory.

Then identify the operating system:

cat /etc/os-release

This matters because package commands and service names can differ between Ubuntu, Debian, AlmaLinux, Rocky Linux and other distributions.

A tutorial written for Ubuntu should not automatically be copied onto AlmaLinux.

Update an Ubuntu VPS

For Ubuntu or Debian-based systems:

sudo apt update

Review available updates:

apt list --upgradable

Then, according to your maintenance policy:

sudo apt upgrade

A fresh VPS image can still have packages that received updates after the image was created.

Keep the system maintained.

Do not use root for every daily task

Some VPS providers initially give direct root access.

Root can change or delete almost anything on the system.

That is useful for administration and dangerous for routine work.

On Ubuntu, create a normal user:

adduser marco

Replace marco with your desired username.

Give the user sudo privileges:

usermod -aG sudo marco

Now open a second terminal and test:

ssh [email protected]

Then verify sudo:

sudo whoami

Expected output:

root

Do not close your working root session until you know the new account works.

That simple habit can prevent locking yourself out.

Passwords work, but SSH keys are better for administration

SSH can authenticate you in several ways.

Password authentication asks for a password.

Public-key authentication uses a cryptographic key pair.

You keep the private key on your device.

The server stores the corresponding public key.

The private key should never be uploaded to the VPS or sent to another person.

A key pair lets the server verify that your client has the correct private key without transmitting that private key across the network.

For regular VPS administration, keys are usually the better approach.

Create an SSH key

On your local computer, not inside the VPS, run:

ssh-keygen -t ed25519

You may optionally add a comment:

ssh-keygen -t ed25519 -C "my-vps-admin-key"

The command asks where to save the key.

A common default is:

~/.ssh/id_ed25519

It also asks for a passphrase.

A passphrase protects the private key file if someone obtains a copy of it.

For an administrative key, using a strong passphrase is a sensible default.

The command creates two files.

Private key:

~/.ssh/id_ed25519

Public key:

~/.ssh/id_ed25519.pub

The .pub file is the one you can place on the server.

Do not share the private file.

Copy your public key to the VPS

If ssh-copy-id is available:

ssh-copy-id [email protected]

You authenticate one more time using the current method.

The public key is added to the remote user's:

~/.ssh/authorized_keys

Now test a new connection:

ssh [email protected]

If your private key has a passphrase, your client may ask for it.

The server should no longer require the account password for key-based authentication.

Test this in a second terminal before changing SSH authentication settings.

Manual public-key installation

If ssh-copy-id is unavailable, display the public key on your local machine:

cat ~/.ssh/id_ed25519.pub

Copy the complete single line.

On the VPS as the intended user:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Edit:

nano ~/.ssh/authorized_keys

Paste the public key as one line.

Then:

chmod 600 ~/.ssh/authorized_keys

Make sure the files belong to the intended user.

Incorrect ownership or permissions can cause key authentication to fail.

If you connect through a hostname instead of an IP, our DNS lookup can check its A or AAAA record. Register and manage a suitable hostname through our domain catalog. DNS helps you reach the server; verifying the SSH host-key fingerprint establishes which server you are trusting.

Do not disable password login too early

Many security guides immediately tell beginners to edit:

/etc/ssh/sshd_config

and disable password authentication or root login.

Those can be appropriate security controls.

But there is an important order:

1. create the normal administrator account;
2. install the SSH key;
3. open a second terminal;
4. verify key login works;
5. verify sudo works;
6. only then consider tightening SSH authentication.

Otherwise, one typo can turn a security improvement into a lockout.

If you change SSH server configuration, keep your existing working session open until the new one has been tested.

Check the SSH service

On Ubuntu, the OpenSSH server service is commonly called:

ssh

Check:

sudo systemctl status ssh

Read recent logs:

sudo journalctl -u ssh --since "30 minutes ago"

Follow logs live:

sudo journalctl -u ssh -f

This is useful when a new key or login is failing.

For more log-reading techniques, see Your Website Is Down: How to Read VPS Logs Before You Restart Everything.

Copy a file to the VPS with scp

Suppose your local computer has:

backup.sql

Copy it to your home directory on the VPS:

scp backup.sql [email protected]:/home/marco/

Copy a file from the VPS back to your computer:

scp [email protected]:/home/marco/report.txt .

The final dot means the current local directory.

If SSH uses a custom port, scp uses uppercase -P:

scp -P 2222 backup.sql [email protected]:/home/marco/

Notice the difference:

ssh -p
scp -P

Linux command-line options are case-sensitive.

Use SFTP for interactive transfers

OpenSSH also provides SFTP.

Connect:

sftp [email protected]

Inside SFTP:

ls
pwd
put localfile.txt
get remotefile.txt
exit

SFTP runs over SSH.

It is not the same as old unencrypted FTP.

Many graphical file-transfer applications can also use SFTP if you prefer a visual interface.

Make repeated SSH connections easier

Typing the IP, username and custom port every time becomes annoying.

Create a local SSH configuration file:

~/.ssh/config

Example:

Host myvps
    HostName 203.0.113.25
    User marco
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Now connect with:

ssh myvps

And copy a file with:

scp backup.sql myvps:/home/marco/

This is one of the easiest quality-of-life improvements for anyone managing several servers.

Common error: Connection timed out

Example:

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

Possible causes include:

• wrong IP;
• server is offline;
• firewall blocks the port;
• provider security group blocks the port;
• you are using the wrong SSH port;
• network routing problem.

A timeout usually means your client did not complete a connection to the SSH service.

Check the VPS provider console if available.

If another access method works, verify:

sudo systemctl status ssh

and firewall rules.

Common error: Connection refused

Example:

ssh: connect to host 203.0.113.25 port 22: Connection refused

This often means the network reached the server, but nothing accepted the connection on that port.

Possible causes:

• SSH service stopped;
• SSH listens on another port;
• configuration prevented startup;
• firewall behavior is rejecting rather than dropping.

Check from the server console:

sudo systemctl status ssh

Then:

sudo journalctl -u ssh --since "30 minutes ago"

Common error: Permission denied

You may see:

Permission denied (publickey)

or:

Permission denied (publickey,password)

Possible causes:

• wrong username;
• wrong private key;
• public key missing from authorized_keys;
• file permissions are wrong;
• server does not allow the attempted authentication method.

Use verbose client output:

ssh -v [email protected]

For more detail:

ssh -vv [email protected]

Verbose mode shows which keys are being attempted and where authentication fails.

Do not publish the complete verbose output without reviewing it for sensitive information.

File transfers are also part of a backup and recovery strategy. Keep protected copies outside the VPS, test restoration, and consult our migration guide when moving a live website.

Common warning: REMOTE HOST IDENTIFICATION HAS CHANGED

This warning deserves attention.

If you deliberately reinstalled the VPS and confirmed the new host fingerprint through a trusted source, you may need to remove the old saved key.

For example:

ssh-keygen -R 203.0.113.25

Then reconnect and verify the new fingerprint.

But do not use ssh-keygen -R simply to silence a warning you do not understand.

The warning exists to protect you from connecting to a machine whose identity changed unexpectedly.

Firewall safety

Ubuntu systems may use UFW.

Check:

sudo ufw status

Before enabling a firewall on a remote VPS, ensure SSH is permitted.

A common rule is:

sudo ufw allow OpenSSH

Then verify the rule exists before enabling UFW.

If you use a custom SSH port, the rule must match the actual port.

Cloud providers may also have an external firewall or security group.

A correct UFW rule cannot help if the provider's network firewall blocks the connection before it reaches your VPS.

A safe beginner workflow

When you receive a new VPS:

1. connect using the provider's initial method;
2. identify the operating system;
3. install normal updates;
4. create a non-root administrator;
5. generate an SSH key locally;
6. install the public key for the new user;
7. verify key login in a second terminal;
8. verify sudo;
9. review firewall access;
10. only then tighten SSH authentication;
11. keep recovery-console access information available;
12. document the server and key ownership.

Do not make five security changes at once.

Make one change.

Test it.

Then continue.

That is slower for five minutes and faster for the next five years.

What SSH does not replace

SSH gives you secure remote administration.

It does not replace:

• operating-system updates;
• a firewall;
• backups;
• service monitoring;
• application security;
• malware protection;
• strong account management.

A server with a secure SSH configuration can still run vulnerable software.

Security is a chain.

SSH protects an important link.