Every time a developer deploys a website, restarts a server, or pushes code to a Git host, there is a good chance SSH is doing the quiet work underneath. SSH, short for Secure Shell, is the protocol that lets you log into a remote computer and run commands on it, with the whole conversation encrypted so nobody listening in between can read it.
Key Takeaways
SSH is a cryptographic protocol for secure remote login and other network services over an insecure network, as defined by RFC 4251.
It runs on TCP port 22 by default, and it replaced Telnet and rlogin, which sent passwords in plain text.
SSH has three layers: transport (encryption and server authentication), user authentication (proving who you are), and connection (multiplexing channels inside one encrypted tunnel).
Public key authentication is the recommended way to log in: your private key never leaves your machine, and the server only holds your public key.
Beyond the terminal, SSH also powers secure file transfer (SFTP and SCP), port forwarding, and Git over SSH.
What SSH Actually Is
RFC 4251, published by the IETF in January 2006, describes SSH as a protocol for secure remote login and other secure network services over an insecure network. The key phrase is "over an insecure network": SSH assumes someone may be watching the traffic, and it is designed so that watching buys them nothing.
In practice, you type something like `ssh user@example.com`, the client and server agree on encryption, verify each other's identity, and then you get a shell prompt on the remote machine. Everything you type and everything the server prints back travels inside an encrypted tunnel. The same tunnel can also carry file transfers, forwarded ports, and other services, all multiplexed as separate channels.
SSH is not a single program. It is a protocol, and the most common implementation is OpenSSH, which ships with Linux and macOS and is available on Windows. When people say "SSH into the server," they usually mean "use an SSH client to connect to the server's SSH daemon."
Why Telnet Had to Go
Before SSH, remote login meant Telnet or rlogin, and both sent everything, including your password, in plain text. Anyone able to observe the network traffic could simply read the password off the wire. That was the exact problem Finnish researcher Tatu Ylonen set out to fix: in 1995, prompted by a password sniffing attack on his university network, he designed the first version of SSH as a secure replacement for rlogin, Telnet, FTP, and rsh, according to Wikipedia.
Ylonen released his implementation as freeware in July 1995, and it spread fast. He chose port 22 for SSH because it sat neatly between FTP on port 21 and Telnet on port 23, and port 22 remains the default SSH port today. The original SSH-1 had weaknesses, so the protocol was redesigned as SSH-2, standardized by the IETF in the RFC 4250 through 4256 series, with RFC 4251 describing the overall architecture. Modern SSH means SSH-2. SSH-1 is obsolete and should never be used.
The Three Layers of SSH
SSH is built in three layers, each with a distinct job, as RFC 4251 explains:
Transport layer: this runs first. It authenticates the server, negotiates encryption algorithms, performs a key exchange, and establishes a channel with confidentiality and integrity. After this layer is up, everything else is encrypted.
User authentication layer: this runs over the transport layer and authenticates the client to the server, by password, public key, or another method.
Connection layer: this multiplexes the encrypted tunnel into several logical channels, so one SSH connection can carry an interactive shell, a file transfer, and forwarded ports at the same time.
This layered design is why SSH is more than a remote shell. The connection layer turns one authenticated, encrypted tunnel into a general purpose secure channel, and new services can run over it without reinventing encryption.
How an SSH Connection Works, Step by Step
A typical login follows this sequence:
Your client connects to the server on TCP port 22 (or a custom port, if configured).
Client and server negotiate which encryption, key exchange, and integrity algorithms to use.
The server presents its host key. Your client checks it against its known hosts database, the `known_hosts` file, to confirm it is talking to the same server as before. If the key changed unexpectedly, the client warns you, because that can signal a man in the middle attack.
A key exchange produces a shared session key, so all further traffic is encrypted and integrity protected.
You authenticate, usually with a password or a public key.
The connection layer opens a channel, and you get a shell, run a single command, or start a file transfer.
The host key check in step 3 matters more than people think. Encryption alone only guarantees that nobody can read the traffic; it does not guarantee you are talking to the right server. The host key is what ties the encrypted tunnel to a specific server identity.
Public Key Authentication: Login Without Sending a Secret
Password login works, but it has two weaknesses: passwords can be guessed, and they are sent to the server (inside the encrypted tunnel, but still to the server). Public key authentication avoids both.
You generate a key pair on your own machine, typically with `ssh-keygen`. The private key stays on your machine, ideally protected by a passphrase. The public key goes into the server's authorized keys file for your account. When you log in, the server checks that your public key is authorized, then the client proves it holds the matching private key by signing a challenge, as OpenSSH public key documentation describes. The private key itself is never sent anywhere, and the passphrase never leaves your machine either.
This is why server administrators recommend key based login and disabling password authentication on internet facing servers: there is no password for an attacker to brute force. Modern key types such as Ed25519 are a good default, and hardware backed keys exist for higher security setups.
SSH Is More Than a Terminal
The terminal is the famous use, but SSH does much more:
Secure file transfer: SFTP runs file transfer over the SSH connection, and SCP copies files the same way. Both replace plain FTP, which sends credentials and data unencrypted.
Port forwarding: SSH can forward a local port to a remote service, so you can reach a database or web dashboard that is only accessible from the server, through the encrypted tunnel.
Tunneling and jump hosts: a bastion or jump host setup lets you reach private servers through one hardened SSH entry point, instead of exposing every server to the internet.
Git over SSH: when you clone or push with a `git@` URL, Git is running over SSH, authenticating you with your SSH key. That is the same key mechanism described above, applied to version control, which our Git guide covers from the repository side.
SSH vs Telnet at a Glance
Aspect | Telnet | SSH |
|---|---|---|
Encryption | None, everything in plain text | Full encryption of the session |
Password safety | Password visible to anyone watching traffic | Password encrypted, or replaced by key authentication |
Server identity | No verification | Host key checked against known hosts |
File transfer | Separate, insecure FTP | SFTP and SCP over the same tunnel |
Port forwarding | No | Yes, built into the connection layer |
Default port | 23 | 22 |
Status today | Obsolete for remote access | The standard for remote administration |
Hardening Checklist for a Real Server
If you run a server, these are the basics worth doing, in order:
Use public key authentication and disable password authentication.
Protect your private key with a strong passphrase, and never copy it to a server.
Keep the server's SSH software updated, since old versions carry known flaws.
Consider changing the default port or restricting access by firewall, not as a substitute for keys, but to cut down automated login attempts.
Review authorized keys regularly and remove keys for people who no longer need access.
Never ignore a host key changed warning without verifying why it changed first.
SSH also pairs naturally with the login model in our OAuth guide: OAuth answers what an app may do on your behalf, while SSH answers how you securely reach and administer the machine itself. Different layers, same principle: never hand out a raw secret when a scoped, revocable credential will do.
Baca versi Bahasa Indonesia dari artikel ini di SSH Dijelaskan: Cara Kerja Akses Jarak Jauh yang Aman.
FAQ
Is SSH the same as a VPN?
No. A VPN encrypts all of a device's network traffic and places the device on another network. SSH encrypts one connection (or a few forwarded channels) to one server. They solve different problems, though SSH tunneling can resemble a VPN for specific services.
Do I need SSH if I only use a web hosting panel?
Probably not directly, but your hosting provider's servers use SSH behind the scenes, and the moment you manage a VPS, a cloud server, or a Git host, SSH becomes the standard way in.
What happens if a server's host key changes?
Your client warns you and refuses to connect until you confirm. A legitimate cause is a server reinstall or key rotation. An illegitimate cause is a man in the middle attack. Always verify with the server administrator before accepting a changed key.
Can I use SSH on Windows?
Yes. Modern Windows ships an OpenSSH client, and tools like PuTTY remain popular alternatives. The protocol is the same regardless of client.
Why is port 22 so often attacked?
Because it is the well known default, automated scanners try it constantly. That is why key based login matters: an attacker can knock on port 22 all day, but without your private key they cannot get in.