Power User and DevOps Foundations: servers, logs, security and AI agents in the terminal

01

Remote servers like a professional: SSH config and jump hosts

In simple words

Typing a long address every time you visit a friend is tiring and easy to get wrong. So you write each friend's address in a small address book once, give it a short nickname, and just say the nickname. An SSH config file is that address book for servers.

Key facts

Before this course: Automation in the Terminal: Git, package managers and scheduled jobs (course 7.11.3). You can already use Git, a package manager, SSH keys and scheduled jobs, and you built a backup job that never deletes. Here you learn to run and protect real servers, and to lead others who do.
An SSH config file stores settings per server so you can type ssh web1 instead of a long command. Per the OpenSSH manual, ssh reads settings in this order: command-line options, your own file ~/.ssh/config, then the system file /etc/ssh/ssh_config. For each setting, the first value found wins. So put specific Host blocks near the top and general defaults (Host *) at the end.
Host starts a block for one or more name patterns. HostName is the real address. User is the account to log in as. Port is the port number (default 22). IdentityFile names a private key. IdentitiesOnly yes makes ssh use only the keys you configured, even if an agent offers more.
Jump hosts: ProxyJump web1 (or ssh -J web1 target) connects to web1 first and goes on from there to an inner server that is not reachable from the internet.
Agent forwarding (ForwardAgent yes or ssh -A) lets a remote computer use your local SSH agent. The manual says to enable it with caution: someone who can bypass file permissions on that remote computer can use your keys to log in as you while you are connected. It suggests a jump host as a safer alternative. Keep ForwardAgent no (the default).
Host key checking: with the default StrictHostKeyChecking ask, ssh asks before trusting a new server and refuses to connect if a known server's key has changed (course 7.11.3 Lesson 4). Never turn this off to "make a warning go away".
Port forwarding: ssh -L 8080:localhost:80 web1 forwards port 8080 on your computer to port 80 as seen from web1. It is a safe way to reach a private admin page without opening it to the internet.
ssh -G NAME prints the settings ssh would use for that name and exits without connecting. Use it to check your file before you rely on it.

Example (practice file ssh_config, tested on macOS)

Host web1
  HostName 203.0.113.10
  User ana
  Port 2222
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Host internal-db
  HostName 10.0.0.5
  User ana
  ProxyJump web1

Host *
  ForwardAgent no
  User guest

Running ssh -G -F ssh_config web1 printed user ana (not guest), because the web1 block comes first and the first value wins. A name with no block of its own, such as other.example, got user guest and port 22.

OS difference	Mac	Linux	Windows
Your config file	`~/.ssh/config`	`~/.ssh/config`	`%userprofile%\.ssh\config`
System-wide file	`/etc/ssh/ssh_config`	`/etc/ssh/ssh_config`	`%programdata%\ssh\ssh_config`
Check settings without connecting	`ssh -G web1`	`ssh -G web1`	`ssh -G web1`
SSH client included?	Yes	Usually	Optional feature, from Windows 10 build 1809 (course 7.11.3)

Step by step

In your practice folder, create a file called ssh_config with the example above. It uses made-up addresses, so nothing will connect.
Run ssh -G -F ssh_config web1 | grep -E '^(hostname|user|port|identityfile|forwardagent) '. Check that you see user ana, port 2222 and forwardagent no.
Run ssh -G -F ssh_config internal-db | grep proxyjump. You should see proxyjump web1.
Run ssh -G -F ssh_config other.example | grep -E '^(user|port) '. You should see user guest and port 22, the defaults from the Host * block and ssh.
Move the Host * block to the top of the file and repeat step 2. Now user says guest: the first value won. Move it back to the end.
Check a port forward without connecting: ssh -G -F ssh_config -L 8080:localhost:80 web1 | grep -i localforward.
When you have a real practice server, copy only the blocks you need into ~/.ssh/config, keep ForwardAgent no, and test with ssh -G before your first real login.
Check: you can explain why the order of blocks matters, and why a jump host is safer than agent forwarding.

Watch on YouTube

Set up and use SSH keysHetzner · YouTube · youtube.com

Videos by other creators on YouTube, for reference. They are not made by or affiliated with The Future Market.

LESSON 01Remote servers like a professional: SSH config and jump hosts

LESSON 01 / ANIMATED LESSON / AI VOICE00:00 / 01:00

Voice

Read the video script

[Host] "An SSH config file is an address book for servers. Write each one once, then just type its nickname."
[Screen: Host web1 block with HostName, User, Port] "A Host block holds the real address, the user, the port and the key."
[Text on screen: The first value found wins] "ssh uses the first value it finds. Specific servers go at the top, general defaults at the bottom."
[Text on screen: ProxyJump = safer than ForwardAgent] "To reach an inner server, jump through another one. Keep agent forwarding off."
[Screen: ssh -G web1] "And before you trust your file, ssh dash G shows the settings without connecting."

Try it now

Write a practice config with three servers: one public web server, one inner database server reached through the web server, and a default block. Prove with ssh -G that each server gets the right user, port and jump host. Then ask a classmate to read your file and predict the user for each name before running ssh -G.

ClaudeStuck? Copy a ready-made prompt for Claude

Copy this, open Claude, paste it, and Claude will walk you through the lesson step by step.

For a grown-up: Claude is for adults (18+). Copy this, paste it into Claude, and use the answer to explain the lesson to your child.

I'm learning "Power User and DevOps Foundations: servers, logs, security and AI agents in the terminal" on The Future Market. Lesson 1: "Remote servers like a professional: SSH config and jump hosts".

What the lesson teaches:
- Before this course: Automation in the Terminal: Git, package managers and scheduled jobs (course 7.11.3). You can already use Git, a package manager, SSH keys and scheduled jobs, and you built a backup job that never deletes. Here you learn to run and protect real servers, and to lead others who do.
- An SSH config file stores settings per server so you can type ssh web1 instead of a long command. Per the OpenSSH manual, ssh reads settings in this order: command-line options, your own file ~/.ssh/config, then the system file /etc/ssh/ssh_config. For each setting, the first value found wins. So put specific Host blocks near the top and general defaults (Host ) at the end.
- Host starts a block for one or more name patterns. HostName is the real address. User is the account to log in as. Port is the port number (default 22). IdentityFile names a private key. IdentitiesOnly yes makes ssh use only the keys you configured, even if an agent offers more.
- Jump hosts: ProxyJump web1 (or ssh -J web1 target) connects to web1 first and goes on from there to an inner server that is not reachable from the internet.
- Agent forwarding (ForwardAgent yes or ssh -A) lets a remote computer use your local SSH agent. The manual says to enable it with caution: someone who can bypass file permissions on that remote computer can use your keys to log in as you while you are connected. It suggests a jump host as a safer alternative. Keep ForwardAgent no (the default).
- Host key checking: with the default StrictHostKeyChecking ask, ssh asks before trusting a new server and refuses to connect if a known server's key has changed (course 7.11.3 Lesson 4). Never turn this off to "make a warning go away".
- Port forwarding: ssh -L 8080:localhost:80 web1 forwards port 8080 on your computer to port 80 as seen from web1. It is a safe way to reach a private admin page without opening it to the internet.

The exercise I'm working on:
Write a practice config with three servers: one public web server, one inner database server reached through the web server, and a default block. Prove with ssh -G that each server gets the right user, port and jump host. Then ask a classmate to read your file and predict the user for each name before running ssh -G.

I'm stuck. Please:
1. Explain the main idea in plain, simple words with one everyday example.
2. Walk me through the exercise one small step at a time. Ask me what I've done so far before giving the next step.
3. Don't just give me the final answer. Help me do it myself, and check my work when I share it.

I'm a parent helping my child (about 8 years old) with a lesson called "Remote servers like a professional: SSH config and jump hosts" from the course "Power User and DevOps Foundations: servers, logs, security and AI agents in the terminal".

Here's what the lesson says:
Typing a long address every time you visit a friend is tiring and easy to get wrong. So you write each friend's address in a small address book once, give it a short nickname, and just say the nickname. An SSH config file is that address book for servers.

The activity:
Write a practice config with three servers: one public web server, one inner database server reached through the web server, and a default block. Prove with ssh -G that each server gets the right user, port and jump host. Then ask a classmate to read your file and predict the user for each name before running ssh -G.

Please explain this so an 8-year-old understands: short sentences, a fun everyday example, and no hard words.
Then give me 3 simple questions I can ask my child to check they understood, and a way to do the activity together, one tiny step at a time.

Open Claude

Sources

OpenBSD manual, ssh_config(5): man.openbsd.org/ssh_config
OpenBSD manual, ssh(1): man.openbsd.org/ssh
Microsoft Learn, OpenSSH Server configuration for Windows (client file order): learn.microsoft.com/en-us/windows-server/administration/openssh/openss

My notes

I learned this

02