What is SSH — how to log into someone else's computer without a password in the open

You hit the deploy step, and the guide says: "log into the server over SSH." Sounds like something from a hacker movie. In reality it's just a way to control a computer sitting thousands of kilometers away as if it were your own terminal.

And here's the surprising part: the safest way to log in over SSH uses no password at all. Instead — a pair of keys. In a couple of minutes you'll understand why that's more secure than any password someone could peek at.

What SSH is, in plain words

SSH (Secure Shell) is a protected channel between two computers. On one side, your laptop (the "client"); on the other, a remote machine, usually a server (the "host"). You type commands on your end, and they run over there.

The key word is Secure. Everything that travels over SSH is encrypted: your login, password, commands, responses. Even if someone intercepts the traffic on the way, they see meaningless noise, not your data. Before SSH there was Telnet, where everything went as plain text — nobody does that today.

An analogy: a regular website is a conversation through a window in a wall — any passerby can hear it. SSH is a conversation down an armored pipe laid from your door to theirs. From outside you can't crack it open or eavesdrop.

Over SSH you can do everything you'd do in your own terminal: browse files, install programs, restart an app, read logs. For that session, the remote computer simply becomes "yours."

Keys instead of a password — why it's safer

Here's the trick. When you set up SSH, a pair of keys is created: a private one and a public one.

• The private key stays on your laptop and never leaves it. It's your half of the lock.
• The public key you place on the server. It's not scary to show — on its own it's useless.

When you log in, the server poses a puzzle that can only be solved with the private key. Your computer solves it without sending the key itself. The server sees "solved correctly — so this is the owner" and lets you in. No password travels the network, because there isn't one.

Why is this safer than a password? A password can be peeked at, brute-forced, or phished. A private key is a very long random string that can't be guessed, and it physically never leaves your machine. Nothing to guess, nothing to intercept.

Such a pair is created with a single command — ssh-keygen. The same logic powers logging into GitHub over SSH: you place the public key in settings once, and git push stops asking for a password. The private key is a secret; treat it like your API keys — never hand it over, never commit it to a repo.

What it looks like in practice

The login command is simple:

ssh name@address — for example, ssh [email protected].

After that the terminal prompt changes — now you're "inside" the server, and every command runs there. To go back to your own machine — the exit command.

Where you'll meet SSH:

• when you rent your own server (a VPS-style host) and log in to configure it;
• when git push to GitHub goes over SSH — that address starting with [email protected];
• when a deploy script connects to the server itself to update the app;
• when you need to check the logs of a "live" app right on the production machine.

Many modern hosts (Vercel, Railway, Render) hide SSH behind a nice button — you deploy without knowing it's under the hood. But the moment you get your own server, SSH becomes the main door into it. Understand it once, and "log in over SSH" stops being scary.

FAQ

Are SSH and HTTPS the same thing?

No, but the idea is similar — both encrypt the channel. HTTPS protects a browser's link to a site (you set up nothing, it just works). SSH is a protected login to control a remote computer from the command line. HTTPS is "safely view a site," SSH is "safely steer a machine."

What happens if I lose the private key?

You can no longer log in with it — half of the lock is gone. It's not a disaster: you generate a new pair with ssh-keygen, place the new public key on the server (or in GitHub settings), and delete the old one. It's worse if the private key falls into the wrong hands — then you revoke it urgently, like a leaked password.

Do I have to use keys and not a password?

You can log in over SSH with a password too, but it's noticeably less secure: bots brute-force passwords, hammering servers around the clock. Keys remove that risk entirely — nothing to guess. That's why production servers often disable password login altogether, leaving only keys.