SSH is how you reach a VPS. Everything else, installing software, editing configuration, reading logs, happens through it, so the first connection is the gateway to all the rest.
Connecting the first time
Your welcome email has the address, a username and either a password or a key. From a terminal:
ssh [email protected]
On the first connection you are asked to verify the server's fingerprint. Accept it once for an address you recognise. If that prompt reappears later for the same server, something changed: investigate rather than accepting.
If the provider gave you root access initially, use it once to create a normal user with sudo, then stop using root.
Switch to key authentication immediately
Automated password guessing against SSH is continuous on every reachable address. A key ends that category of attack outright.
Generate a key on your own machine and copy the public half to the server:
ssh-keygen -t ed25519 ssh-copy-id [email protected]
Then confirm key login works before disabling passwords. Test in a second terminal while the first session stays open. That open session is your way back if something is wrong.
Protect the private key with a passphrase. A key file without one is a password sitting in a file on your laptop.
Disabling password logins
In /etc/ssh/sshd_config:
PasswordAuthentication no PermitRootLogin prohibit-password
Reload SSH, then open a new connection while the current one is still open. Only close the original once the new one works.
People skip that check, close the terminal, and discover the config had a typo. Recovering then needs console access from the provider.
Making it convenient
An SSH config file saves typing and mistakes:
Host myvps HostName 203.0.113.45 User username IdentityFile ~/.ssh/id_ed25519
Then ssh myvps connects. Worth doing on day one, particularly if you manage more than one server: it removes the class of error where you run a command on the wrong machine.
Long jobs need to survive a disconnection
A command running in an SSH session dies when the connection drops, and connections drop for reasons that have nothing to do with you.
Use a terminal multiplexer for anything that takes minutes:
screen -S work # run the command, then Ctrl+A then D to detach screen -r work
The job continues after you disconnect. This matters most for exactly the operations you least want interrupted: migrations, large imports, package upgrades.
Moving files
SSH carries file transfer too, so nothing extra is needed:
scp file.zip [email protected]:/home/username/ rsync -avz ./site/ [email protected]:/var/www/site/
rsync is the better tool for anything repeated; it transfers only what changed and resumes cleanly.
When you cannot connect
Connection refused. SSH is not running, or the firewall is blocking the port. If you just enabled a firewall without allowing SSH, this is why, and you need console access from the provider to fix it.
Connection timed out. Usually the network path rather than the server. Try from a different connection.
Permission denied (publickey). The key is not where the server expects, or its permissions are wrong. The .ssh directory must be 700 and authorized_keys 600, SSH refuses keys that are more permissive, deliberately.
Host key changed warning. Either the server was rebuilt, or something is intercepting the connection. Confirm which before removing the old entry.
Once you are in, securing your VPS deals with the four things to do in the first hour.
Working as root is the default and not where you should stay. How to Manage Users and Sudo Access on a VPS walks through moving off it safely.
When SSH stops answering entirely, the console is the only source of information. How to Diagnose a Server That Will Not Boot goes into reading it.
Once there is more than one server, a short config file replaces every long command. How to Use SSH Config, Jump Hosts and Key Agents explains it, including reaching a machine with no public address.
Verify the host before you accept it
The first connection asks you to trust a key, and clicking through that prompt is the one moment the protocol cannot protect you.
ssh-keyscan -t ed25519 example.com 2>/dev/null | ssh-keygen -lf - ssh-keygen -F example.com
Compare the fingerprint against what the provider shows in their panel, or against what a colleague sees from a different network. They must match.
After that first acceptance the key is stored and any change produces a warning. That warning is the protection working, and deleting the stored entry to make it go away discards the only signal you get.
When the connection is refused rather than failing
Different failures have different causes, and the message distinguishes them if you read it.
nc -zv -w 3 example.com 22 ssh -v [email protected] 2>&1 | tail -20 ssh -o ConnectTimeout=5 -p 2222 [email protected]
A refused connection means something answered and declined, usually because the service is not listening on that port. A timeout means nothing answered at all, which is a firewall or a wrong address.
An immediate refusal after accepting the key is an authentication problem rather than a connection one. The verbose output names which keys were offered and what the server said about each, which is the difference between guessing and knowing.
Do not work as the administrative user
Connecting as the highest privileged account is convenient and it removes every safety margin you have.
adduser deploy usermod -aG sudo deploy mkdir -p /home/deploy/.ssh && chmod 700 /home/deploy/.ssh cp ~/.ssh/authorized_keys /home/deploy/.ssh/ && chown -R deploy: /home/deploy/.ssh
Create an ordinary account, give it the ability to elevate, and use that for daily work. A mistyped command then fails instead of executing.
Confirm the new account works from a second session before disabling direct administrative login. Doing it in the other order is the most common way people lock themselves out of a machine they just built. Securing your VPS covers the rest of the first hour.
Keep a note of how you reach each machine
The connection details live in one person's memory and one person's configuration file, which is not a record. Write down the address, the port, which account you use, which key, and whether a jump host is involved. Keep it somewhere that does not depend on the machine being reachable. The moment this matters is when somebody else has to reach the server and the person who set it up is unavailable, which is exactly when nobody wants to be reconstructing it.