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 this section’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 unit, 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

This section’s Tools at a Glance

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.

This section’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 program initiating the connection. On Windows, confirm Get-Command ssh and ssh -V. OpenSSH Client is a Windows optional feature; it is not part of PowerShell itself.

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

Before you begin. For this exercise, prefer an isolated host-only link or a VirtualBox NAT forwarding rule bound to host 127.0.0.1:2222 and guest port 22. Verify the guest host-key fingerprint through its console before accepting the client prompt. Do not expose SSH on your home router.

3-1. Prepare a private connection

Use a disposable Ubuntu VM and an ordinary lab account. On the VM, install the server after reviewing the package plan. Then inspect the service and listener.

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh
ss -ltn

Service state and a listening socket are separate observations. If the service is not running, consult the Ubuntu documentation for your installed version. Do not expose this exercise through a home-router port-forward rule.

Choose a host-only network, or configure VirtualBox NAT forwarding with host IP 127.0.0.1, host port 2222, and guest port 22. With NAT forwarding, set the following Windows values. Replace lee with the actual guest account.

$guestUser = 'lee'
$guestAddress = '127.0.0.1'
$sshPort = 2222
Get-Command ssh
ssh -V

For a host-only network, instead set guestAddress to the guest address shown by ip a and sshPort to 22. A guest NAT address such as 10.0.2.15 is normal; it is not itself proof of a fault.

3-2. Verify the server before accepting it

In the VM console, collect the host public-key fingerprint through this independent path:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Now connect from Windows:

ssh -p $sshPort "$guestUser@$guestAddress"

Compare the displayed fingerprint and key type with the VM console before typing yes. If a different key type is selected, inspect the matching host public key. If fingerprints differ, stop and resolve the discrepancy. Successful verification identifies the server key; it is not proof that every program on the VM is trustworthy.

Enter the guest password when prompted, then run whoami and pwd. These commands now execute in the guest. Type exit to return to Windows.

3-3. Create a separate practice key

In Windows, create a uniquely named key rather than replacing an existing default key. Enter a passphrase when prompted and keep it private.

$keyPath = Join-Path $HOME ('.ssh\infosec-book01-' + [guid]::NewGuid().ToString('N'))
New-Item -ItemType Directory -Force (Split-Path $keyPath) | Out-Null
ssh-keygen -t ed25519 -f $keyPath -C infosec-book01-lab

The private file stays on Windows. Only the .pub file is copied. In this disposable account, append the public line without replacing other authorized keys:

Get-Content -LiteralPath ($keyPath + '.pub') |
  ssh -p $sshPort "$guestUser@$guestAddress" 'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys'

Test the selected key explicitly. A key-passphrase prompt is different from a guest-account password prompt.

ssh -i $keyPath -o IdentitiesOnly=yes -p $sshPort "$guestUser@$guestAddress"

Run whoami, then exit. If password authentication is still used, inspect the client diagnostic output with -v and the guest configuration. Do not publish the diagnostic log without reviewing its paths and identifiers.

3-4. Transfer and verify one fixture

Create a uniquely named local text fixture and send it to the guest account. scp uses uppercase -P for the port.

$transferName = 'infosec-book01-' + [guid]::NewGuid().ToString('N') + '.txt'
Set-Content -LiteralPath $transferName -Value 'Hello from the lab.' -Encoding UTF8
scp -P $sshPort -i $keyPath $transferName "${guestUser}@${guestAddress}:./$transferName"

Read the exact filename in the guest and compare the contents. Record the source and destination paths. Remove only that fixture if cleaning up; retain the practice key until the exercise is complete.

3-5. Revoke the practice access

In the guest, identify the exact infosec-book01-lab public-key line and remove only that line from authorized_keys. Confirm the explicitly selected key no longer authenticates. An existing session can remain open, and password login may still be permitted. Close the session and remove only the forwarding rule created for this exercise. A changed host-key warning requires independent verification before updating a saved key.

4. Missions & Exercises

Mission — Complete the Fingerprint Check and Key Management

1. 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?
2. 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
3. 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 .)
4. 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
5. 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?

# 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 .

6. Common Pitfalls & Fixes

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

If NAT prevents the host from reaching the guest, use a host-only adapter or bind a VirtualBox forwarding rule to host 127.0.0.1:2222 and guest port 22. Connect with ssh -p 2222 lee@127.0.0.1. Keep the host firewall enabled, verify the guest fingerprint, and remove the forwarding rule when finished.

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

This section’s Concepts

This section’s Commands

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, this section’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.