Other machines: ssh and package managers

Recall from lesson 6-1 that chmod 600 on a file leaves read and write permission for the owner and nothing at all for anyone else, so no other user on the machine can read its contents.

This lesson is where that becomes more than good hygiene. SSH refuses to use a private key file unless its permissions are locked down exactly that way, on the grounds that a key readable by other accounts is a key that may already be compromised.

ssh: your shell, on another computer

Every server you'll ever deploy to is a Linux machine in some datacenter, and you'll drive it with the exact skills from this course. ssh (secure shell) opens a shell on a remote machine over an encrypted connection:

ssh deploy@example.com

Read it as user@machine. After connecting, your prompt changes and every command you type (cd, ls, tail, all of it) runs over there, on that machine's filesystem. exit brings you home.

Instead of passwords, professionals use key pairs: a private key file that stays on your laptop (chmod 600!) and a public key placed on the server. ssh-keygen creates the pair. Bonus tool: scp file user@host:path copies files across, cp-style.

A remote session from connect to exit

This session connects to a server, investigates a log using skills from units 3 and 5, and disconnects. Each command is shown with the output it produced.

Connecting names the user and the machine in the user@host form:

$ ssh deploy@example.com
Welcome to Ubuntu 24.04 LTS
deploy@web-1:~$

Look closely at that last line, because the prompt itself changed. It now reads deploy@web-1, which is the server announcing who you are and where you are. From this point on, every command runs over there.

The first investigation step reads the tail of the application log, since the newest entries are the relevant ones:

$ tail -n 2 /var/log/app.log
ERROR payment timeout
INFO retry scheduled

The flag can also be written without a space, as tail -n2, and both spellings are common. A payment timeout is worth quantifying, so grep -c counts how many times an error has occurred:

$ grep -c ERROR /var/log/app.log
14

Fourteen error lines is a real pattern rather than a one-off. With the investigation finished, exit closes the connection and returns the prompt to the local machine:

$ exit
Connection to example.com closed.

Installing software: package managers

On Linux you don't download installers from websites. A package manager fetches, installs, and updates software from a trusted catalog. On Debian/Ubuntu it's apt:

sudo apt update        # refresh the catalog
sudo apt install htop  # install a program

Two notes:

• sudo runs one command as the administrator (root). Installing system software needs it. With great power: sudo + rm -rf is the most dangerous combo in computing.
• Other systems, same idea: dnf (Fedora), pacman (Arch), brew (macOS), and language-specific ones you'll meet later like npm and pip.

After ssh admin@files.example.com succeeds, running ls shows the files in admin's home directory on files.example.com, not anything on your own machine.

Once the connection is established, every command runs on the remote machine. The prompt is remote, the working directory is remote and starts at that user's home directory, and ls reads the remote filesystem. Making that mental switch, and staying aware of which machine a command is about to run on, is the whole trick to server work.