It is now very nearly impossible to install a headless Pi

The key phrase here is "for remote access".

Yep the key(s) for remote access should not be the keys for local access. Ideally they only get you onto a gateway machine from which you access the rest by passwords or keys as you choose.

Some time back I decided this was too much hassle and set up a VPN for outside access, now all I have to worry about are the VPN keys.

Keys with a passphrase cover 'something you have' as well as 'something you know', which is two of the three factors (the other being 'something you are', ie biometrics).

Passwords are just 'something you know', ie once the password is stolen anyone can reuse it. For example passwords can be keylogged or phished, while keys can't be (the phishing site doesn't get your private key and can't replaying the transaction).

Unlike the web, SSH uses host keys to reduce the risk of phishing but do you check the host key the first time you connect? Plus keylogging is a real concern - there are cracked SSH daemons which record the passwords and send them to attackers.

If that is a concern, don't unlock your keys until you need to use them. Desktop environments often run an ssh-agent to hold your keys for you so you only need type the passphrase once per login/time period, but you can disable that behaviour. Plus you can use different keys for different purposes - eg a work key and a home key, so you don't unlock your work key unless you're doing work stuff.

Asking for the passphrase is no more complex than asking for a password, surely?

Even if you change nothing on the server end, it's still good to use keys where you can. If you never send the password there's nothing to keylog or phish. You could even unset your password so password auth will never succeed. But it's only a one line change in /etc/ssh/sshd_config to disable password auth altogether.

Theo

If an attacker can just walk up to your computer and run commands on it then they will install a keylogger and they will have any passwords you use next time you type them.

There are things you can do about this (screen lock, full disk encryption, etc) but your choices may depend on the nature of the threat. e.g. a dishonest cleaner could be deterred by a screen lock, but an abusive partner might respond with violence to any visible security measures.

Screen lock really should be a minimum consideration. Easy to do and good enough for most purposes, fingerprint unlock is convenient if available.

Things are serious when the threat surface includes your skin!

A one liner to disable password auth, works on Ubuntu and Raspberry Pi OS:

echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-passwordauth.conf ; sudo service ssh reload

It will work on just about any unixish system with sshd.

OK, since I'm more worried about people breaking **into** my home desktop machine rather than the security of all the remotes 'out there' that's exactly what I do, use a gateway for access. Well, actually two gateways so that if one fails I can still use the other. The home firewall is set up to all ssh connections only from two IP addresses.

All the remote systems I connect to from my home machine (or my laptop) are of little conesequence security wise. One for example is a Beaglebone Black monitoring the battery voltages on my boat.

I've often looked at openVpn but always decided it was far more hassle than using ssh! :-) Admittedly I do 99% of my computing at the command line so an ssh connection is all I ever want.

I don't disagreee with what you're saying but there's a load of configuration to do it all if, as is often the case, I'm rebuilding a Raspberry Pi for example.

"If you never send the password there's nothing to keylog or phish" Ay? If there's a keylogger on your system it doesn't care whether you're typing a password or a key. If it's logging what's sent over the wire then it's encrypted.

You **have** to start with password authentication so it's inevitably there when you start with your headless Pi. Everything more to move to one key per remote system is extra hassle which I have to repeat when I rebuild the Pi (which can be quite frequently, e.g. two or three times in a week).

So generate key (OK, that's only once per physical system), copy the key to the remote using ssh-copy-id. Then go to the remote and edit /etc/ssh/sshd_config, then reboot and check it all works. Not a load of work but enough to be a bit of a pain, plus I like to record configuration changes (like the sshd_config one).

That requires a knowledgeable attacker, just connection to a remote doesn't.

Quite.

However this is all quite academic really. It's security the other way about (**into** my home system) that really matters.

It depends on having this line at the top of your /etc/ssh/sshd_config:

Include /etc/ssh/sshd_config.d/*.conf

otherwise the folder sshd_config.d would be ignored. I know Ubuntu and Raspbian ship with that line in the default config (after ~2018), but couldn't speak for other distros.

Theo

Does that cover the RPi OS? The article I found (Nov. 2021) says

Included within its scope are a range of devices, from smartphones, routers, security cameras, games consoles, home speakers and internet-enabled white goods and toys.

But it does not include vehicles, smart meters and medical devices. Desktop and laptop computers are also not in its remit.

How long ago was that?

Brilliant.

On your machine:

ssh-copy-id pi@raspberrypi

On the Pi: echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-passwordauth.conf ; sudo service ssh reload

That's it. Two lines.

The keylogger is often in a compromised SSH daemon on the server, rather than in your machine. You connect to the server, it sees your password as you type it, it records your password and tries to login to other machines using it.

With keys, you never send the private key or passphrase over the connection. You tell your SSH client which key to use (or it tries several). The SSH client asks you for the passphrase to unlock the key (which is happening locally). You tell teh server which key you're using and it checks your authorized_keys for that public key.

The site sends you a challenge based on the public key, you compose a response to your challenge using the private key, you send the response. If the server can decrypt the response you are in possession of the private key and the server proceeds to generate keys for this session.

If the keylogger is on your machine, it can get the passphrase but it doesn't get the private key unless it is specifically designed for attacking ssh and can read your private keys. eg you might see the following in the keylog:

ssh snipped-for-privacy@server.bigcorp.com abr@cad4bra ls

and it's clear that abr@cad4bra is your password. If that was your passphrase it wouldn't help attack anyone.

You don't have to start with password auth. rpi-imager will allow you to install a public key into the Pi so you can SSH directly using keys. It will also remember your settings so every time you flash a Pi, it gets your keys automatically.

etckeeper will keep track of changes to /etc in a git repo

If you want to do this to a lot of machines, it's worth learning Ansible as it'll keep your fleet of machines in sync. Just write an ansible recipe and it will ensure it is applied (and only once) across all your machines.

Theo

The Act doesn't talk about 'smartphones, routers, cameras' etc - it just has 'internet-connectable products' and 'network-connectable products'. eg your wifi cloud-controlled smart plug is an internet connectable product while a Zigbee one isn't internet-connectable but is network-connectable. Smart meters are network-connectable but not internet-connectable.

Theo

Then their *adapted* version of software will have its own username and password .

A raspberry pi does not come equipped with even an operating system

I'm sure you'll be happy to argue that with m'learned friends. I'm sure you won't mind handing over "4% of the person’s qualifying worldwide revenue for the [corporate] person’s most recent complete accounting period." if found to be in breach, plus damages from everyone downstream who sues you.

Theo

I laughed when the movie WarGames showed the protagonist sitting outside the principal's office, sliding out the writing leaf on the desk on which a terminal sat, to reveal a piece of paper with the password written on it. It was the most realistic part of the movie.

And even GUI applications that don't rely on lots of animation (e.g. Thunderbird for e-mail) work quite well with ssh -X.