What is SSH?

When you rent a server in the cloud (for example an Ubuntu machine from AWS, DigitalOcean, or Hetzner), it lives in a data centre far away — there is no keyboard or monitor attached to it. SSH (Secure Shell) is how you reach into that machine over the internet and control it as if you were sitting in front of it. It gives you an encrypted (scrambled so nobody can read it) connection to a remote computer’s command line. Almost everything you do in DevOps — deploying apps, reading logs, restarting services — starts with an SSH connection.

What SSH actually is

SSH is a protocol — a set of rules two computers agree on so they can talk. Specifically, it is a protocol for secure remote access: it lets you run commands on another computer over a network safely.

“Secure” is the key word. When you connect over SSH, everything you send (your password, your commands, the files you transfer) and everything the server sends back (output, logs) is encrypted. Encryption means the data is scrambled using math so that anyone who intercepts it on the network sees only useless gibberish. Only your computer and the server hold the keys to unscramble it.

SSH gives you three main things:

A remote shell — an interactive command line on the far machine (this is the most common use).
File transfer — copying files to and from the server (via scp and sftp, covered in their own page).
Tunnelling — forwarding network traffic through the encrypted connection (covered in the SSH tunnelling page).

The client/server model

SSH always involves two roles:

The SSH server (also called the SSH daemon, sshd) — a small background program that runs on the remote machine and listens for incoming connections. On Ubuntu this is provided by the openssh-server package and managed by systemd as the service ssh.
The SSH client — the program you run on your own laptop to start the connection. On Linux and macOS this is the ssh command; it ships with the openssh-client package.

A “daemon” is just a program that runs quietly in the background waiting for work. A “client” is the program that asks the daemon to do something.

You can check whether the server side is installed and running on an Ubuntu box like this:

sudo systemctl status ssh

Output:

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-06-15 09:12:04 UTC; 3h ago
   Main PID: 812 (sshd)
      Tasks: 1 (limit: 1131)
     Memory: 4.1M
        CPU: 220ms

If it is not installed, you add it with:

sudo apt update
sudo apt install -y openssh-server
sudo systemctl enable --now ssh

enable --now does two things: enable makes the service start automatically on every boot, and --now starts it immediately.

The default port: 22

A port is a numbered “door” on a machine that a particular service listens behind (ports are explained fully in the Ports & Protocols page). SSH’s official, default port is port 22. When you run ssh server.example.com with no extra options, the client tries to connect to port 22 on that machine.

You can confirm the server is listening on port 22:

sudo ss -tlnp | grep ssh

Output:

LISTEN 0  128  0.0.0.0:22  0.0.0.0:*  users:(("sshd",pid=812,fd=3))
LISTEN 0  128     [::]:22     [::]:*  users:(("sshd",pid=812,fd=4))

Port 22 is constantly scanned by automated bots on the public internet. Leaving SSH open with password login is one of the most common ways servers get compromised. The Hardening SSH page covers locking it down — use key-based login and a firewall.

If you run a firewall (Ubuntu ships with ufw, the Uncomplicated Firewall), you must allow SSH or you will lock yourself out:

sudo ufw allow 22/tcp
sudo ufw enable

Why SSH replaced telnet

Before SSH, the common tool for remote command-line access was telnet. Telnet did the same basic job — give you a shell on another machine — but with one fatal flaw: it sent everything in plain text, including your username and password. Anyone on the network between you and the server could read your credentials directly off the wire.

SSH, released in 1995, fixed this by encrypting the whole session and by authenticating the server (proving the machine you connected to is really the one you meant, not an impostor pretending to be it). Today telnet is considered insecure and is never used for logging into servers.

Feature	telnet	SSH
Encryption	None (plain text)	Strong, end-to-end
Password safety	Sent in the clear	Encrypted
Server authentication	None	Host keys verify the server
Key-based login	No	Yes
Default port	23	22
Use it today?	No — insecure	Yes — the standard

When to use SSH: any time you need to log into, manage, or transfer files to a remote Linux server. It is the default, expected tool. When not to: if you only need a web dashboard or API, you may not need SSH at all — and for fully managed/serverless platforms there may be no SSH access by design.

How the pieces fit together

This page is the foundation for the rest of the SSH section. From here:

SSH into a server shows the actual ssh user@host workflow and host-key prompts.
SSH key authentication replaces passwords with cryptographic key pairs — the secure, modern default.
SSH config lets you save shortcuts so you type ssh prod instead of long commands.
SCP & rsync cover copying files over SSH.
Hardening SSH locks the server down against attackers.

Best practices

Always use key-based authentication instead of passwords (see the SSH key page) and disable password login on production servers.
Keep openssh-server updated with sudo apt update && sudo apt upgrade so you get security fixes.
Allow SSH through ufw before enabling the firewall, or you risk locking yourself out of the machine.
Never use telnet (port 23) for remote access — it is plain text and unsafe.
Verify the server’s host key the first time you connect, and be suspicious if it ever changes unexpectedly (that can signal an attack).
Limit who can log in: create a regular user, use sudo, and avoid logging in directly as root.