Step 29. SSH Remote Access — Opening the Encrypted Front Gate

Level 0 — Understanding Computer Operation and Structure | Difficulty ★★★☆☆ | Estimated time: 4 hours

Prerequisites: You must have finished the VM environment from Steps 16–17, plus Step 21 (apt) and Step 24 (sudo). You need both an Ubuntu VM and the host PC (Windows PowerShell).

What you need: An Ubuntu VM and Windows PowerShell. You’ll install one package, openssh-server, on Ubuntu.
Caution — this book’s absolute rule: The only target of today’s practice is your own VM that you installed yourself. Attempting to connect to someone else’s computer or server without permission is a crime that the label "experiment" cannot justify (an intrusion under Korea’s Network Act). The bigger your skills grow, the stricter this boundary becomes. Run every command today only inside your own lab.

Until now, you’ve worked directly inside a VM window sitting in front of you. But real servers mostly live in faraway data centers or the cloud, with no screen and no keyboard. The de facto single standard for issuing commands to such a computer is SSH (Secure Shell). Today you’ll succeed at connecting from host Windows into the Ubuntu VM, and go all the way to public-key authentication — logging in with a key instead of a password. Your first experience of "issuing commands wirelessly to the computer in the next room" is genuinely fascinating.

1. Learning Objectives

By the end of this chapter, you will be able to:

Explain what SSH is and which problem of plaintext communication it solves
Install an SSH server on Ubuntu, start it with systemctl, and check its status
Successfully connect from Windows PowerShell into the VM with ssh user@address
Create a public/private key pair and connect without a password
Send and receive files with the remote machine using scp

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language & environment	Windows PowerShell (client) + Ubuntu terminal (server)
Today’s commands	`sudo apt install openssh-server` (install the server), `sudo systemctl start/status ssh` (manage the service), `ip a` (check the address), `ssh user@address` (connect), `ssh-keygen` (make keys), `scp file user@address:~/` (transfer a file)
Concepts needed	The danger of plaintext communication, server vs. client, port 22, public-key authentication (padlock and key), fingerprints

2-1. Why Encryption — A Story from the Old Days

In the early internet, there was a remote access method called telnet. The problem: everything, including passwords, traveled the wires in plaintext — raw, unencrypted. Anyone eavesdropping on the same network saw passwords in the clear. So we needed communication that would be "safe even if the wires are tapped," and SSH was the answer.

Today’s lesson: "Unencrypted communication is a postcard." Assuming anyone can read it is basic security common sense, and SSH is the tool that common sense built.

2-2. Server and Client

SSH has two roles:

SSH server: The side that "accepts" connections. Today you’ll install it on the Ubuntu VM (openssh-server). The standard is to wait on port number 22.
SSH client: The side that "initiates" connections. Windows PowerShell already has the ssh command built in.

Think of a port as "a per-program window number inside one computer." Even at the same address (IP), window 22 is SSH, window 80 is the web, and so on.

2-3. Public-Key Authentication — Padlock and Key

The weakness of password login: the password must be sent to the server every time, and if someone learns it, it’s over. SSH’s safer method is public-key authentication.

You forge a pair of keys: a public key and a private key.
The analogy: the public key is a padlock; the private key is the key that opens it.
You hang the padlock (public key) on the server. It doesn’t matter who sees it.
You hide the key (private key) on your own computer. Never give it to anyone.
When you connect, the server tests: "Got a key that opens this padlock?" — and your private key proves it mathematically. The key itself never travels the wire.

If a password is "something you know," a private key is "something you have." And since that one private key file is effectively your ID card, managing it well is itself security.

3. Follow Along

Every output in this chapter differs by environment (address, username, fingerprint), so all outputs below are sample outputs in the same format as the real screen. Read along with the values on your own screen.

3-1. Installing and Starting the SSH Server on Ubuntu

In the VM’s terminal:

sudo apt update && sudo apt install -y openssh-server

This is the apt you learned in Step 21. A server program is, in the end, just a package. When installation finishes, start it and view its status:

sudo systemctl start ssh
sudo systemctl status ssh

● ssh.service - OpenBSD Secure Shell server
     Active: active (running) ...

(Sample output.)

How to read it: systemctl is the command for managing services (daemons, Step 26). If you see "active (running)", the SSH server is alive and waiting on port 22. Press q to leave the status screen.

3-2. Checking the VM’s Address

ip a

...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    inet 192.168.39.82/20 brd ... scope global eth0
...

(Sample output — this is what it actually looks like. lo‘s 127.0.0.1 is the special "myself" address and isn’t for connecting; find the inet address of a real card like eth0 or ens33.)

How to read it: This number is the VM’s IP address — its home address on the network. If no address appears here, or you only see 10.0.2.15, it may be a problem with the VM’s network mode. Wall 1 solves it.

3-3. First Connection from Windows

In the host PC’s PowerShell (use your own address and username):

ssh lee@192.168.x.x

The authenticity of host '192.168.x.x' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxx...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

(Sample output — this confirmation appears only on the first connection.)

How to read it: It’s asking, "This server is new to me — can I really trust it?" The fingerprint is the server’s ID number, used to verify that it really is your VM (you’ll compare it yourself in the mission). Since it is indeed your own VM connecting for the first time, type yes; when it then asks for a password, enter your Ubuntu account’s password.

lee@ubuntu:~$

(Sample output.)

How to read it: The prompt has changed. Right now you’re sitting at Windows, driving Ubuntu. Try whoami and ls — they all execute inside the VM. Type exit to leave.

Why: This one line is the entirety of remote administration. Every remote Linux box you’ll ever touch, you enter through this one line.

3-4. Forging the Keys — ssh-keygen

In Windows PowerShell (locally, not while connected):

ssh-keygen

Generating public/private ed25519 key pair.
Enter file in which to save the key (C:\Users\Me/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):

(Sample output.)

How to read it: It’s forging a key pair. Press Enter for the save location (the default), and for the passphrase (the key’s own password), press Enter to leave it empty for practice. Two files are then created:

id_ed25519 — the private key. The file you never give to anyone.
id_ed25519.pub — the public key. The padlock you’ll hang on the server. .pub is public.

3-5. Hanging the Padlock on the Server

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh lee@192.168.x.x "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

(Sample output: it asks for the password once, and if it ends with no message, that’s success.)

How to read it: What this one line does — it reads my public key (.pub) with type, connects to the VM over SSH, and appends it (>>) to the end of ~/.ssh/authorized_keys ("the roster of authorized keys") over there. It’s posting a list at the server’s front door: "Let in whoever holds this key." It’s also the moment two worlds connect, with the pipe (|) letting Windows’s output flow into Linux’s input.

Make a prediction: If you now run ssh lee@192.168.x.x again, will it ask for a password, or not? Predict, then connect. (Answer: the prompt appears immediately, with no password. The server checked its padlock, and my private key opened it.)

3-6. Sending a File — scp

echo "my first file sent remotely" > hello-remote.txt
scp hello-remote.txt lee@192.168.x.x:~/

hello-remote.txt                    100%   30     0.0KB/s   00:00

(Sample output.)

How to read it: scp is "copy over SSH" (secure copy). The format is file-to-send user@address:destination, and ~/ is my home folder over there.

Verify: Connect via SSH and type cat hello-remote.txt. The file you just made on Windows is sitting in Ubuntu.

Why: Moving files to and from a remote server is the daily bread of real work. Fetching backups, uploading scripts, downloading logs — all of it is scp (or its relatives).

4. Missions & Exercises

Mission — Complete the Fingerprint Check and Key Management

Fingerprint comparison: Compare the fingerprint you saw on the first Windows connection against the one the VM prints directly with sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub — are they the same fingerprint?
Double status check: On the VM, run both systemctl status ssh (is the service alive?) and ss -tlnp | grep 22 (is it listening on port 22?) to confirm "server survival" in two different ways
Round-trip transfer: Send a file from Windows → VM (scp), and the reverse — create a file on the VM and bring it to Windows (scp lee@address:~/remote.txt .)
Key revocation and re-registration: On the VM, delete your public key’s line with nano ~/.ssh/authorized_keys → confirm that connecting asks for the password again → register it again
Record every place you got stuck and how you solved it in ssh-report.txt

Exercises

Question 1. What is the problem with plaintext remote access like telnet, and how does SSH solve it?

Question 2. In public-key authentication, what do you upload to the server, and what do you keep hidden on your computer? Why must you never upload the private key to the server?

Question 3. What is the fingerprint check on first connection for, and what kind of attack (a man-in-the-middle attack) does it block?

Question 4. An ssh connection that fails instantly with "Connection refused" and one that hangs for a while then "times out" have different causes. What should you suspect and check in each case?

5. Model Answers & Completion Criteria

Mission Model Answer

# 1. Inside the VM — print the server's real fingerprint
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

# 3. Windows → VM, and the reverse direction
scp hello-remote.txt lee@192.168.x.x:~/
scp lee@192.168.x.x:~/remote.txt .

How to verify: ① In step 1, does the SHA256:... part of the fingerprint the VM printed itself match the fingerprint PowerShell showed on first connection? If they match, you’ve proven that "the party I connected to is really my server." This is the professional habit that catches man-in-the-middle attacks (where someone sets up a fake server to intercept your connection). ② In step 2, did both commands point to port 22 and ssh? ③ In step 4, after deleting the key, did the password prompt come back — and after re-registering, did it disappear again? Only when you’ve done both registration and revocation are you truly managing keys.

Exercise Solutions

Question 1 solution. With plaintext access, everything — including the password — travels the wires unencrypted, exposed as-is to any eavesdropper on the same network. SSH encrypts everything that passes back and forth, so even if it’s intercepted midway, it can’t be read.

Question 2 solution. What you upload to the server is the public key (the padlock, registered in authorized_keys); what you keep hidden on your computer is the private key (the key). Uploading the private key to the server means anyone who gets into that server can pick up your ID card — a padlock may be scattered freely, but if the key is duplicated, every door opens.

Question 3 solution. It’s an ID-checking device that verifies "is the party I’m connecting to now the server I know?" A man-in-the-middle attack is one where an attacker sets up a fake server to intercept your connection and steal your password or session; since a fake server has a different fingerprint, comparing fingerprints catches it.

Question 4 solution. An immediate refusal (refused) means you reached the address, but that house’s door 22 is closed — most likely the SSH server isn’t running. Check with sudo systemctl status ssh and start it. A timeout means you never reached the house at all — suspect the network mode (NAT blocks incoming connections), a wrong address, or a firewall. Check the bridged or port-forwarding setup in Wall 1.

Completion Criteria Checklist

[ ] I can explain which problem of plaintext communication SSH solves
[ ] I can install openssh-server, start it with systemctl, and check its status
[ ] I successfully connected from Windows to Ubuntu via ssh
[ ] I can explain the roles of the public/private keys and the principle "never share the private key"
[ ] I know what authorized_keys is and why the permissions (700/600) matter
[ ] I can send and receive files in both directions with scp
[ ] Mission: I completed the fingerprint comparison, double status check, round-trip transfer, and key revocation/re-registration

6. Common Pitfalls & Fixes

Wall 1. "ip a only shows 10.0.2.15, and I can’t connect from Windows"

Symptom: The ssh connection spins for a while, then fails (times out).
Cause: VirtualBox’s default network mode (NAT) lets the VM go "outbound only," and blocks connections coming in from outside.
Fix: There are two roads. ① Change the network to Bridged in the VM settings, and it receives an address like any device on your home network. ② Keep NAT but set up port forwarding (an exception rule that sends host port 2222 → guest port 22), then connect with ssh -p 2222 lee@127.0.0.1. Once one of the two works, the rest is the same.

Wall 2. "I get Connection refused"

Symptom: Not a timeout — a "refused" appears instantly.
Cause: You found the right address, but that house’s door 22 is closed — the SSH server isn’t running.
Fix: On the VM, check with sudo systemctl status ssh; if it’s dead, sudo systemctl start ssh. To make it start automatically after reboots too: sudo systemctl enable ssh.

Wall 3. "I registered the key, but it still asks for a password"

Symptom: You registered the public key, yet the password prompt still appears.
Cause: Three usual suspects. ① The ~/.ssh folder’s permissions over there are too loose (for security, SSH ignores keys unless the permissions are 700). ② authorized_keys permissions aren’t 600. ③ The public key was copied wrong (a broken line break).
Fix: On the VM, run chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys, then try again. This "pickiness" of SSH isn’t a bug — it’s security: it means "I refuse to trust a roster file that others can open."

Wall 4. "A scary warning says the fingerprint changed"

Symptom: On connecting, WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! appears and the connection is refused.
Cause: A server with a different fingerprint than the one stored for that address is answering. You reinstalled the VM, or the IP address changed — or, rarely, it’s a real man-in-the-middle attack.
Fix: If you’re certain the cause is something legitimate like "I reinstalled the VM," delete that address’s line from Windows’s C:\Users\Me\.ssh\known_hosts file and connect again. But if you meet this warning on a real server, don’t delete it carelessly — the rule is to check with the server administrator first.

Wall 5. "I ran scp and got Permission denied"

Symptom: The file transfer is refused.
Cause: The connection worked, but in most cases you don’t have write permission on the destination folder over there (for example, trying to drop straight into /etc).
Fix: The safe order is to send it to your home (~/) first, then move it over there with sudo. The permissions from Steps 23–24 apply remotely, exactly as they are.

7. Summary

Today’s Concepts

Concept	One-line description
SSH	The standard for encrypted remote access — server (waiting on 22) and client
Port	A per-program window number inside one computer (SSH is 22)
Public key / private key	The padlock hung on the server / the key hidden on my computer
authorized_keys	The "roster of authorized keys" at the server’s door (~/.ssh is 700, this file is 600)
fingerprint	The server’s ID number — the habit of comparing it on first connection
known_hosts	The ledger of server fingerprints I’ve verified

Today’s Commands

Command	What it does
`sudo apt install openssh-server`	Install the SSH server
`sudo systemctl start/status/enable ssh`	Start the server / view status / auto-start at boot
`ip a`	Check this computer’s address
`ssh user@address`	Connect remotely
`ssh-keygen`	Forge a key pair
`scp file user@address:~/`	Copy a file remotely and securely
`ss -tlnp \| grep 22`	Check whether it’s listening on port 22

The Instinct That Matters More Than Commands

From the moment your first SSH connection succeeds, a "computer" is no longer the machine in front of you. Any box beyond the network — given an address and a key — becomes your workbench. At the same time, today’s practice had one boundary line: what you connected to was a VM you installed yourself and registered a key on. Today you learned both: the skill of forging keys, and the judgment of telling which doors you may use them on.

Remember two more things. First, the server-side SSH configuration lives in /etc/ssh/sshd_config, and a production server’s basic defensive wall is "disable password login + allow keys only" — because every port 22 in the world receives countless brute-force login attempts every single day. Today you forged the material of that wall (the key) with your own hands. Second, SSH is both the door attackers target and the administrator’s only entrance. One technology standing at the center of both offense and defense — today, for the first time, you held in your hands the structure this whole book will keep repeating.

The principle of using your key only on doors you’re permitted to open doesn’t change, no matter how the technology changes. On top of that principle, your hands now move freely across the remote world.

Once every box is checked, Step 29 is complete. Click the checkbox in the sidebar to save your progress.