Chapter 5: Security
Security, passwords, RSA keys, puttygen
And now for the subject that has been ominously hanging in the air, like a rusty battleaxe - security, passwords, RSA keys, etc.. When you flash the sd card with raspbian (more about it later) and connect through putty for the first time- all is simple: login as user pi and the password is raspberry. Why can't we keep it this way? Why do we need all those padlocks, firewalls, landmines, bazookas, etc? Why can't people just trust one another and be good?
Hi Mark and Jacek,
It's hard to make a connection work with puTTY generating an RSA key; puTTYgen uses a different format. Here's what works:
Create a key on the target Linux machine and send the private portion to the Windows user
On Windows, use puTTYgen to convert the key
Use the converted key in puTTY
I enclose the key for conversion; more separately.
And separately, in another mail, Francis sent me a file that contained something like this (it's not the same key, so don't even think about it, you evil hacker, you):
-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAABJQAAAQEAxqIqWUz3WEj5mWuH7MneqY8XpoWDOCzP3Atd
35yNWTdPyL9M+bujPo223VDgxmET8Fm0H+vLYus/X8Bv+Z9us0UVHiBVPZebFTGD
fHH0y6+1MNnpv/nepqioWKAAui+0Ij7KMo+v15sXFeHkCkh4oJf1R2oIkn8ft8bU
ybGq/sXhneonxfzepU54rRhOqsYSpxxG2nCCITxA2R+nbnpFyR+69VovZIc/M51F
SuTfI8u/YGFYA+BHHR60W6ycbFy3UXPbCygb3+CSLLRIwzDR+1/Jf6NXWIFHYNaE
4tHLimhqOIsztKEfSaSqRThK+wMrh1NZBvsNuljdJnEfMdvl1Q==
AAABACWUTTN9Q40+PQ8wBPVyTLhLgQPUEegIeloP/QDKl0g65ZSukgW7txmsG61U
fY1QouhIUoKUZL+v9zug8pcCfLoh05AT9HNvtY5jUDojZan+pb0iTtFK8sWVh6IQ
btcdyCInjgmQzj2MC0lUP+ZFD+cH/fjBCIprE9apE4AasaXSE4yeCdSGYdM9TtFE
j3wh7fpdlLggSo52jul1e8G/ldM/cimFI4tsy1FMqmzecOdporXN9347fNg54GjA
Qj6peYK33y8fDczcp4wdzKLSokHt8kQ8ftvc46b1Pcixguy2g5z25hfbHXJQQFzS
/jbkhnUXEVq7LkSibAAjPBiRhG0AAACBAOuKwWVC0yZouCjKGV8UiNW3wmndo2jT
FoUpn1hifsipAsYpJjmPGp0nbEkVwky5ASw4xgCWhCkp1HpBdGpcHtyjcThHMpxU
eBTeX0xUs/6cXLWEMWJTfiFWo5lQ+7QVElCl6Wb5Csli9K7zoYoCI/70vdm3Ycrz
aQiFdZnJt9QFAAAAgQDX4sDXshpFclJBkN2wBhwuetjveLSzytejuO7A50/3el/i
gwaDGQkBp5vAh/iGyC6AQhGEZGrTMzzhFRtmMr4PRDa973XtdSNQ125VEdpVJxlc
ksR7DSpyvEc3SHT1trX0MGQxGOuVrwfLsBbu+0vTlWS13bvggLni6WXaCtnDkQAA
AIEAmnQMSm4tlhJdxXM0iqBeRkelHgs8GmSstPw8W6/Js7A6Xtgdnr5CGdMyuhj9
i00KqRDgmX5X9UDLGFdWtl15WJPgpLeZteMV8TkYAiVvsg6Afrs1rrKTj/Bqjpf4
67BM/aVZp+r4qdfZPNEhj8wxqO3wr+lkZ6bJaq9a+AcOv4U=
-----END RSA PRIVATE KEY-----
And before he sent it, he went into my RPI (ssh dola, etc.) and created a so called 'pair of RSA keys'. I have never done it myself but Google says (https://www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md) he might have used somefing like: ssh-keygen -t rsa -C csa@dola
which created two files: id_rsa and id_rsa.pub (the default directory for them is ~/.ssh). They are called private and public key respectively. And you have to have the public key on your laptop to connect to RPI. But here things get a little complicated as Francis explains in the mail: Create a key on the target Linux machine (dola in this case) and send the private portion to the Windows user (that would be me, always wanted to have a Mac, shame- I can hear the disgust: ' this Jacek is a Windows user, ugh, bleh'). So instead of sending me the public key (the usual method), Francis is sending the PRIVATE key from which I am to generate the public key, using puttygen. When you have the key from Francis on your laptop (put it in a directory, anywhere)- you have to do two more things. First, download a program called puttygen (for ex.: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) and use it to make the public key. Here is how. Run putty gen:
Click Load (and load the file Francis sent you) and then choose 'Save public key' (PUBLIC, not private)- any directory, avoid desktop as I did, because later on when you want to do some spring cleaning and move it somewhere you will have to change the setting in putty as well. Anyway the first task is done - we generated the public key and have it on our laptop. Now close the puttygen window (a window- ick, bleh, yuck - I wonder what mac users call those things). Now what we need is just to tell putty where to look for the public key we have just generated. So this is where you do it in putty:
In my case, the key is called key1.ppk (the name does not matter but choose a more informative one, like 'my key to dola', etc.) and it sits on my desktop. And now, finally, when you use putty, your RPI will let you in.
So with those random RSA passwords (keys) that are each 7 pages long one would think the system is pretty secure. But Francis is still not quite satisfied with the security. I remember him using the phrase 'impeccably robust' (yes, that's another of my private names I call him, but don't tell anyone) in one of the mails.
sshd_config - security settings
Dear Jacek,
To improve security, we generally disable password login through ssh. Are you using passwords to log into vila via ssh? On dola, password login through ssh has already been disabled:
PasswordAuthentication no (in /etc/ssh/sshd_config -- that's the file that controls ssh access to the machine)
We also add a list of allowed users -- that's been done on dola and now also on vila. The main purpose of this is to make user user pi is blocked -- that's the default user on any RPi, and the system assumes in multiple places that it continues to exist. However, we don't need to allow remote access to user pi.
Since both machines are behind a firewall (on a local network), the only access route is through the tunnels. However, in theory, any user on cartago could try to log into dola -- unlikely but currently possible. There's also a tunnel to redhen3rpi at CWRU, and users on that machine can also see the tunnel to dola -- again, these are all trusted users, but we still want just-in-case security by turning off passwords and listing allowed users.
And now there's an echo in my head. It keeps repeating:
but we still want just-in-case security by turning off passwords and listing allowed users
but we still want just-in-case security by turning off passwords and listing allowed users
but we still want just-in-case security by turning off passwords and listing allowed users
but we still want just-in-case security
but we still want just-in-case security, etc.
Oh yes - what we need is 'impeccably robust' and 'careful discipline'. Who is this Francis (I keep asking in a loop)? I've already considered several possibilities in other chapters (a hacker, a saint, a contract killer, etc.) but now I think he must be a Shaolin monk and he looks like this:
So let's have a look inside the file Francis mentioned. Issue: cat /etc/ssh/sshd_config (on dola). We find, for example:
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
# Red Hen users only
AllowUsers root csa jacek mark
So this is how Francis did it. if your name is not jacek of mark or csa, etc., you will not get in (even if you stole the rsa keys). And passwords will not help you either (disabled). This is not a capture station anymore - it's FORT KNOX, Kentucky.
Close unneeded ports
You can make the capture station more secure by checking its open ports and closing those you don't need.
To check the local ports, issue as user root:
nmap localhost
Port 22 is needed, and sometimes you may want port 25 for e-mail, but the others should be closed.
Now, port 631 is the Unix print system; you can disable it using
update-rc.d -f cups remove
Port 111 is used by the network file server; disable it using
systemctl disable rpcbind
Keeping open ports to a minimum is a simple rule of thumb.
Epilogue
This is the end of the Ultimate Guide - for now. Because I know that in the mailbox, and very soon (today), I will find more Red Hen mails - new ideas, new challenges, new puzzles. And, in a while, I will sit down to write the next chapter, and the next. Thank you for reading. You'll hear from me soon.
Jacek, Cpt. Dola, Cpt. Dummy, Polish Red Hen (jacekifa@gmail.com)