SSH (not Shh): What SSH Is and Why It Powers Modern File Transfer

The three-letter acronym SSH stands for Secure Shell — a network protocol invented in 1995 to replace earlier insecure remote-administration protocols (Telnet, rlogin, rsh). Despite the spelling overlap with "shh" (the universal quiet-down sound), it's pronounced as three separate letters: S-S-H. SSH is the foundation under SFTP (the secure file transfer protocol), under remote-server administration on Unix-like systems, under Git's git@github.com:... URLs, and under nearly every secure connection between system administrators and infrastructure. This post explains what SSH actually does, the cryptography behind it, and why it's the right answer for modern secure file transfer.

SSH (the protocol) vs shh (the sound)

To be clear about the namespace:

• SSH — Secure Shell. A network protocol. Pronounced S-S-H. Specified in RFC 4251 and the subsequent SSH-2 family of RFCs (2006).
• shh — the onomatopoeia for "be quiet." Not a protocol. Different word entirely.

They are unrelated. SSH the protocol is loud — it'll happily flood your terminal with output, transfer gigabytes through a single connection, and run any command you tell it to. The "Sh" prefix in SSH refers to "Shell" (as in "command shell"), not to silence.

The acronym was coined by Tatu Ylönen at Helsinki University of Technology in 1995, after a password-sniffing attack on the university's network. SSH replaced the earlier rsh ("remote shell") and telnet — both of which sent passwords in cleartext — with an encrypted equivalent.

What SSH actually does

SSH is a transport protocol plus a set of services that ride on top of it. The transport handles:

• Encryption. Every byte over the connection is encrypted with a modern cipher (ChaCha20-Poly1305, AES-256-GCM, etc.) negotiated at handshake time.
• Authentication. Either passwords or — more commonly in production — public-key cryptography.
• Host-key verification. The server presents a host key; the client validates it against ~/.ssh/known_hosts to confirm the server's identity. Defeats man-in-the-middle attacks.
• Integrity. Each message is authenticated; tampering in transit is detectable.

On top of that transport, several services run:

• Interactive shell sessions (ssh user@server) — log into a remote machine and run commands.
• SFTP (sftp user@server) — the SSH File Transfer Protocol, a file-transfer subsystem that uses SSH for transport.
• SCP — secure copy, a simpler one-shot file-transfer command also riding on SSH.
• Port forwarding (ssh -L 8080:internal:80 user@server) — tunnel arbitrary TCP traffic through an SSH connection.
• X11 forwarding — run GUI apps remotely with the display piped back over SSH.
• Agent forwarding — chain SSH connections through intermediate hops while authenticating at the original endpoint.

For file transfer specifically, SFTP is the relevant SSH service — it's what every modern "secure FTP" workflow actually uses underneath.

Public-key cryptography: the part that makes SSH work

SSH's authentication model is based on asymmetric cryptography — key pairs where one half (the public key) can encrypt or verify, and the other half (the private key) can decrypt or sign. The two are mathematically linked but you can't derive one from the other in any practical sense.

The mechanics:

1. You generate a key pair on your machine: ssh-keygen -t ed25519. Result: ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public).
2. You install the public key on the server, in ~/.ssh/authorized_keys for the user account you'll be logging in as.
3. When you connect, the server sends a random challenge. Your client signs it with the private key. The server uses the public key to verify the signature.
4. Match means you have the private key. The server grants access without ever seeing the private key itself.

The asymmetry is what makes it secure: the private key never transits the network, and possession of the public key alone doesn't let an attacker impersonate you.

See our SSH keys setup guide for the step-by-step on generating and installing keys.

SSH key types: Ed25519 vs RSA vs ECDSA

When you generate an SSH key, you choose the key type — the cryptographic algorithm the key uses. Three matter in practice:

• Ed25519 — modern, fast, small (256-bit private key), strong against any realistic adversary. The current best-practice default. Use this unless your server is too old to support it.
• RSA — older, larger keys (4096 bits is the modern minimum for strength equivalent to Ed25519). Universally supported. Use for compatibility with very old servers.
• ECDSA — middle-ground elliptic-curve option. Less commonly used than Ed25519 these days; mostly compatibility-driven.

DSA is also a thing you'll see in legacy environments — it's been deprecated for years; don't generate new DSA keys.

For most teams in 2026: Ed25519 for new keys, RSA-4096 if your server can't speak Ed25519.

SSH for file transfer: why SFTP beats FTP

SFTP gets everything SSH provides — encryption, key auth, host-key verification, modern ciphers — wrapped around a file-transfer command set. Compared to plain FTP:

Feature	FTP	SFTP (via SSH)
Encryption	None (cleartext)	Mandatory
Authentication	Password only	Password OR key
Ports	21 + dynamic data ports	22 (single port)
Firewall complexity	High	Low
Host identity verification	None	Built in

Modern security review processes look at FTP and ask follow-up questions; they look at SFTP and move on. For new file-transfer deployments, SFTP is the right answer unless legacy partner compatibility forces FTP or FTPS.

See our FTP vs FTPS vs SFTP comparison for the full three-way breakdown.

Common SSH commands

The CLI patterns worth knowing:

# Connect to a remote shell
ssh alice@server.example.com

# Connect on a non-standard SSH port
ssh -p 2222 alice@server.example.com

# Connect with a specific private key
ssh -i ~/.ssh/work-key alice@server.example.com

# Transfer files via SFTP
sftp alice@server.example.com

# One-shot file copy with SCP
scp localfile.txt alice@server.example.com:/path/to/destination/

# Forward a local port to a remote service
ssh -L 8080:internal-host:80 alice@gateway.example.com

# Generate a new keypair
ssh-keygen -t ed25519 -C "alice@laptop"

# Install your public key on a server (Linux/Mac)
ssh-copy-id alice@server.example.com

# Show the fingerprint of a public key
ssh-keygen -l -f ~/.ssh/id_ed25519.pub

# Remove a host's cached key (after a server reinstall)
ssh-keygen -R server.example.com

~/.ssh/config is where these settings live persistently — once configured, ssh server is enough; no need to repeat the user, port, or key.

SSH host-key verification: trust on first use

When you connect to a server for the first time, SSH prompts:

The authenticity of host 'server.example.com (203.0.113.5)' can't be established.
ED25519 key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no)?

That's SSH asking you to verify the server's identity. If your server administrator gave you the fingerprint out of band (a separate channel from the credentials), compare and accept on match. If you don't have an out-of-band fingerprint, trust on first use — accept and cache the key. Subsequent connections detect any change (the client refuses to connect if the host key changes mid-relationship), alerting you to a man-in-the-middle or a legitimate server reinstall.

After acceptance, the key lives in ~/.ssh/known_hosts. If a server is legitimately reinstalled and its host key changes, remove the old entry: ssh-keygen -R server.example.com.

The modern way

Files.com is the File Orchestration Platform we'd recommend for SSH-based file transfer workflows in 2026. The platform exposes SFTP (SSH-based) on port 22 with native SSH-key authentication, alongside FTPS / FTP / WebDAV / AS2 on the same backend storage:

• Generate and manage SSH keys through the admin UI. Per-user keys, rotation, revocation.
• Audit logging on every connection — per-user, per-file, immutable.
• MFA, SSO with SAML/SCIM, IP allowlisting layered alongside SSH key auth.
• SOC 2 Type II, HIPAA-BAA, GDPR-ready posture out of the box.

Start a free Files.com trial — no credit card.

For teams that need to run SSH-based file transfer infrastructure inside their own datacenter, the free ExaVault on-premise appliance handles SFTP from a self-hosted VM image.

FAQ

Is it SSH or shh?

SSH. Three letters, pronounced individually (S-S-H). Stands for Secure Shell. The lowercase "shh" (for "be quiet") is unrelated — different word entirely, even if the spelling looks similar.

What does SSH stand for?

Secure Shell. A network protocol for encrypted remote-machine access and file transfer, invented in 1995 to replace the insecure Telnet and rsh protocols. The current SSH-2 family of standards is specified in RFC 4251 and related RFCs.

How is SSH different from FTP?

FTP is the original 1971 file-transfer protocol — cleartext, no encryption. SSH is a 1995 encrypted-remote-access protocol that includes a file-transfer subsystem called SFTP. So "SSH vs FTP" is really "SFTP vs FTP" for the file-transfer question — and SFTP wins on every dimension (encryption, authentication, firewall behavior). See our SSH vs FTP details.

What is SSH used for?

Three main things: remote shell access (logging into a server to run commands), file transfer (via the SFTP subsystem), and port forwarding (tunneling other protocols through an encrypted SSH connection). It's the de facto standard for sysadmin work on Unix-like systems.

What's an SSH key?

A pair of cryptographically linked files — a private key that stays on your machine and a public key that you install on servers you want to authenticate against. The private key proves your identity to the server without ever transiting the network. See our SSH keys setup guide.

Is SSH secure?

Yes — SSH-2 with modern ciphers (Ed25519 keys, ChaCha20-Poly1305 or AES-GCM encryption, Curve25519 key exchange) is considered strong against any realistic adversary in 2026. The main risks are operational: a stolen private key, a phished password (when password auth is enabled), or a misconfigured server that allows weaker cipher suites.

What's the default SSH port?

Port 22. Some shops run SSH on a non-standard port (commonly 2222) to reduce noise from automated scanning, but port 22 is the universal default. Clients connect to port 22 unless you specify -p (or -P for sftp / scp) with a different port.

Can I use SSH without a password?

Yes — that's the SSH-key authentication model. Generate a keypair, install the public key on the server, and authenticate via the private key on every subsequent connection. No password transits the wire. The standard pattern for production automation and a security best practice for interactive use.