Remote access — study guide

Working on a machine that isn't in front of you

The computer you actually need to operate is often not the one in front of you. It is a server in a datacenter, a virtual machine rented from a cloud provider, a box humming in another building — somewhere you will never physically sit. SSH (the secure shell) closes that distance: it gives you a real shell on the remote machine, over the network, as if you had pulled a chair up to it.

What you get is not a watered-down remote view but the genuine command line of the other machine. You type, the command runs there, and its output comes back to you. Because that traffic crosses a network you do not control, SSH is built to be secure by default — the word in its name is not decoration.

The model on this page steps through what happens when you connect: the client reaching the server, the two machines settling who each other is, bringing up an encrypted line, and proving your identity, until a shell finally opens on the far end. Every packet and endpoint in it can be clicked to explain itself.

Client and server

SSH has two halves, and they are not interchangeable. On the remote machine a server program called sshd (the SSH daemon) runs quietly in the background and listens for incoming connections. On your machine the ssh client is the program you actually run; it reaches out and connects to that waiting daemon. Nothing happens until the client makes the first move.

Once connected, the trick worth holding onto is where the work happens. The shell you drive runs on the remote machine, not yours — every command executes there, against that machine's files and its processes. Your terminal is only the near end of a pipe: it ships your keystrokes across to sshd and prints back whatever the remote shell produces. You get the full command line of a computer that may be thousands of miles away, and the only thing traveling the wire is input going one direction and output coming the other.

An encrypted channel over an open network

To reach the server, the client needs two things: which machine to talk to and which door to knock on. The machine is a host — a name or an address — and the door is a port. SSH's default port is 22, so unless someone has chosen otherwise, that is where sshd is listening and where the client goes.

Reaching the server is only the start. Before anything sensitive passes — before you type a password, before a single keystroke of real work — the two sides agree on a shared secret and bring up an encrypted channel. From that point on, everything crossing the wire is ciphertext: your keystrokes, the command output coming back, and the credentials you log in with are all unreadable to anyone watching the network in between.

That is the whole difference from a plaintext connection, where the same traffic would travel in the clear for any router, wireless neighbor, or curious network operator along the way to read. The secure shell assumes the network between you and the server is hostile, and arranges things so that it does not matter.

Is this really the machine I meant?

Encrypting the connection only helps if you are encrypting it to the right machine. An impostor could sit in the middle, answer in the server's place, and cheerfully set up a perfectly secure channel — to itself. So before you trust it, the server has to prove which machine it is. It does this with a host key: one half of a public/private key pair that belongs to that specific server. The server keeps the private half secret and presents the matching public half to every client that connects, and only the machine actually holding the private key can back up that identity.

The hard part is the first connection: you have no prior record of this server, so you cannot yet tell its real key from a forged one. SSH handles this with trust on first use — the first time you connect, it shows you the key and asks you to accept it, and once you do, it writes that key down in a file called known_hosts. Every later connection is checked against the saved key. It works like recognizing a friend's voice on a phone line you have used before: the first call you take on faith, but ever after a stranger answering that same line is instantly, obviously wrong.

That saved key is what turns a silent risk into a loud one. If the key a server presents ever stops matching the one in known_hosts, SSH does not quietly carry on — it refuses, warning that the remote host identification has changed and that someone could be eavesdropping. Usually the server was simply rebuilt; occasionally it is exactly the attack the check exists to catch. Either way you are told, instead of being fooled.

Proving who you are with a key pair

The server has proved which machine it is; now you have to prove who you are. The simplest way is a password, which SSH will accept over its encrypted channel. The far better way is a key pair of your own — the same public/private idea, turned around to point at you instead of at the server.

Here is the shape of it. You hold a private key, a file that never leaves your machine and that you never send to anyone. The server holds the matching public key, which is safe to hand out and safe to store — it lives in a file called authorized_keys on the server. When you log in, the server issues a challenge that can be answered correctly only by whoever holds the private key, and you answer it without ever transmitting the private key itself. You prove possession, not the secret. It works like a signet ring kept locked away and the wax seal it stamps: you prove a letter is yours by pressing a fresh seal anyone can recognize, never by handing over the ring itself.

Because the private key is the whole of your identity, how you store it matters as much as the cryptography. This is exactly the kind of file the permissions rules exist to protect: a private key that other users on your machine can read is a private key anyone on that machine can steal. SSH enforces this rather than trusting you to remember it — it will simply refuse to use a private key whose permissions let others read it, and tell you the file is unprotected. A key pair is only ever as strong as the secrecy of its private half.

More than an interactive shell

An interactive prompt is the most visible thing SSH gives you, but it is not the only one. The same secure connection can carry a single command instead of a whole session: you ask the remote machine to run one thing, it runs it and hands back the output, and the connection closes — no lingering prompt, just a question and an answer.

The same transport moves files, too. scp and sftp copy files to and from the remote machine over an ordinary SSH connection, using the same authentication and the same encryption as a login session — a file copy is just a different use of the secure pipe, not a separate, less-protected channel. Other tools lean on SSH the same way, riding its authenticated, encrypted transport rather than inventing their own.

It is easiest, in the end, to think of SSH not as a remote-login program that happens to be secure, but as a general-purpose secure connection between two machines. Logging in is only its most familiar use.

How every server gets operated

Almost every server you will ever run is a machine you never physically touch. The game server you stand up for friends, the box that hosts a service, the cloud instance you rent for an afternoon — you reach all of them the same way, by opening an SSH session to a computer you have never seen and may never see. Remote access is not a niche skill reserved for administrators; it is simply how servers are operated.

That makes these habits the professional baseline, not extras. The expected way to log in is a key pair, not a password typed over and over: it is harder to guess, harder to steal in transit, and it is what automated tools and deployment systems assume. And the private key that anchors your identity has to be locked down by permissions so that only you can read it — the same least-privilege thinking applied to the one file that is, in effect, the keys to the machine.

Learn to reach a remote box safely and keep its key where nothing else can read it, and you have the ground floor of running anything in production.