Reaching Other Machines: ssh & scp

Beginner40 min8 steps

What you'll learn

Explain what SSH is and why every byte of the session is encrypted
Log into another machine with ssh user@host (and -p for a non-default port)
Read the first-connection host-key fingerprint prompt and know what saying 'yes' commits you to
Contrast password auth with public-key auth, and generate a keypair with ssh-keygen
Install a public key with ssh-copy-id / authorized_keys and log in without a password
Write a minimal ~/.ssh/config alias so a whole connection recipe becomes one word
Copy files both directions with scp (plus -r and -P), and know when rsync or sftp is the better tool

Nearly all real Linux work is remote
Understand what SSH is and why it exists.
The servers you'll administer don't have a monitor plugged in. They live in a datacenter, a cloud region, a closet — and you reach them all the same way: SSH, the Secure SHell.
ssh opens a shell on another machine, over the network, with every byte encrypted — your password, your commands, the output, all of it. That's the whole reason it displaced its 1990s predecessors (telnet, rlogin), which sent passwords across the wire in plain text for anyone on the network to read.
Once you're comfortable with ssh, "that server in Frankfurt" feels exactly like your own terminal. This lesson gets you there, then teaches its file-copying sibling scp.
```
$ ssh root@localhost -p 2222
```
```
The authenticity of host '[localhost]:2222' can't be established.
ED25519 key fingerprint is SHA256:kFq7...w9lI.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
```
The anatomy: ssh USER@HOST. No user given means 'my current username'. -p picks a non-default port (the default is 22). And on the very first connection you get this famous prompt — the next step decodes it.
The host-key prompt: what 'yes' actually means
Read the first-connection fingerprint prompt and understand the trust decision it's asking for.
Encryption alone isn't enough — you also need to know you're encrypting to the right machine, not an impostor sitting between you and it. So every SSH server has a host key: a unique cryptographic identity. The first time you connect, your client hasn't seen that identity before and shows you its fingerprint, asking: do you trust that this is really the machine you meant?
When you answer yes, the key is saved to ~/.ssh/known_hosts, and every future connection is checked against it automatically. That's why the prompt only appears once per host.
The one prompt you must never ignore
If ssh ever screams WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! it means the machine at that address no longer matches the identity saved in known_hosts. Sometimes that's innocent (the server was reinstalled) — but it is exactly what an attacker impersonating your server looks like. Stop and verify before connecting. And never 'fix' it by disabling host-key checking (StrictHostKeyChecking=no) — that turns off the only defense this system gives you.
Check yourself
You ssh to a server you've used daily for months and suddenly get the first-connection fingerprint prompt again, as if the host were brand new. What's the most likely benign explanation — and what should you do either way?
Passwords vs keys — and generating yours
Understand public-key auth and create a keypair with ssh-keygen.
SSH can authenticate you two ways:
- Password — you type the remote account's password. Simple, but phishable, brute-forceable, and painful to automate.
- Public key — you prove you hold a secret key. Stronger, and after setup: no typing at all.
Key auth uses a keypair:
- the private key (~/.ssh/id_ed25519) — the secret. It stays on your machine. It is never uploaded, never emailed, never pasted into a chat or committed to a repo. Never.
- the public key (~/.ssh/id_ed25519.pub) — the shareable half. Handing it out costs you nothing; it can only verify you, not impersonate you.
The server keeps a copy of your public key; at login your client proves — without revealing the private key — that you hold its other half.
```
$ ssh-keygen -t ed25519
```
```
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Your identification has been saved in /root/.ssh/id_ed25519
Your public key has been saved in /root/.ssh/id_ed25519.pub
```
-t ed25519 picks the modern key type. Accept the default path. The passphrase encrypts the private key on disk — a second lock in case the file is ever stolen. Use one on real machines; in this disposable sandbox, empty is fine.
Permissions are part of the protocol
ssh refuses to use a private key that other users could read. Keep ~/.ssh at mode 700 and the private key at 600 — ssh-keygen sets this correctly, but a careless cp or chmod later can break it, and the error message ('UNPROTECTED PRIVATE KEY FILE') will make sense to you now.
Installing your key and logging in without a password
Put the public key in the server's authorized_keys and use it.
The server-side half of key auth is one file: ~/.ssh/authorized_keys on the server, one public key per line. Any key listed there may log into that account.
The standard installer is ssh-copy-id user@host — it logs in once (with your password) and appends your public key for you, with correct permissions. When password auth is disabled, or you already have shell access, you do the same thing by hand: append the .pub line to the file.
Example — not runnable on your lab box
```
$ cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
```
This is everything ssh-copy-id does, minus the remote login: the public key becomes a line in authorized_keys. Note what's being copied — the .pub file. The private key never moves.
```
$ ssh -p 2222 root@localhost 'hostname; echo connected via: $SSH_CONNECTION'
```
```
signal9-lab
connected via: ::1 51712 ::1 2222
```
Two things at once: ssh can run a single command instead of opening a shell (great for scripts), and $SSH_CONNECTION — set only inside SSH sessions — is proof the command really ran over the wire, not in your local shell.
~/.ssh/config: a whole connection in one word
Write a minimal per-host alias so you stop retyping user/host/port.
Real work means many servers, odd ports, different usernames. Instead of retyping ssh -p 2222 root@localhost, teach your client the recipe once, in ~/.ssh/config:
`
Host labbox
HostName localhost
Port 2222
User root
`
Now ssh labbox means exactly that whole command — and the alias works everywhere the client does: scp labbox:/etc/hosts ., rsync, sftp labbox, all of them.
```
$ ssh -G labbox | head -3
```
```
user root
hostname localhost
port 2222
```
-G asks ssh to print the final resolved settings for a host without connecting — the fastest way to check what your config actually did.
scp: copying files across the wire
Move files to and from a remote machine, including whole directories and odd ports.
scp is cp that understands host:path. Same source-then-destination shape you already know; the side with the colon is the remote side:
`
scp report.txt labbox:/srv/reports/ # push: local → remote
scp labbox:/var/log/app.log . # pull: remote → local
scp -r photos/ labbox:/srv/backup/ # -r copies a directory tree
scp -P 2222 file root@localhost:/tmp/ # -P (capital!) sets the port
`
The port flag flips case: ssh -p, scp -P
The one trap everyone hits. ssh takes lowercase -p for the port — but in scp, lowercase -p means 'preserve timestamps', so the port flag is capital `-P`. Get it wrong and scp doesn't error; it quietly tries port 22 and you stare at a timeout (or copy with a flag you didn't mean). With a ~/.ssh/config alias you sidestep the whole question — the port lives in the config.
When scp isn't the right tool
- rsync — syncing big or repeat transfers: it sends only what changed and can resume; rsync -av photos/ labbox:/srv/backup/photos/. Once a copy takes minutes, you want rsync.
- sftp — an interactive session (sftp labbox) when you'd rather browse with ls/get/put than fire single copies.
All three run over SSH — same keys, same host trust, same config aliases.
Now do it — go passwordless end to end in your live terminal
Chain keygen → install → login into one live sequence so the whole flow becomes muscle memory.
You've seen each piece; now run the whole arc yourself, in order, and watch a password login turn into a key login. Do them one at a time and read what each prints — the payoff is the final command not asking you for anything.
```
$ ssh-keygen -t ed25519 -N '' -f ~/.ssh/id_ed25519 <<< y
```
Make a throwaway keypair non-interactively: -N '' sets an empty passphrase (fine in this sandbox only), -f names the file, and the <<< y answers the 'overwrite?' prompt if a key already exists. Your terminal shows the key's randomart — proof the pair now exists.
```
$ cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
```
Install the PUBLIC half into the server's authorized_keys (here the server is this same box) and lock the file to 600. Watch that only the .pub is ever named — the private key stays put. This is ssh-copy-id done by hand.
```
$ ssh -p 2222 -o PasswordAuthentication=no root@localhost 'echo key-login OK'
```
The moment of truth. -o PasswordAuthentication=no tells ssh 'refuse to fall back to a password' — so if this prints key-login OK, it can ONLY have worked via your key. You just logged into another machine with no password at all. That's the everyday reality of Linux administration.
If key login fails, read the permissions first
Nine times out of ten a failed key login is a permissions problem, not a key problem. Add -v to your ssh command to watch it try each key and say why the server refused. Check ~/.ssh is 700 and authorized_keys is 600 — ssh silently ignores a keys file the group or world can write, precisely because an attacker could otherwise add their own key to it.
SSH safety, in five lines
Internalize the non-negotiables before the labs.
The rules that keep you employed
1. The private key is a secret: it never leaves your machine — never pasted into chats/issues/AI tools, never committed to a repo, never emailed.
2. Passphrase-protect private keys on real machines; the sandbox is the only place skipping it is fine.
3. Never disable host-key checking. A changed-key warning is a question to investigate, not an error to silence.
4. ~/.ssh is 700, private keys are 600 — ssh enforces this, on purpose.
5. Labs here generate throwaway keys inside the sandbox. Never use your real personal or work credentials in any lab, on any platform.
That's the toolkit: ssh to be there, scp to move things, keys to skip passwords, known_hosts to trust deliberately, and ~/.ssh/config to make it all one word. Three labs await — first login and key setup, then an scp round trip, then the config alias.

Recap

ssh user@host opens an encrypted shell on another machine; -p picks a non-default port
First connection shows the host-key fingerprint; 'yes' pins it in ~/.ssh/known_hosts and a CHANGED warning later means stop and verify
ssh-keygen -t ed25519 makes a keypair: .pub is shareable, the private key never leaves your machine
A public key listed in the server's ~/.ssh/authorized_keys (ssh-copy-id or manual append) = passwordless login
~/.ssh/config Host blocks turn user+host+port into one alias; ssh -G shows what resolves
scp copies with cp's grammar (host: marks the remote side), -r for directories, capital -P for port; rsync for big/repeat syncs, sftp for interactive browsing

The ssh/scp field guide
Task	Command	Watch out for
Log in	ssh user@host	no user = your current username
Non-default port	ssh -p 2222 user@host	ssh uses lowercase -p
Run one remote command	ssh host 'cmd'	quotes keep the command for the remote shell
Make a keypair	ssh-keygen -t ed25519	guard the private key; ~/.ssh 700, key 600
Install your key	ssh-copy-id user@host	copies the .pub only, never the private key
Alias a connection	Host block in ~/.ssh/config	ssh -G host shows what it resolves to
Push a file	scp file host:/path/	the colon side is remote
Pull a file	scp host:/path/file .	'.' = the current local directory
Copy a directory	scp -r dir/ host:/path/	-r for a whole tree
scp on an odd port	scp -P 2222 file host:/tmp/	CAPITAL -P (lowercase -p = preserve times)
Big / repeat transfer	rsync -av src/ host:/dst/	sends only what changed; can resume

Reaching Other Machines: ssh & scp

Nearly all real Linux work is remote

The host-key prompt: what 'yes' actually means

Passwords vs keys — and generating yours

Installing your key and logging in without a password

~/.ssh/config: a whole connection in one word

scp: copying files across the wire

Now do it — go passwordless end to end in your live terminal

SSH safety, in five lines