INTL 3:770/1 3:770/3
REPLYADDR theom+news@chiark.greenend.org.uk
REPLYTO 3:770/3.0 UUCP
MSGID: c9416ffa
REPLY: 3cca3c1e
PID: SoupGate-Win32 v1.05
Chris Green wrote:
> 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.
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.
> "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.
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 chris@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 **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).
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.
> 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).
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
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
SEEN-BY: 10/0 1 15/0 90/1 103/705 105/81 106/201 128/260 129/305 135/225
SEEN-BY: 153/757 7715 218/0 1 601 700 840 870 930 220/70 221/1 6 226/17
SEEN-BY: 226/30 100 227/114 229/110 112 113 200 206 307 317 400 426
SEEN-BY: 229/428 470 550 616 664 700 240/1120 266/512 267/800 282/1038
SEEN-BY: 291/111 292/854 301/1 113 812 310/31 320/219 322/757 335/364
SEEN-BY: 341/66 342/200 396/45 460/58 633/280 712/848 770/1 3 100
SEEN-BY: 770/330 340 772/210 220 230 5020/400 1042 5058/104 5075/35
PATH: 770/3 1 218/840 221/6 301/1 218/700 229/426
|
