Linux › Module 4 › Lesson 3
wget, curl, ssh
Download files with wget and curl, and manage servers with SSH
Opening
The terminal is a browser, a downloader, and a front door
curl and wget speak HTTP without a GUI. ssh is how you sit at a remote Linux prompt through encryption instead of telnet's postcard. Together they are how you fetch a script, inspect a response, and administer a VM you own. They are also how secrets leak: a token in a curl header that hits the shell history, a private key pasted into Discord, or typing yes when SSH screams that the host key changed. This lesson is the safe habits, not a license to log into strangers.
1. curl -I vs wget: inspect versus save
wget is the "save this URL to a file" tool. wget https://example.com/file.iso writes file.iso in the current directory and shows a progress bar. It is great for fetching a known object onto a lab VM. Recursive wget against sites you do not own is not a lab — it can violate terms, law, and bandwidth. curl is the Swiss Army client: it can print the body to stdout, send methods and headers, talk to APIs, and follow redirects when you ask. curl -I (HTTP HEAD, or a HEAD-like header dump depending on the server) is the defender's first look: status code, Server, Location, cookies flags, HSTS. You learn whether HTTPS redirects, whether a leftover header leaks a framework version — on a target you are allowed to touch. Rule of thumb: wget when you want a file on disk; curl -I when you want metadata; curl when you need headers, methods, or to pipe the body into another command. Never put live API keys on the command line if you can use a file or an environment variable that will not be screenshot into a ticket.
2. SSH keys, known_hosts, and host key verification
ssh user@host opens an encrypted session. Password auth is still common and still phishable and brute-forceable. SSH keys are a key pair: the private half stays in ~/.ssh (mode 600), the public half goes in the server's authorized_keys. Anyone with the private key is you. There is no "just this once" paste to a classmate. Generate keys on your machine; never reuse a key from a blog. The first time you connect, SSH asks you to trust a host key fingerprint. That is Trust On First Use. Compare the fingerprint with an out-of-band source (cloud console, a teammate on a known-good channel) when the host matters. The fingerprint is stored in ~/.ssh/known_hosts. If a later connection says WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED, stop. That is either a rebuilt VM with a new key, or an on-path attacker. Blindly deleting the known_hosts line and typing yes is how MITM wins. Confirm the rebuild, then replace the pin on purpose — not in panic. Disable StrictHostKeyChecking only in disposable lab automation you fully understand, never as a default on production laptops.
3. Wrong vs right: pasting secrets and ignoring host keys
Worked failure mode — convenience versus verification. Practice only against hosts you own or have written permission to use.
Wrong
curl -H "Authorization: Bearer real-prod-token" https://api.example.com and the token lands in .bash_history and a Twitch overlay. Private key committed to GitHub. First SSH warning about a changed host key, you type yes because the build is late. wget -r a whole company site "to learn HTML."
Right
curl -I against example.com or your own site. Tokens via env files mode 600, not argv. ssh-keygen locally; public key only on YOUR VMs. On a host-key mismatch: halt, verify, then update known_hosts. Never ssh to a box you are not authorized to enter.
4. Practical: headers, then inspect ~/.ssh without leaking keys
Fetch headers from a public site you are allowed to use (example.com is designed for documentation). List your .ssh directory permissions. Do not cat private keys into the terminal or the chat.
Command guide
curl / wget / ssh hygiene on YOUR VM
Headers only (example.com is for documentation)
Command — copy this
curl -I https://example.com
Optional command
wget: save a small public file into YOUR lab folder
Command — copy this
mkdir -p "$HOME/cyberlium-lab/m04-http" cd "$HOME/cyberlium-lab/m04-http" wget -O example-index.html https://example.com/
Optional command
SSH key hygiene — inspect, do not print secrets
Command — copy this
ls -la "$HOME/.ssh" 2>/dev/null || echo 'No ~/.ssh yet — OK for a new lab user'
Private keys should be -rw------- (600). Pub keys are 644.
Generate a key ONLY on your machine if you need one (no passphrase skip on real hosts)
Optional command
ssh-keygen -t ed25519 -f "$HOME/.ssh/cyberlium_lab" -C "lab-only" chmod 600 "$HOME/.ssh/cyberlium_lab"
Connect only to hosts you own, e.g. your VM:
Optional command
ssh [email protected] ssh -p 2222 youruser@YOUR-VM-IP
NEVER: cat ~/.ssh/id_* into chat, tickets, or git NEVER: curl with a live production token on the command line NEVER: ssh user@random-ip you do not own NEVER: blindly accept a changed host key
Mission: curl -I and a 600 private key check
Run curl -I https://example.com and note the HTTP status. If ~/.ssh exists, ls -l it and confirm private keys are 600 (or record that you have none yet). Do not paste key material anywhere. Do not SSH to machines you do not own. Optional: wget a file into $HOME/cyberlium-lab/m04-http.
Stuck? Ask Cyberlium AI Mentor
If SSH host-key warnings still feel scary, ask Cyberlium AI Mentor for a hint — not a command that disables all checking. Try: "Hint only: known_hosts changed after I rebuilt MY VM — what should I verify before deleting the old line?"
You can tell curl -I from wget, keep SSH private keys private, and treat known_hosts as a security control instead of a nuisance. Next — Lab — Network Recon with Linux — ip addr, ping 127.0.0.1, and ss -tuln on your own machine, with permission as the first rule.
Knowledge Check
APPLY: You need to see whether https://example.com returns 200 and which server header it sends, without saving the HTML. Best command?
Multiple choice
Knowledge Check
APPLY: SSH says the remote host identification has changed for a VM you did not rebuild. What is the secure next step?
Multiple choice
Knowledge Check
APPLY: True or False: It is acceptable to paste an SSH private key into a group chat "just so a teammate can get in tonight," if you delete the message tomorrow.
True or False