SSH (Secure Shell) is an encrypted method for logging in to a remote computer, usually your web server, and running commands on it as if you were sitting in front of it. Developers use it to update software, move files, run backups and fix problems that the hosting dashboard cannot reach.
How SSH works
An SSH client on your computer opens a connection to an SSH server running on the host, by default on port 22. Before anything else happens, the two sides agree an encryption key, so every command and response that follows is scrambled for anyone listening on the network. The server then checks who you are.
There are two common ways to prove identity. Password login is the simplest, but passwords can be guessed or stolen. Key-based login is stronger: you generate a key pair, keep the private key on your own machine, and place the public key on the server. When you connect, your computer proves it holds the matching private key by signing data the server can check, so the secret itself never crosses the network. Modern setups use Ed25519 keys, and the private key should be protected by its own passphrase.
SSH also carries other tools. SFTP, the secure way to transfer files, runs over an SSH connection. Developers use SSH to pull code from version control onto the server, and on WordPress sites the WP-CLI command-line tool lets them update plugins, search and replace URLs in the database or export content in seconds.
Why it matters
Some jobs are slow, risky or impossible through a hosting control panel. A site migration that moves a large database, a bulk change to thousands of URLs after a restructure, or a server-side redirect rule all go faster and more reliably over SSH. Many entry-level shared hosting plans restrict or disable it, while a virtual private server gives full access. If your developer keeps saying “the host won’t let me”, this is often why.
SSH access is also the master key to the server. Anyone with a working key can read customer data stored in the database, replace pages or plant malware. Under UK GDPR you are expected to keep personal data secure, which includes knowing who can reach the server it sits on. A key left behind by an agency you stopped working with three years ago is exactly the kind of gap that causes trouble.
Common mistakes
- Leaving password login switched on. Servers with SSH open to the internet receive constant automated login attempts. Keys plus disabled password login removes that whole class of attack.
- Sharing one account or key between several people. When someone leaves, you cannot remove their access without locking everyone out, and you cannot tell who did what.
- Never auditing authorised keys. Old freelancers and agencies keep access long after the contract ends.
- Logging in directly as root. A mistyped command as the all-powerful user can wipe the server. Use a named account with limited rights and switch to full admin rights only for the task that needs them.
- Emailing private keys. A private key should never leave the machine of the person it belongs to.
How to act on it
Ask your host or developer three questions: whether SSH is enabled, which named people hold keys, and whether password login is turned off. Ask for each person to have their own key, and remove keys when a working relationship ends, the same way you would collect an office key. If your host offers it, restrict SSH to known IP addresses.
The same rule applies to anyone doing technical SEO work that needs server access: give them their own key for the length of the job, never a shared password, and revoke it when the work ends.