Mails from Francis - Chapter 5


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.

bash script (5)

I know it's a bit messy (I am not a Shaolin monk) but let's change the subject to something lighter, (soft-ier)- bash - and let's have a look at one of the hundreds of long mails in which Francis  was trying to teach me something (and I am forever in his debt for that):
Dear Jacek,
This is excellent -- since you've added $CC as a variable in the script, let's go all the way and turn it into a multi-country grabbing script, as follows:
# Country code
if [ -z "$1" ]
  then echo -e "\n\tMissing country code. Please see $SCRIPT -h.\n" ; exit
  else CC=$1
fi
Now, $1 is the first value a user adds when running the script; we can have several.
The form 
      if [ -z "$1" ] 
is a way to invoke the "test" function in bash -- 
      test -z "$1"
asks, "is the length of string $1 zero?"  So if the length is zero, the user has forgotten to enter a country code and we exit with a "Missing country code" message and a prompt to ask for help.
So we might add a help screen first along these lines -- you can look at any script in /usr/local/bin for models:
SCRIPT=`basename $0`
# Help screen
if [ "$1" = "-h" -o "$1" = "--help" -o "$1" = "help" ]
 then echo -e "\n\t$SCRIPT"
  echo -e "\n\tGrab tv schedules using WebGrab+Plus."
  echo -e "\n\tSyntax:"
  echo -e "\n\t\t$SCRIPT <country code>"
  echo -e "\n\tExample:"
  echo -e "\n\t\t$SCRIPT cz"
  echo -e "\n\tCurrently valid choices are cz, pl, and ru."
  echo -e "\n\tEach country has its own configuration file in ~/wg++/<country code>.config.xml"
  echo -e "\tAdd new countries by adding configuration files."
  echo -e "\tUse two-letter ISO country codes."
  echo -e "\n\tThis script is typically run daily as a cront job.\n"
   exit
fi
The first line gets the name of the current script, so we don't have to repeat it in the help screen, or change it if it changes.
The echo command understands /n for newline and /t for tab is you give it the -e switch.
The help screen understands -h and -help and help.
To debug this you could add, after the Country code 
# Debug
echo -e "CC is $CC" ; exit
For further refinements, you might consider adding a case box for country adjectives -- for a model, see scheduler-DVB-06.sh (case $NWK in ...). 
I also recommend you add a header with a to do list and a changelog; see xmltv-download-02.sh for a model -- I suggest including installation dependencies, which will allow the script to be installed more easily in other locations:
#!/bin/bash
#
# Grab the tv schedule using WebGrab+Plus
#
# Written by Jacek Wozny 7 October 2016
#
# Dependencies:
#
#  * WebGrab+Plus
#  * mono-runtime libmono-system-data4.0-cil libmono-system-web4.0-cil (from Xamarin at http://www.mono-project.com)
#
# To do:
#
#  * Add a case box for country adjectives
#
# Changelog:
#
#       2016-10-09 Country code as user variable
#       2016-10-08 Separate scripts for each country
#
# -----------------------------------------------------------------------------

Adding $CC as a variable is the start of a whole new adventure. Note that we still keep separate configuration files, but it looks like that's all we need.
Also, I suggest we output the files to a different location, let's say /home/csa/xmltv. This will make it slightly simpler to fetch them from dola and rusalka, since this is the directory they will end up in on those machines. 
Francis

Do you need my comment for the above? No, because all is patiently, clearly explained in a well organized (Francis's) manner. And after reading this I begin to lean again towards 'the saint' theory (if you read the other chapters, you'll know what I mean). 

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)


Comments