SSH to Other Machines

What SSH does

SSH, the Secure Shell, gives you a command line on another computer, encrypted from end to end. You’ve already used it to talk to GitHub (Git course, module 4). On Linux it’s how you run a machine with no screen, like a home server, from your laptop’s terminal: once you’re logged in, it’s an ordinary shell on the other machine.

OpenSSH provides both sides: the client, ssh, and the server, sshd, which listens for connections on port 22 ¹. It replaced older tools like telnet that sent passwords in plain text ¹.

The server side

The client is installed on Ubuntu already. On the machine you want to reach:

me@garden-server:~$ sudo apt install openssh-server
me@garden-server:~$ systemctl status ssh

That’s all it takes to accept logins ¹. Its service is called ssh on Ubuntu.

The first connection

From the laptop, give your user name on the server and its name or address:

me@garden-laptop:~$ ssh me@garden-server.local

The first time, ssh shows the server’s host key fingerprint and asks whether to trust it ². This is the same check as GitHub’s fingerprint in the Git course: it proves you’ve reached the machine you meant to. To check, run this on the server and compare ²:

me@garden-server:~$ ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

Answer yes when they match. ssh records the key in ~/.ssh/known_hosts and checks it on every connection after that ²; if it ever changes, ssh refuses with a loud warning, because that’s what someone intercepting the connection would look like. (Reinstalling the server also changes it, legitimately.)

Then type your password for the server, and you’re in. exit or Ctrl-D comes back.

Keys instead of passwords

You already have a key pair from the Git course: the private key in ~/.ssh/id_ed25519, the public one in ~/.ssh/id_ed25519.pub. Ubuntu’s docs recommend Ed25519 keys too ¹. To let it log you in, its public half goes into ~/.ssh/authorized_keys on the server, the list of keys allowed to log in as you ². One command does it:

me@garden-laptop:~$ ssh-copy-id me@garden-server.local

ssh-copy-id logs in once with your password and appends your public key ³. Next time, ssh me@garden-server.local uses the key: no password, just the key’s passphrase, which ssh-agent remembers for the session.

If your public keys are already on GitHub, the server can fetch them itself: ssh-import-id gh:your-github-name ¹.

If key logins don’t work, authorized_keys must be writable only by you (chmod go-w ~/.ssh/authorized_keys fixes the usual problem), and the server’s log says why: sudo journalctl -fu ssh while you try ¹.

Short names in ~/.ssh/config

Typing me@garden-server.local gets old. ~/.ssh/config on the laptop gives hosts short names and default settings ⁴:

Host server
    HostName garden-server.local
    User me

Now ssh server is enough, and so is scp file server:. Host names the shortcut; HostName is the real name or address; User the login name; Port and IdentityFile set the port and which key to use, if they’re not the defaults ⁴. This file is a good one for your dotfiles, as long as you’re happy for the host names in it to be in the repository.

Running commands and copying files

Give ssh a command and it runs that instead of a login shell, then returns ²:

me@garden-laptop:~$ ssh server 'df -h /'
me@garden-laptop:~$ ssh server 'systemctl --user list-timers'

scp copies files over the same connection, with the same login ⁵. A remote path is host:path:

me@garden-laptop:~$ scp notes.txt server:
me@garden-laptop:~$ scp server:/var/log/dpkg.log .
me@garden-laptop:~$ scp -r Photos/2026 server:photos/

rsync, from the Shell course’s backup script, uses SSH whenever a path has a host: in front, and only sends what changed ⁶:

me@garden-laptop:~$ rsync -av ~/Documents/ server:laptop-documents/

Turning off passwords

Once your key login works, turn password logins off on the server. Then guessing passwords is useless against it, which matters as soon as it’s reachable from anywhere but your own network.

Ubuntu reads extra settings from /etc/ssh/sshd_config.d/*.conf, before the main file, and for most settings the first value wins, so a small file there overrides the defaults and survives updates ¹. Create /etc/ssh/sshd_config.d/50-local.conf with:

PasswordAuthentication no

PasswordAuthentication is yes by default ⁷. (Root can’t log in with a password by default anyway: PermitRootLogin defaults to prohibit-password ⁷.)

Changing SSH settings on a machine you reach only by SSH is how people lock themselves out ¹. So:

1. Test the configuration before restarting: sudo sshd -t checks it and reports errors ^{8 1}.
2. Keep your current session open. Restart with sudo systemctl restart ssh ¹.
3. In a second terminal, log in again. Only when that works, close the first.

To confirm passwords are refused, ssh -o PubkeyAuthentication=no server from the laptop should fail with Permission denied (publickey).

Your turn

So

sudo apt install openssh-server makes a machine reachable by SSH. On the first connection, compare the host key fingerprint with ssh-keygen -l -f on the server; ssh then remembers it in known_hosts. ssh-copy-id (or ssh-import-id gh:you) installs your public key in the server’s authorized_keys, and ~/.ssh/config gives hosts short names. ssh host 'command' runs one command; scp and rsync copy files with host:path. Then set PasswordAuthentication no in /etc/ssh/sshd_config.d/, check with sshd -t, restart ssh, and keep a session open until a new login works.