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):























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 ( he might have used somefing like: ssh-keygen -t rsa -C csa@dola

which created two files: id_rsa and (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.: 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.


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 (