SSH Basics: How to Log Into a Remote Server Safely

At some point, the website or app you’re building stops living on your laptop and moves onto a real server — a machine that’s always online, sitting in a data center you’ll probably never see. That raises an obvious question: if you can’t sit in front of it, how do you actually control it? How do you install software, edit files, restart things, and check what went wrong?

The answer, almost universally, is SSH. It’s the tool that lets you open a terminal on a computer that’s thousands of kilometers away and type commands as if you were right there. Once you understand SSH, a server stops feeling like a distant black box and starts feeling like just another machine you can reach. Let’s build that understanding from the ground up.

What SSH actually is

SSH stands for Secure Shell. Break that into two halves and the whole idea falls into place.

A shell is the program that reads the commands you type and runs them — it’s the thing behind the command-line prompt. When you open a terminal on your own machine, you’re talking to a shell. SSH gives you a shell on a different machine, over the network. You type, the remote computer runs the command, and the output comes back to your screen.

The secure part is just as important. Everything you send over an SSH connection — your commands, your password, the files you transfer, the results that come back — is encrypted. Even if someone is watching the network between you and the server, all they see is scrambled noise. That’s a big deal, because SSH replaced older tools like Telnet that sent everything, passwords included, in plain readable text.

So put simply: SSH is a secure way to log into and control a computer remotely. If you’ve heard people say “ssh into the server,” that’s exactly what they mean — opening one of these encrypted remote sessions.

How an SSH connection works

You don’t need to memorize the cryptography, but a mental model of what happens when you connect makes everything afterward less mysterious. Here’s the sequence, simplified:

1. You start the connection. Your client reaches out to the server’s address, on a specific port (SSH uses port 22 by default).
2. The server proves who it is. The server hands over its host key — a unique fingerprint that identifies this exact server. Your client checks it. The first time you ever connect, you’ll be asked to confirm you trust it.
3. An encrypted tunnel is set up. The two machines agree on a shared secret using some clever math, and from this point on everything in both directions is scrambled.
4. You prove who you are. Now the server needs to confirm you’re allowed in — either with a password or, much better, with a key (more on that below).
5. You get a shell. Authentication passes, and a prompt appears. You’re now typing commands that run on the remote machine.

   YOUR LAPTOP                        REMOTE SERVER
   (ssh client)                       (sshd, port 22)
        │                                   │
        │  1. connect ─────────────────────►│
        │                                   │
        │◄──── 2. "here's my host key" ─────│
        │                                   │
        │═══ 3. encrypted tunnel agreed ════│
        │                                   │
        │  4. "here's who I am" ───────────►│
        │◄──── 5. welcome — here's a shell ─│
        │                                   │
   you type commands  ───────────────────►  they run over there

Every keystroke after that travels through the encrypted tunnel. The experience feels instant and local, but you’re really driving a machine that could be on the other side of the planet.

Connecting: the ssh command

The command itself is refreshingly short. The basic form is:

ssh username@host

• username is the account you want to log in as on the server (for example jane or deploy).
• host is where the server lives — either an IP address like 203.0.113.10 or a domain name like srv.acypartner-indonesia.example.

So a real connection might look like this:

ssh jane@203.0.113.10

If the SSH server listens on a non-default port (some are moved off 22 to cut down on automated noise), you tell ssh with -p:

ssh -p 2222 jane@203.0.113.10

The very first time you connect to a new server, you’ll see something like this:

The authenticity of host '203.0.113.10' can't be established.
ED25519 key fingerprint is SHA256:Xy9k...3Qz.
Are you sure you want to continue connecting (yes/no)?

That’s step 2 from earlier — your client showing you the server’s host key and asking if you trust it. Type yes, and the fingerprint gets saved to a file called known_hosts on your machine. From then on, your client quietly checks that the server still matches. If that fingerprint ever changes unexpectedly, SSH will loudly refuse to connect — its way of warning you that something might be impersonating your server.

Passwords vs. SSH keys

When the server asks you to prove who you are, there are two common ways to do it. This is the part beginners most often get wrong, so it’s worth slowing down.

Password authentication

The simplest method: you type the account’s password, the server checks it, and you’re in. It works, and it’s how a lot of people start. But it has real weaknesses. Passwords can be guessed, reused across sites, or worn down by automated bots that hammer servers trying thousands of common ones per minute. A password also has to travel (encrypted, thankfully) on every login.

Key-based authentication

The better way is a key pair — two matching files generated together:

• A private key that stays on your machine and that you never share with anyone.
• A public key that you copy onto the server.

When you connect, the two halves prove they belong together using cryptography, without your private key ever leaving your computer. The result: logins that are both more convenient (no password to type each time) and far more secure (a good key is effectively impossible to guess). For any real server, keys are the standard you should aim for.

You generate a key pair once, with:

ssh-keygen -t ed25519 -C "jane@acy-partner-indonesia"

That creates two files in your ~/.ssh/ folder: id_ed25519 (the private key — guard it) and id_ed25519.pub (the public key — safe to share). The -C part is just a comment so you can tell your keys apart later.

Then you copy the public key to the server:

ssh-copy-id jane@203.0.113.10

After that, ssh jane@203.0.113.10 logs you in using the key — no password prompt. Behind the scenes, your public key got added to a file called ~/.ssh/authorized_keys in your account on the server, which is the list of public keys allowed to log in as you.

   YOUR MACHINE                      THE SERVER
 ┌──────────────────┐            ┌──────────────────────┐
 │ id_ed25519       │  private   │ authorized_keys      │
 │  (PRIVATE, stays)│            │  holds your PUBLIC   │
 │ id_ed25519.pub ──┼──copy────► │  key, lets you in    │
 └──────────────────┘            └──────────────────────┘

Doing things once you’re in

After you connect, you’re simply at a Linux prompt — the same kind of shell you’d use locally. If you’ve spent any time with the command line, everything you know applies here, just on the remote machine. You can move around with cd and ls, read and edit files, check running services, and install software.

A few things worth knowing about working over SSH:

• The prompt usually tells you where you are. Something like jane@srv01:~$ reminds you which user you are (jane) and which machine (srv01). That small detail saves you from accidentally running a command on the wrong server.
• To leave, type exit (or press Ctrl+D). That closes the session and drops you back to your own machine’s prompt.
• You can run a single command without a full session. Tack the command onto the end and SSH runs it, returns the output, and disconnects:

ssh jane@203.0.113.10 "uptime"

That’s handy for quick checks or scripts that need to ask a server one thing.

Which account you log in as matters, too. Logging in as a regular user and using elevated privileges only when needed is far safer than logging in as the all-powerful root user for everything. If that distinction is fuzzy, the article on users and groups covers who’s allowed to do what, and file permissions explains why not every account can touch every file.

A small comfort: the SSH config file

Typing ssh -p 2222 jane@203.0.113.10 every time gets old fast. SSH lets you save shortcuts in a file at ~/.ssh/config. Add an entry like this:

Host acy-server
    HostName 203.0.113.10
    User jane
    Port 2222

Now this is all you type:

ssh acy-server

The client looks up acy-server in the config, fills in the address, user, and port for you, and connects. For anyone juggling more than one or two servers, this small file turns a chore into a habit you barely notice.

Why SSH matters

SSH is the front door to nearly every server you’ll ever touch. Deploying a website, fixing a bug in production, reading logs at 2 a.m. to figure out why something broke, transferring files, automating a routine task — almost all of it starts with an SSH connection. It’s not an advanced topic you can put off; it’s day-one, foundational plumbing for anyone working with servers.

It’s also the secure foundation that a lot of other tools quietly build on. File-transfer methods like SCP and SFTP run over SSH, using the same encrypted tunnel and the same keys. Deployment scripts and configuration tools connect through SSH under the hood. Learn it well once, and you’ve unlocked a whole layer of how servers are managed.

Wrapping up

Here’s everything in one place:

• SSH (Secure Shell) is a secure, encrypted way to log into and control a remote computer’s command line over a network.
• It’s split into a client (on your machine, the ssh command) and a server (sshd, listening on port 22 by default).
• Connecting checks the server’s host key (so you know it’s really your server), sets up an encrypted tunnel, then verifies you.
• You authenticate with a password or, much better, an SSH key pair — a private key you guard and a public key you place on the server.
• The basic command is ssh username@host; you leave with exit, and an ~/.ssh/config file saves you from retyping connection details.

Once you’re comfortable opening a session, the natural next step is moving files between your machine and the server — copying a build up, pulling a backup down. That’s the job of file transfer over SSH, and the keys you just set up carry straight over to it.