Connecting with SSH

ssh, keys, scp — reach a remote server.

Every server you will ever run lives somewhere you are not. It sits in a data center in another city, or it is a virtual machine (a whole computer that exists only as software running on shared hardware) in the cloud that you will never physically touch. You still have to type commands on it as if you were standing at its keyboard. SSH (Secure Shell, a way to open an encrypted command-line session on a distant computer) is how you do that. It is the front door to almost every Linux machine in operations, and you will use it every single day.

The simplest form is ssh user@host. You name who you want to be on the far machine and which machine to reach, and SSH opens a shell there. A shell is the program that reads your typed commands and runs them. Once you are connected, your terminal is that remote computer for as long as the session lasts.

For those few seconds you are a user named deploy on a machine called web-01. Run hostname to prove it, then type exit (or press Ctrl-D) to hang up and land back on your own laptop.

Notice the one weak spot in that first login: a password prompt. Passwords can be guessed, phished, and reused. The next section replaces them with something far stronger.

Keys Beat Passwords

A password is a secret you both know, and you send it (encrypted) down the line every time you log in. A key pair works differently, more like a wax seal that only your signet ring can stamp. You hold a private key (a secret file that never leaves your laptop) and you hand out a public key (a matching file that is safe to show anyone). The server keeps your public key on file. When you connect, the server sends a puzzle that can only be answered by whoever holds the private key, and your machine answers it without ever sending the secret across the wire. You generate both files at once with ssh-keygen.

The -t ed25519 flag picks the key type. ed25519 is a modern algorithm that makes short, fast, strong keys; prefer it over RSA (an older key type that has to be much longer to reach the same strength). You now have two files. id_ed25519 is the private key, the secret. id_ed25519.pub is the public key, safe to share. Install the public one on the server with ssh-copy-id, which asks for your password one last time.

Under the hood, ssh-copy-id appended your public key to a file named ~/.ssh/authorized_keys on the server. That file is the guest list: every public key in it is allowed to log in as that user. From now on, SSH answers the puzzle for you and no password is asked. If you set a passphrase on the key, your machine prompts for it once and a helper called ssh-agent (a small program that holds your decrypted key in memory) remembers it for the rest of your session.

SSH takes those permissions seriously enough to refuse a private key that the rest of the system can read. Loosen them by mistake and the login fails in a way that confuses a lot of newcomers.

Trust On First Connection

Go back to that first prompt asking you to confirm a fingerprint. Every server has its own key pair too, and when you first reach one, SSH shows you the server's host key fingerprint (a short, unique digest of the server's own public key) and asks whether you trust it. Say yes and SSH records that key in ~/.ssh/known_hosts. It is like memorizing a friend's voice on your first phone call so you notice at once if an impostor picks up later. Every future connection is checked against the saved key without asking again.

This check is what stands between you and a machine-in-the-middle attack, sometimes called man-in-the-middle, where someone sits on the network between you and the real server, pretends to be it, and quietly records everything you type, a typed password included. If the host key ever fails to match what you saved, SSH stops the connection cold and shows a loud warning. Read that warning. Do not paste a reflexive yes to make it go away.

Moving Files With scp

SSH does not only carry keystrokes, it can carry files down the same protected connection. scp (secure copy, a file-transfer tool built on SSH) works like cp (the ordinary local copy command), except one side is a remote machine. You write the remote location as host:path, with the path after the colon.

To pull a file back the other way, put the remote side first and a local destination last.

For large or repeated transfers, most engineers reach for rsync (a copy tool that sends only the parts that changed), but scp is on every machine and fine for a one-off file.

An Address Book For Servers

Typing [email protected] over and over gets old fast, and real infrastructure has dozens of hosts. The file ~/.ssh/config is your address book. You give each server a short nickname and record its real address, the login user, and which key to use, the way saved contacts on a phone let you tap a name instead of dialing a number.

Host web01
    HostName web-01.acme.internal
    User deploy
    IdentityFile ~/.ssh/id_ed25519
 
Host bastion
    HostName jump.acme.internal
    User deploy
 
# reach db01 by hopping through the bastion first
Host db01
    HostName db-01.internal
    User deploy
    ProxyJump bastion

Now ssh web01 expands into the full command with the right user and key. The last entry shows a jump host (a hardened gateway that is the only machine allowed to reach the private servers behind it). ProxyJump tells SSH to tunnel through bastion to get to db01. Real networks hide their database and application servers from the public internet and force every login through one audited entry point, which is both cleaner and safer.

scp reads the same nicknames, so scp report.tar.gz web01:/opt/app/ does the full transfer with no long hostname to remember.

One habit closes the loop on all of this. Every public key in a server's authorized_keys file is a live, working login, and keys tend to outlive the people who added them. Read that file now and then on any machine you run.

That second line belongs to a contractor who left months ago, and it still opens the door. Deleting the stale lines that no longer belong is one of the cheapest security wins you have on any server you touch. Open the file, remove the line, save, and that key is no longer a way in.

Try this

Work through “An Address Book For Servers” yourself on a sandbox you can throw away, following the commands above in order. Then break one step deliberately and re-run, so you have seen the failure before it finds you.

Takeaway

The trap worth remembering here: your private key is the login. Check that on your own systems before you need to, because it is cheaper to find on a quiet afternoon than during an incident.

Related