What is SSH: definition, how it works, and when to use it

Short answer: SSH (Secure Shell) is an encrypted network protocol for logging into a remote computer and running commands on it across an untrusted network. It listens on TCP port 22, encrypts every byte from the start of the session, and verifies both the server’s identity and yours before a single command runs. SSH replaced Telnet, which sent passwords in cleartext, and it is the transport that SFTP, SCP, rsync, and Git over SSH all run inside.

If you have ever managed a web server, deployed code, or copied a file to a host you do not physically own, you have almost certainly used SSH. It is the default administrative channel for essentially every Linux and BSD server on the internet, and it has held that position for nearly thirty years without a serious challenger.

This article covers what SSH is, how the protocol works at each stage of a connection, how it compares to Telnet and to the file transfer tools built on top of it, the main things people use it for, and where it fits in a modern hosting setup.

SSH at a glance#

What SSH actually is#

SSH is three things that share a name, and separating them clears up most of the confusion around the term.

The protocol. SSH is a specification, defined in RFCs 4250 through 4254, for how two machines negotiate encryption, authenticate each other, and then multiplex data streams over one connection. It says nothing about what those streams carry.

The server. sshd is the daemon that listens on port 22 and accepts connections. On virtually every Linux distribution this is OpenSSH’s server. It is the piece that decides whether your key is acceptable and what your session is allowed to do.

The client. ssh is the command you type. There are many clients: OpenSSH on Linux, macOS, and modern Windows, PuTTY on Windows, and libraries embedded in Git, Ansible, Terraform, and every CI system that deploys code.

The protocol was written in 1995 by Tatu Ylonen, a researcher at Helsinki University of Technology, after a password-sniffing attack on the university network. The tools everyone used at the time – Telnet, rlogin, rsh, and FTP – all transmitted usernames and passwords as readable text. Anyone with access to a router or a shared network segment could collect credentials by watching traffic. SSH was written specifically to make that attack pointless, and it succeeded so thoroughly that its predecessors are now effectively extinct on public networks.

What "secure" means here#

SSH provides three guarantees, and it is worth being precise about them because each one maps to a specific stage of the connection:

• Confidentiality. Everything after the initial handshake is encrypted with a symmetric cipher. An observer sees that two IP addresses exchanged a certain volume of data on port 22, and nothing more.
• Integrity. Every packet carries a message authentication code. If anything is altered in transit, the receiving side detects it and tears down the connection rather than acting on modified data.
• Authentication. Both directions are verified. The server proves its identity with a host key, and you prove yours with a password or a key pair. A protocol that only did the second half would still let an attacker impersonate the server.

That third guarantee is the one people skip past, and it is the reason host key warnings matter. Encryption alone does not help if you are encrypting your password and sending it to an attacker.

SSH vs Telnet#

Telnet is the protocol SSH replaced. The comparison is short because there is no dimension on which Telnet wins.

Telnet is not merely weaker. It offers no protection at all. A captured Telnet session is a complete transcript of the administrative work someone did, including the password they typed to start it. The only defensible modern use is on a physically isolated management network talking to old hardware that supports nothing better, and even then it is a liability rather than a choice.

The same reasoning killed plain FTP for file transfers. FTP has the identical flaw plus a two-connection design that fights with every firewall it meets. If you still have an FTP workflow anywhere, the comparison in SFTP vs FTP vs FTPS covers what to move to and why.

How SSH works, step by step#

A connection goes through a fixed sequence before you see a prompt. Knowing the order is genuinely useful, because when a connection fails it fails at a specific stage, and the stage tells you where to look.

1. TCP connection#

The client opens a TCP connection to the server on port 22. This is an ordinary three-way handshake with nothing encrypted yet, just a reliable byte stream between two machines. If this step fails you get “connection refused” or a timeout, which means a firewall, a wrong address, or a daemon that is not running. Nothing cryptographic has happened yet. The SSH connection refused guide walks through each cause at this layer.

2. Version exchange#

Both sides send a plaintext identification string, such as SSH-2.0-OpenSSH_9.6 . This is how each side learns the protocol version and implementation of the other. If a server only speaks SSH-1, a modern client refuses to continue rather than downgrade.

3. Algorithm negotiation#

The client and server each send a list of the key exchange methods, ciphers, MAC algorithms, and compression methods they support, in preference order. They then pick the first mutually supported option from each list. This is why an old client can fail against a hardened server with a message about no matching key exchange method: the server has removed the weak algorithms the old client still depends on.

4. Key exchange#

This is the cryptographic core of the session. The two sides run a Diffie-Hellman exchange, usually Curve25519 or ECDH on a NIST curve, to arrive at a shared secret that neither one transmitted. The mathematics allow both parties to compute the same value independently, so an attacker who records the entire exchange still cannot derive it.

From that shared secret, both sides derive a set of symmetric keys: one for encrypting each direction, one for integrity checking each direction. From here on, everything is encrypted with a fast symmetric cipher such as AES-256-GCM or ChaCha20-Poly1305.

This hybrid design is deliberate. Asymmetric cryptography is what makes key agreement possible without a pre-shared secret, but it is far too slow to encrypt a stream of terminal output or a multi-gigabyte file. So SSH uses asymmetric math once, at the start, to agree on a symmetric key, then uses symmetric encryption for the actual work. TLS does the same thing for HTTPS.

Modern implementations also rekey periodically, typically after an hour or a gigabyte of traffic, so a single compromised session key exposes only a slice of the session.

5. Server authentication#

As part of the key exchange, the server signs the transcript with its host key, a long-lived key pair generated when the SSH daemon was first installed. Your client compares that key to what it has stored for this hostname in ~/.ssh/known_hosts (or PuTTY’s registry entries on Windows).

• First connection: the key is unknown. Your client prints the fingerprint and asks you to accept it. This is a trust-on-first-use model, and the correct move is to compare that fingerprint against one your provider published rather than typing yes reflexively.
• Later connections: the stored key must match. If it does, you never see a prompt.
• Mismatch: your client refuses to continue and prints a large warning.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

A host key changes legitimately when a server is rebuilt or reinstalled. It also changes when someone is intercepting your connection and presenting their own server. Deleting the offending line from known_hosts to make the warning go away is the single most common way people defeat their own security. Confirm the change is expected first, then clear the entry.

6. User authentication#

Now the server verifies you, over the already-encrypted channel. The two methods that matter in practice:

Password authentication. You type your account password. It travels inside the encrypted tunnel, so it is not exposed on the network, but it is still a guessable secret. Automated bots scan the internet for port 22 and try common username and password pairs continuously.

Public key authentication. You hold a private key; the server holds the matching public key in ~/.ssh/authorized_keys . The server sends a challenge, your client signs it with the private key, and the server verifies the signature against the public key. Your private key never leaves your machine and is never transmitted, so there is nothing on the wire for an attacker to capture and nothing on the server for an attacker to steal. This is the stronger option by a wide margin, and it is what passwordless SSH login sets up.

Key algorithms in current use are Ed25519 (the modern default: fast, small, secure), ECDSA, and RSA at 4096 bits (slower and larger, but universally supported). DSA is dead and should be removed wherever you find it.

7. Channels open#

Authentication succeeded, and now the encrypted connection can carry multiple independent channels at once. This multiplexing is what makes SSH more than a remote terminal:

• A session channel requesting a shell gives you an interactive prompt.
• A session channel requesting exec runs one command and returns its output, which is how running commands over SSH and every deployment script work.
• A session channel requesting a subsystem starts SFTP.
• Forwarded channels carry tunneled TCP connections in either direction.

One TCP connection, one authentication, many simultaneous streams. That design is why you can be editing a file, transferring another, and tunneling a database port over the same login.

The three keys people confuse#

SSH involves three different kinds of keys and they do completely different jobs. Mixing them up is the root of most SSH confusion.

You never handle a session key. You copy only the public half of your user key pair to a server. And you verify, but never install, a host key.

SSH vs SFTP vs SCP#

These three are constantly treated as competing choices. They are not. SFTP and SCP are both things that run inside SSH.

The practical split: use SSH when you want to do something on the server, SFTP when you want to browse and manage files (this is what FileZilla, WinSCP, and Cyberduck speak), and SCP when you want to copy one file in one line inside a script. For larger or repeated transfers, rsync over SSH beats all three because it transfers only what changed.

Worth noting: OpenSSH now implements scp on top of the SFTP protocol internally, because the original SCP protocol had a design flaw that let a malicious server write files the client never asked for. The command survives; the wire protocol underneath it changed.

What people actually use SSH for#

Remote administration#

The original purpose and still the main one. You get a shell on a machine you may never physically touch: read logs, restart services, edit configuration, inspect processes, run database queries. Everything in the Linux commands reference is something you would normally run through an SSH session, and searching a server’s files with find and grep over SSH is one of the fastest ways to diagnose a broken site.

File transfer#

SFTP, SCP, and rsync all ride on SSH, which means one open port and one set of credentials covers both administration and file movement. There is no second service to install, no second password to rotate, and no second thing to get wrong. The SFTP commands reference covers the full command set.

Git over SSH#

When you clone from git@github.com:user/repo.git , that is SSH. Git authenticates with your key pair, so there is no password or token to paste, and pushes are non-interactive, which is exactly what a deploy pipeline needs. It also explains a common surprise: if your key is not loaded, git push fails with a permission error that has nothing to do with Git.

Automation and deployment#

Ansible, Terraform provisioners, Capistrano, and most CI deploy steps are, underneath, SSH running non-interactive commands with key authentication. This is the reason key-based login is not just a security preference: passwords cannot be automated safely, and any workflow that needs a human to type a secret is a workflow that cannot run at 3am.

Port forwarding and tunneling#

SSH can carry arbitrary TCP connections through its encrypted channel. This is the feature most people discover last and then use constantly.

A local forward looks like this:

ssh -L 3307:127.0.0.1:3306 user@server

That makes port 3307 on your laptop behave as port 3306 on the server, over the encrypted SSH connection. Nothing new is exposed to the internet, and the database never needs a public listener. Tunneling is genuinely powerful and worth using carefully: a remote forward can punch a hole through a network boundary that someone deliberately put there.

Jump hosts#

ssh -J bastion.example.com target.internal connects through a bastion in one command. It is how you reach machines with no public address without copying private keys onto an intermediate server, which is the mistake that pattern exists to prevent.

SSH versions: SSH-1 and SSH-2#

There are two incompatible versions of the protocol, and only one of them is safe.

SSH-1’s integrity check could be defeated, allowing an attacker to inject commands into an established, encrypted session. OpenSSH dropped SSH-1 support entirely in version 7.6, so on any current system there is nothing to configure. If you encounter a device that only speaks SSH-1, treat it the way you would treat a device that only speaks Telnet: isolate it, and replace it.

Within SSH-2 there is still an ongoing cleanup of weak algorithms. ssh-rsa with SHA-1 signatures was disabled by default in OpenSSH 8.8, which is why some older servers suddenly stopped accepting connections after a client upgrade. The fix is to update the server, not to re-enable the old algorithm.

When SSH is the right tool, and when it is not#

Use SSH when:

• You need to run commands on a server you do not have physical access to
• You are transferring files to or from a server and want encryption without extra setup
• You need automated, unattended access for deployments or scheduled jobs
• You need to reach a service that is not, and should not be, exposed to the internet
• Your site is broken at the application layer and you need a channel that does not depend on the application working

Reach for something else when:

• Your users need a graphical desktop, where a remote desktop protocol fits better, though tunneling it through SSH is still the right way to secure it
• You are giving a non-technical person file access, where a browser-based file manager is faster and much harder to misuse
• You are moving very large data volumes between two servers, where rsync over SSH or an object-storage transfer is more efficient than an interactive session
• You need access from a device where you cannot protect a private key

Common misconceptions#

“SFTP is a separate protocol from SSH.” It is a subsystem of SSH. Same port, same credentials, same encryption. Changing your SSH port changes your SFTP port automatically, because there is only one port.

“Changing the SSH port makes the server secure.” It reduces log noise from automated scanners, and that is genuinely useful. It is not a security control – a port scan finds the new port in seconds. What actually secures SSH is key-only authentication, a firewall, fail2ban, and a patched OpenSSH. The SSH port guide covers the tradeoff in full.

“SSH encrypts my files.” It encrypts them in transit. Once a file lands on the server it sits on disk in whatever state you uploaded it. If you upload a config file full of API keys, those keys are now plaintext on a disk somewhere.

“My private key is on the server.” It should never be. Only the public half goes to the server, in authorized_keys . If you have copied a private key to a server so you can hop to another one, use a jump host or agent forwarding instead.

“A passphrase on my key makes it unusable for automation.” An SSH agent holds the decrypted key in memory for the session, so you unlock it once and every subsequent connection uses it silently.

“The host key warning is a bug.” It is the protocol working. Investigate before clearing it.

Diagnosing a failed connection#

Because the handshake happens in a fixed order, the error message tells you which stage failed and therefore where to look.

Two of these have the same non-obvious cause worth calling out. Permission denied (publickey) very often comes down to file permissions: SSH refuses to use a key directory that other users can read. The directory must be 700 and the private key 600 . And running the client with -v (or -vvv ) prints exactly which stage it reached before failing, which is faster than guessing.

SSH on Hostney#

Every Hostney account gets SSH access, and the account’s shell lives inside its own container. Your session sees your own filesystem and nothing else – not other customers’ files, not the host’s. That isolation is enforced by the kernel, not by file permissions, so there is no misconfiguration that can bridge it. The full picture is in how Hostney isolates websites with containers.

Authentication is key-only. Password login over SSH is not available. That is not a limitation to work around; it removes password guessing as an attack against your account entirely, because there is no password to guess. You generate or import a key pair on the SSH keys page in the control panel, and you can optionally bind a key to specific IP addresses so that even a stolen private key is useless from anywhere else.

There is a terminal in the browser. If you do not want to install a client at all, the control panel includes a full Linux shell that opens in a panel over a secure WebSocket connection, with the same access you would get from a desktop client. It is the fastest path to a shell when you are on a machine that is not yours. Details are in terminal access.

Connection details live in one place. The server information modal shows your hostname, username, port 22, and a ready-to-copy ssh command. The same hostname, username, and key work for SFTP and SCP, because they are all the same protocol.

ssh username@your-server.hostney.com
sftp username@your-server.hostney.com

Git, Composer, WP-CLI, and npm are all available in the shell, so a deploy over SSH behaves the same way it would on a server you built yourself.

Quick reference#

• SSH is an encrypted protocol for remote login and command execution, on TCP port 22.
• The handshake runs in order: TCP, version exchange, algorithm negotiation, key exchange, server authentication, user authentication, channel open. A failure names its stage.
• Asymmetric cryptography agrees on a key; symmetric cryptography does the actual encrypting.
• Three key types: host key (the server’s identity), your key pair (your identity), session keys (the encryption itself).
• SFTP and SCP are not alternatives to SSH; they run inside it on the same port with the same credentials.
• Use Ed25519 keys, protect the private half, and never copy it to a server.
• Never dismiss a host key mismatch without confirming why it changed.
• SSH-2 only. SSH-1 has been removed from OpenSSH since 2017.
• Port changes reduce noise; key-only authentication, firewalls, and fail2ban provide the security.

Summary#

SSH is the encrypted replacement for a generation of protocols that trusted the network. It gives you a verified, confidential, tamper-evident channel to a remote machine, and then multiplexes whatever you want across it: an interactive shell, a file transfer session, a Git push, a tunneled database port, or an automated deployment.

The parts that matter in daily use are small. Understand that the handshake is ordered, so errors point at a stage. Understand that there are three kinds of keys doing three different jobs. Use key authentication rather than passwords, because it is both stronger and the only thing that automates cleanly. And treat a host key warning as the security event it is.

Everything else built on top – SFTP, SCP, rsync, Git over SSH – inherits those same properties for free, which is precisely why the protocol has lasted.