Anyone who has bought a standalone server has received a message from the company with a line like ssh root@203.0.113.10. Anyone who has opened a guide to managing a Linux server has met the same command in step one. Most of us copy it, paste it, type the password and move on, without knowing what happened between our computer and the server, why some companies ask you to upload a "key", or what the warning message at the first connection means.
SSH is the tool that answers all of these questions, and understanding it is not only for professional sysadmins. A WordPress owner on a VPS needs it, anyone who deploys a site with Git needs it, and anyone who wants to protect a server from password-guessing attacks starts with it. This guide starts from the definition and ends with a working secure connection, with a list of the mistakes you will hit along the way.
📋 Quick summary: SSH at a glance
| Item | Details |
|---|---|
| Full name | Secure Shell |
| What it is | An encrypted network protocol for running commands, transferring files and forwarding ports on a remote machine |
| Default port | 22 (TCP) |
| Origin | 1995, by the Finnish researcher Tatu Ylönen |
| Version used today | SSH-2 (documented in RFC 4251 to 4254 in 2006) |
| Best-known implementation | OpenSSH: free and open source, released in 1999 with OpenBSD |
| Login methods | A password, a public and private key pair, SSH certificates, or a physical security key (FIDO2) |
| Best key type today | Ed25519 |
| Most common uses | Server administration, SFTP, scp and rsync, tunnels, Git, automation and deployment |
What is SSH? Definition and history
SSH stands for Secure Shell. It is a protocol that lets you connect to another machine over the network and run commands on it as if you were sitting in front of it, with everything between the two ends encrypted: commands, output, passwords and files. Your machine is the client, and the machine you connect to is a remote server running a service called sshd, usually located in a data center in another country.
"Shell" means the program you type commands into, such as Bash. SSH does not replace it; it brings it to you from the server, safely. When you buy web hosting or a server and receive login details, those details are usually for SSH or SFTP.
Why did SSH appear in the first place?
Before SSH, remote administration used Telnet, rlogin and rsh, which all sent everything as clear text, including the password. Anyone capturing the network traffic between the two ends could read every character. In 1995 a password-sniffing attack hit the Helsinki University of Technology network, so researcher Tatu Ylönen wrote an encrypted replacement and released it for free, and within months it spread across universities and companies worldwide.
The project later became a company and its licensing tightened, so the OpenBSD team took the last free version and developed it into OpenSSH in 1999. This is the implementation you use today on Linux, Mac and Windows, often without noticing.
From SSH-1 to OpenSSH 10
The first version of the protocol (SSH-1) had flaws in its design itself, so SSH-2 was released with a new, incompatible design and documented officially in RFC 4251 to 4254 in 2006. OpenSSH dropped SSH-1 support completely in version 7.6 in 2017, so what you use today is always SSH-2.
Vultr bills by the hour, so you can create a test server and delete it after a few hours for a small cost
☑️ Try Vultr now
How does SSH work? What actually happens when you connect
When you type ssh user@server, your machine opens a TCP connection to the server on port 22. You can type an IP address or a domain name, and in the second case DNS turns it into an IP address before the connection starts. The connection then goes through four stages before the terminal appears. The protocol is officially split into three layers (transport, authentication and connection), but it is clearer for the reader to see them in the order they happen.
Stage one: agreeing on encryption
Each side announces its protocol version, then they exchange lists of the algorithms each one supports (key exchange, packet encryption, integrity checks) and choose the strongest option they share. They then perform a key exchange, which generates a secret session key without that key ever crossing the network. From this moment everything is encrypted, and the key is renewed periodically during long sessions.
Stage two: verifying the server's identity
Before you type your password, your machine wants to be sure it is talking to the right server and not an intermediary pretending to be it. The server proves its identity with its own host key, and you see its fingerprint at the first connection:
The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?If you type yes, the fingerprint is saved in ~/.ssh/known_hosts and your machine will not ask again. If the fingerprint changes later for no known reason, SSH stops the connection and warns you. Do not ignore that warning.
Stage three: verifying who you are
Now the server checks that you are the user allowed to log in. The available methods are a password, a public and private key pair (the best option), SSH certificates, or a physical security key that supports FIDO2. Most beginners start with a password and then move to keys, which is what the next section covers.
Stage four: opening channels
After authentication, SSH opens several channels inside the single encrypted connection: one for the interactive terminal, one for running a single command, one for file transfer over SFTP, and channels for port forwarding (tunnels). That is why one SSH connection is enough for all of these jobs together.
SSH keys: public and private, without the complexity
A password is a secret shared between you and the server: you type it and send it (encrypted) at every login, and if it is guessed or stolen the door falls. Keys rest on a different idea: a pair of mathematically linked files, one you can give to anyone and one that never leaves your machine.
The public key is a lock you put on any server you want to enter, and it does not matter who sees it. The private key is the only key that opens that lock, and it stays on your machine.
The technical detail shows why this is safe. When you log in, your machine never sends the private key. The server asks for proof, your machine digitally signs the session data with the private key, and the server verifies the signature with the public key it stores. If an attacker captured all the network traffic, there would be nothing in it that lets them log in again.
Why are keys stronger than passwords?
First, an Ed25519 key cannot realistically be guessed by brute force, while passwords are guessed automatically on every exposed server. Second, no secret crosses the network at all. Third, scripts and deployment tools work with a dedicated key without storing a password in a file. And fourth, revoking access means deleting one line from the authorized_keys file, instead of changing a password that more than one person knows.
SSH key types: which one should you choose?
| Type | Typical size | Status today | Note |
|---|---|---|---|
| Ed25519 | 256 bits | Recommended | Small, fast and strong, and the default in modern ssh-keygen |
| RSA | 3072 or 4096 bits | Acceptable for compatibility | Pick it only for old systems that do not support Ed25519, and do not go below 3072 bits |
| ECDSA | 256, 384 or 521 bits | Works but less preferred | Uses NIST curves, and there is no practical reason to prefer it over Ed25519 |
| Ed25519-sk | Hardware security key | The most secure | Requires touching a FIDO2 key (such as a YubiKey) on every connection, and OpenSSH has supported it since 8.2 |
| DSA | 1024 bits | Abandoned | Removed completely in OpenSSH 10.0, so do not use it |
Where are SSH files stored?
| File | Location | Purpose |
|---|---|---|
id_ed25519 | ~/.ssh/ on your machine | The private key: never share it with anyone |
id_ed25519.pub | ~/.ssh/ on your machine | The public key: you copy it to servers |
authorized_keys | ~/.ssh/ on the server | The list of public keys allowed to log in |
known_hosts | ~/.ssh/ on your machine | Fingerprints of servers you have trusted before |
config | ~/.ssh/ on your machine | Shortcuts for connecting to servers |
sshd_config | /etc/ssh/ on the server | Settings for the SSH service itself |
⚖️ SSH vs Telnet, FTP and SFTP: where people get confused
The similar names confuse beginners most. This table settles the differences:
| Protocol | Default port | Encryption | Use |
|---|---|---|---|
| SSH | 22 | ✅ Full | A terminal, remote commands and tunnels |
| Telnet | 23 | ❌ None | A legacy remote terminal; do not use it over the internet |
| FTP | 21 | ❌ None | File transfer, with the password sent as clear text |
| FTPS | 21 or 990 | ✅ Over TLS | FTP itself, wrapped in an encryption layer |
| SFTP | 22 | ✅ Over SSH | File transfer and management inside an SSH connection |
| RDP | 3389 | ✅ | A graphical remote desktop for Windows machines |
SFTP is not encrypted FTP
Many people think SFTP is FTP with encryption added. That is not true. SFTP is a completely separate protocol that runs inside an SSH connection on port 22, while FTPS is plain FTP wrapped in TLS. That is why a program like FileZilla asks you to choose the protocol yourself, and if you pick plain FTP on port 21 there is no encryption at all. And since SFTP uses SSH, your same key works with it.
SSH and the cPanel terminal
The cPanel control panel offers a Terminal tool in the browser on many hosts, giving you a terminal on your hosting account. That is convenient for a quick command. But real SSH from your machine gives you what a browser terminal does not: tunnels, file transfer from the command line, and running automated scripts from your machine.
Contabo is known for offering more memory and storage for the price, with full SSH access to the server
☑️ See Contabo VPS plans
Practical SSH uses in server administration
Managing the server and running commands
The first and best-known use: updating packages, restarting services, reading logs and monitoring resources. Here are examples on Ubuntu and Debian:
sudo apt update && sudo apt upgrade -y
sudo systemctl restart nginx
sudo journalctl -u nginx --since "1 hour ago"
df -hAnd if you want only one command without opening a full session: ssh user@203.0.113.10 "uptime". The command runs and the output comes straight back to you.
Transferring files: scp, sftp and rsync
scp backup.zip user@203.0.113.10:/home/user/
rsync -avz ./site/ user@203.0.113.10:/var/www/site/
sftp user@203.0.113.10The scp command is simple for single files. rsync transfers only the differences on later runs, so it is the best choice for backups and repeated deployments. Since OpenSSH 9.0, scp uses the SFTP protocol in the background, but the command you type has not changed.
Tunnels: reach a service without exposing it to the internet
A MySQL database runs on port 3306 and listens locally on the server only, because opening it to the world is dangerous. Instead of opening it, you create a tunnel through SSH:
ssh -L 3307:127.0.0.1:3306 user@203.0.113.10Then you connect your database client to 127.0.0.1:3307 from your machine, and the request travels through the encrypted tunnel to the database on the server. There is also a -R option to reverse the direction (exposing a service on your machine to the server) and a -D option to create a SOCKS proxy.
Git and GitHub
When you run git clone git@github.com:user/repo.git you are using SSH. You add the public key to your GitHub account settings, then test the connection with this command:
ssh -T git@github.comAutomation and deployment
Scripts and tools such as Ansible and automatic deployment systems (CI/CD) log in to servers over SSH with dedicated keys and no password. A useful rule here: create a separate key for each tool or machine, so you can revoke one without touching the others.
Managing WordPress with WP-CLI
Anyone who runs a WordPress site on a server that allows SSH saves a lot of time with the WP-CLI tool: updating every plugin with one command, checking the WordPress version, and replacing links in the database, all without opening the control panel.
wp core version
wp plugin update --allIf you have not installed WordPress yet, start with the WordPress installation guide and then come back here.
Jumping between servers (jump host)
Some networks put only one server in front of the internet and hide the other machines behind it. You reach the internal machine through the front server with a single command:
ssh -J jumpuser@203.0.113.5 user@10.0.0.8Which type of hosting gives you SSH?
| Service type | SSH access level |
|---|---|
| Website builder | Not available |
| Shared hosting | Available on some plans, as a limited account without root |
| Managed WordPress hosting | Usually available inside the site account, with tools such as WP-CLI |
| VPS | Full, with root access |
| Dedicated server | Full, with root access |
Website builders do not give you SSH because you do not own a server to manage, which is part of the difference between hosting and website builders. Some shared hosts such as Bluehost, Hostinger, FastComet and DreamHost provide SSH, but activation and the plan you need differ from company to company. Check the support page or the chat before you pay.
Managed hosting such as Cloudways or Kinsta gives you SSH at the application level, while the server itself stays in the company's hands. With a virtual private server (VPS) or a dedicated server you get full root access, along with full responsibility for updates and security. Budget VPS providers include Contabo and UltaHost, and for a wider comparison see our best web hosting comparison.
🛠️ How to connect to a server over SSH: a practical setup with an Ed25519 key
The following commands work on Windows 10 and 11 (from PowerShell) and on Mac and Linux (from Terminal), because the OpenSSH client is built into these modern systems. Replace user with your username and 203.0.113.10 with your server's address.
ssh -Vssh-keygen -t ed25519 -C "my-laptop".ssh folder: the private key id_ed25519 and the public key id_ed25519.pub.ssh-copy-id user@203.0.113.10type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub and paste the line into your hosting provider's dashboard. Many VPS providers offer this option while you create the server, so key login works from the first time.ssh user@203.0.113.10-p option, for example ssh -p 2222 user@203.0.113.10.sudo nano /etc/ssh/sshd_configPasswordAuthentication no
PermitRootLogin prohibit-passwordsudo sshd -t
sudo systemctl restart sshssh on Ubuntu and Debian and sshd on most other distributions. And better than allowing root login with a key is to create a regular user with sudo rights and set PermitRootLogin no./etc/ssh/sshd_config.d/ may override your setting, so check the effective value with sudo sshd -T | grep -i passwordauthentication.~/.ssh/config (on Windows: C:\Users\yourname\.ssh\config) and add:Host myserver
HostName 203.0.113.10
User user
Port 22
IdentityFile ~/.ssh/id_ed25519ssh myserver, and scp, sftp and rsync work with the same name.authorized_keys on every server and create a new pair.Cloudways manages the server for you and leaves you SSH and SFTP access to your applications
☑️ Try Cloudways
🔐 Securing SSH: what is worth the effort and what is not
A new server on the internet usually receives automated guessing attempts on port 22 within hours of being created, without anyone knowing it exists. That is why securing it starts on day one, and this is the order of measures by their real effect:
| Measure | Effect | Priority |
|---|---|---|
| Disable passwords and use keys | Ends guessing attacks | Essential |
| Block direct root login | Protects the account attackers target most | Essential |
| A firewall that opens only what you need | Reduces exposed ports | Essential |
| Update the system and OpenSSH regularly | Closes known vulnerabilities | Essential |
| Fail2ban to block repeated failed attempts | Reduces load and log noise | Useful |
| A hardware security key or two-factor authentication | An extra layer for sensitive accounts | For sensitive cases |
| Change the port from 22 | Only reduces log noise | Optional |
Changing the port looks like a security measure but it is not: any port scanner finds the new port within seconds. Its only benefit is that your logs get quieter from ready-made bot attempts. If you change it, do not rely on it alone.
For the firewall on Ubuntu, the order matters:
sudo ufw allow OpenSSH
sudo ufw enableAllow SSH before enabling the firewall, or you will lock yourself out. And if you changed the port, allow the new port instead of OpenSSH.
And do not skip updates. In 2024 a serious vulnerability called regreSSHion (CVE-2024-6387) appeared in the OpenSSH server, and the fix was a simple update for anyone who updated.
🔧 Common connection errors and their fixes
| Message | Usual cause | Fix |
|---|---|---|
Connection refused | The SSH service is stopped, the port is wrong, or the firewall rejects the connection | Check the address and port, and start the service from the console in your provider's dashboard |
Connection timed out | Packets do not arrive: a wrong address, or the provider's firewall blocks the port | Open the port in the provider's firewall and check the IP address |
Permission denied (publickey) | The server cannot find your public key, or file permissions on the server are wrong | Make sure the public key is in authorized_keys and that ~/.ssh is 700 and the file is 600. Try ssh -v to see the details |
REMOTE HOST IDENTIFICATION HAS CHANGED | The server fingerprint changed: the server was reinstalled, or in a rare case someone is impersonating it | If you reinstalled it yourself, run ssh-keygen -R 203.0.113.10 and connect again. Otherwise do not connect before you find the reason |
UNPROTECTED PRIVATE KEY FILE | The private key file's permissions are open to others (common on Mac and Linux) | Run chmod 600 ~/.ssh/id_ed25519 |
SSH and a domain behind Cloudflare
If your site is behind Cloudflare with proxy mode on (the orange cloud), SSH will not pass through the domain name, because the proxy forwards web traffic only. Connect to the server's IP address directly, or create a subdomain record with a gray cloud (DNS only) and connect through it.
-v option to the connection command (or -vvv for more detail). You will see exactly which key was tried and where it was rejected.🎯 Who needs SSH, and who can postpone it?
✅ You need SSH if:
- You manage a VPS or a dedicated server
- You deploy your site or app with Git or scripts
- You manage WordPress with tools such as WP-CLI
- You want to reach a database without opening its port to the internet
- You manage several sites or clients and want to save time
❌ You can postpone it if:
- Your site is on a website builder
- You run a simple site from your hosting panel and SFTP is enough
- Your plan does not offer SSH and you do not need its benefits
- You prefer the company to handle all the technical administration
And if you choose a VPS with a ready control panel that eases the terminal's complexity, see the Hosting.com review and the InterServer review to understand the differences between their plans.
A Linux VPS with cPanel from Hosting.com combines the ease of a panel with the power of the terminal
☑️ See VPS plans with cPanel
🏆 Final verdict: what to do after reading this article
SSH is not an optional topic for anyone who owns a server. It is the one legitimate door for managing it, and a wrong setup is the shortest path attackers take: a weak password on port 22 open to the world. The practical rule is simple: an Ed25519 key with a passphrase, password login disabled, root login disabled, a firewall on and regular updates. These are five steps that take no more than half an hour and close most of what attackers usually exploit.
And if you are a beginner, do not learn on a server that holds your real site. Create a small test server or a virtual machine, try the commands and make mistakes, then delete it. And if your site is on shared hosting and you only upload files over SFTP, there is no need to complicate your life now; come back to this article when you move to a VPS.
Scala Hosting offers a managed VPS while SSH stays in your hands
☑️ See Scala Hosting offers
✅ SSH FAQ
❓ Is SSH free?
❓ What is the SSH port number, and does changing it protect the server?
❓ What is the difference between SSH and SFTP?
❓ Which is better: a password or an SSH key?
❓ Should I choose Ed25519 or RSA?
❓ What should I do if I lose the private key or suspect it leaked?
authorized_keys on every server immediately, then create a new pair.❓ Does SSH work on Windows?
❓ Does shared hosting support SSH?
❓ Do I need SSH to manage a WordPress site?
❓ Is SSH completely secure?
❓ What is the difference between SSH and a VPN?
-D option, for example), but it does not replace a VPN if you want to secure all your browsing.❓ Can I use SSH from my phone?
Kamatera lets you pick the CPU, memory and storage precisely, with full SSH access
☑️ See Kamatera VPS options
Did this guide help? Share it with someone who is starting to manage their own server. And if you hit an error message we did not list, write it to us in the comments below.
Related Articles
🖥️ What Is a VPS?
The virtual private server and why you get full SSH rights on it. Read: What Is a VPS and How It Works
🗄️ What Is a Server?
The machine you connect to over SSH, and how it serves sites around the clock. Read: What Is a Server
🌐 What Is DNS?
How a domain name becomes an IP address before any connection starts. Read: What Is DNS
🎛️ What Is cPanel?
The best-known hosting control panel and how it relates to the terminal. Read: What Is cPanel
📋 Contabo Review
A large-resource VPS at a low price, with a frank list of pros and cons. Read the Contabo review
☁️ Cloudways Review
Managed cloud hosting that gives you SSH without managing the whole server. Read the Cloudways review
