SSH remote access¶

Practical 6.1 ssh-remote-access-annex.pdf · PDF

A real server lives in a locked room, or in a datacentre in another city. Nobody walks up to it with a keyboard. So how do you install a program on it, or read its logs, or fix a typo in its configuration?

You log in through the network, with SSH. You met SSH in Unit 3: it encrypts the whole conversation, so nobody in the middle can read your password. But here is the uncomfortable truth: any server on the Internet receives login attempts all day long, with user names like root, admin and test, from addresses all over the world. Programs try every address on the Internet with lists of common passwords. SSH encrypts the conversation. It does not make a bad password good.

The padlock and the key¶

SSH (Secure Shell) is a protocol to get a shell on another machine, encrypted, on TCP port 22.

Instead of a password, SSH can use a key pair: two files that only work together. Think of a padlock and its metal key.

• The private key is the metal key. It never leaves your computer.
• The public key is the padlock. You can give copies to anyone.
• You hang your padlock on the server: one line in the file ~/.ssh/authorized_keys of your account there.
• To log in, the server asks you to prove you hold the key that fits that padlock. Your computer does the proof with the private key, and the key itself is never sent.

That proof is a simplification of a digital signature: a mathematical seal that only the private key can make and anyone with the public key can check.

flowchart LR
    subgraph CLIENT ["deb-lab (your laptop)"]
        PRIV["<b>Private key</b><br>id_ed25519<br>the metal key"]
    end
    subgraph SERVER ["ubu-srv"]
        PUB["<b>authorized_keys</b><br>a copy of your public key<br>the padlock on the door"]
    end
    SERVER -->|"1. prove you have the key"| CLIENT
    PRIV -->|"2. a signature, never the key"| PUB
    PUB -->|"3. it fits: come in"| CLIENT

Ed25519¶

The kind of key you will make is Ed25519, published in 2011 by Daniel J. Bernstein and four colleagues, and part of OpenSSH since version 6.5 (January 2014). The whole public key fits in one short line:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICc5C37KWQFL/Vk9C4Vo4dhL5uujFkTsySgerRQTKfV5 marta@deb-lab

Three parts: the type, the key, and a comment so you remember which device it belongs to.

The first connection: the fingerprint¶

The very first time you connect to a server, ssh shows you a string like SHA256:... and asks if you want to continue. That string is the server's fingerprint: a short summary of the server's own key, its identity card.

It is the only moment you can catch an impostor pretending to be your server. So compare before you say yes. On the server's console (the virt-manager window):

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

Then, from deb-lab, connect with ssh marta@ubu-srv and check that the fingerprint it shows is the same. Only then type yes. The client remembers it in ~/.ssh/known_hosts and will warn you loudly if it ever changes.

Make your key pair and hang the padlock¶

On the client (deb-lab), not on the server:

$ ssh-keygen -t ed25519 -C "marta@deb-lab"
Generating public/private ed25519 key pair.
Your identification has been saved in /home/marta/.ssh/id_ed25519
Your public key has been saved in /home/marta/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:hGGGUivesqVqFM21bsLdZaLt0oKpvlzIES035W5YoBc marta@deb-lab

$ ls -l ~/.ssh
-rw------- 1 marta marta 399 Oct  5 20:49 id_ed25519
-rw-r--r-- 1 marta marta  95 Oct  5 20:49 id_ed25519.pub

Look at the permissions: the private key is -rw------- (600), only the owner reads it. The .pub is readable by everyone, and that is correct. When it asks, type a passphrase: without one, whoever steals your laptop gets your server too.

Now copy the padlock to the server:

$ ssh-copy-id marta@ubu-srv
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'marta@ubu-srv'"

ssh-copy-id asks for the server password one last time, and appends your public key to ~/.ssh/authorized_keys on the server. From now on, the login asks for the passphrase of your key (your desktop usually remembers it for the session), not for the server password.

Working comfortably: config and scp¶

How many things do you type to connect? A user, a name, sometimes a port and a key file. Write them once in ~/.ssh/config:

Host srv
    HostName ubu-srv
    User marta
    IdentityFile ~/.ssh/id_ed25519

chmod 600 ~/.ssh/config
ssh srv hostname

Now ssh srv is enough, and every tool that uses SSH understands srv. If it complains Bad owner or permissions on ~/.ssh/config, the chmod 600 is missing.

scp (secure copy) is cp with a machine name in front of one of the paths. The colon is what makes it remote.

Note that keys log you in; they do not make you root. ssh srv "sudo apt update" still asks for sudo's password.

Locking the door without locking yourself out¶

Your key works. But the server still accepts passwords, so the guessing programs can keep trying. Time to close that door.

Do not edit the big /etc/ssh/sshd_config. Its first active line is Include /etc/ssh/sshd_config.d/*.conf: the small files in that folder are read first, and for each option the first value found wins. Create /etc/ssh/sshd_config.d/10-tramuntana.conf:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

The 10- matters: some installations already have a 50-cloud-init.conf that says PasswordAuthentication yes, and 10 is read before 50. PermitRootLogin no does not mean nobody can be root: you log in as yourself and use sudo, so the log says who did it.

Three safety steps¶

1. Keep one SSH session open in a second terminal, and do not close it until the end. Sessions that are open survive the restart.

2. Test the file before restarting. sudo sshd -t prints nothing when the file is right. With a typo:

   $ sudo sshd -t
   /etc/ssh/sshd_config.d/20-typo.conf: line 1: Bad configuration option: PasswordAuthentification
   /etc/ssh/sshd_config.d/20-typo.conf: terminating, 1 bad configuration options
   

3. Restart, then test from a new terminal. If the new login fails, the old session is still there to fix it.

sudo sshd -t
sudo systemctl restart ssh

On a server in another city there is no console to walk to. If you close your only session and the new configuration is wrong, the server is gone. One session stays open. Always.

Check the result:

$ sudo sshd -T | grep -E "^(passwordauthentication|permitrootlogin)"
permitrootlogin no
passwordauthentication no

$ ssh -o PubkeyAuthentication=no srv
marta@ubu-srv: Permission denied (publickey).

Without the key, there is no password question at all: the list in brackets is what the server still accepts. With the key, ssh srv still gets in.

Read the log¶

Every refused login leaves a trace. On the server:

sudo journalctl -u ssh -n 20

You will find your refused attempt, with the client's address (192.168.122.x) and the time. On Ubuntu the service is called ssh, not sshd. On a server facing the Internet, journalctl -u ssh | grep "Failed password" shows the guessing programs at work.

The Practical 6.1 sheet ends with a real server on the Internet: you paste your public key in Classroom, the teacher hangs it on the server, and you log in without ever having a password for it.

Key takeaways¶

• SSH gives you an encrypted shell on another machine (port 22). Encryption does not stop password guessing.
• A key pair is a padlock (public key, in authorized_keys on the server) and a metal key (private key, id_ed25519, never leaves the client, protected by a passphrase).
• Check the server's fingerprint on the first connection; known_hosts remembers it.
• ssh-keygen makes the pair, ssh-copy-id installs it, ~/.ssh/config gives a short name, scp copies files (the colon makes it remote).
• Turn off PasswordAuthentication and PermitRootLogin in a drop-in file, test with sshd -t, and keep one session open while you restart.

Quick check¶

SSH gives you a shell. But what if the thing you must fix is a window with a button? Next: Remote desktop.