There is something to be said for not giving too much away. Whether that’s actually not giving too much away related or not. I’ve decided that
the perfect use-case for a Raspberry Pi Zero W (wireless) is a jump server. A jump server is a device that is dedicated to providing some
public facing general access capability. There are some companies like Citrix that specialize in Jump Servers… but in this case it’s a
homebrew. (and there are still some challenges)
- first of all the Pi Zero is small, slow, and has limited thruput. And that’s the point. I do not want to be able to serve more than just one or two
terminal session. (maybe 4). But if a hacker gets in I want to feel the force.
- I can install the OS (raspbian) as console only, skipping the GUI limiting the idle time heat.
- I can still install a USB or wireless keyboard, or go bluetooth for the purpose of setup
- the amount of live accessories is minimal if anything more than just power
- I can velcro it just about anywhere
- out of the box the OS seems to be locked down although there is still some concern because the device and the OS are hobby oriented.
- and while I’ve purchased 2, so I have a backup, cost and availability are real considerations. Given that I’m protecting a VMware server maybe this would be better as a VM?
Well it’s not free and that first config is going to require some accessories
- Raspberry Pi Zero W
- USB power either a brick or a USB-A to Micro-USB and a PD source
- Micro SD card - at least 8GB
- Pi Zero case (if you care)
- HDMI adapter
- if you elect to skip the ‘W’ then you’ll need a USB to Eth dongle
- keyboard (no mouse)
- heat sink is probably a good idea
- and download the Raspbian image (currently buster)
- since I’m planning 3FA (three factor authentication) you’ll also need a smartphone.
NOTE: these devices are ARM based and so you need to keep that in mind as not all apps are going to be available and if you are going to build your own apps
for these devices that is part of the calculation.
This is in general terms and meant to be more of a checklist. The challenge here is that, for the moment, the kind of automation I like may not be possible. At least
the initial installation requires manual bootstrapping.
There may be some instrctions for bootstrapping a Pi-W to a wireless network headless but I prefer to witness the steps. Also some weirdness is the display and possibly
the keyboard appear to NOT be plug n play. Lastly, if you plan to use a bluetooth keyboard you’ll still need a regular keyboard until the BT is installed and congfigured.
- on a separate machine … download Raspbian and copy it to the Micro SD.
- unbox and assemble (note this is not a build) the Pi; including the insertion of the Micro SD
- apply power to the board. Note that on the Pi you will not see the power indicator until the OS is actually bootstrapped
- during tha first boot Rapbian will resize the partition to the full size of the media
- at the first login prompt you’ll want to login. (pi/raspberry)
The initial config
Now you want to make some basic config changes by launching:
- change the
pi user password to something safer
- set the hostname
- set your locale
- choose a keyboard layout
- set your timezone
- your ntp (network time protocol) should be running/enabled but if not turn it on. (a service on your network)
- set the SSID and Password (you’ll be prompted for your country; if you make a mistake it’s in the locale menu)
- enable SSHD
- if bluetooth keyboards are your thing then install and configure it. Keep in mind it requires a few reboots. In my first device I installed BT but since these are network
devices I will eventually remote it.
- update - this is a different update from the apt-get. so do it here.
At this point you should be able to
ssh into the device from your usual console/terminal. You might even relocate it to someplace other than your desk.
3FA - three factor authentication
I think I can make a case for 4FA if you make the
username as complex as the password. For example
pi should not be accessable for start. And
john is probably also not
a good name.
- google authentication
- ssh cred
You really do not need much because you want this machine to be a passthru.
- iftop and pftop are probably some good tools.
- install google authenticator (and on your phone)
- in my case I like
vim even though there are other tools available
- add G.A. to PAM configuration
- update SSH config (always as for password)
- create youself an admin user and add it to sudo and you may want to experiment with G.A.
- if you are planning to mount some USB drives you might need some extra tools for ntfs or hfs. So
apt-get install hdparm ntfs-3g hfsplus hfsprogs. A reboot might be required.
- create a jump user
- create a GA key
- configure you GA on smartphone
- create a unique
ssh file-pair for each host you plan to jump to
- in the
.ssh/authorized_keys file paste the .pub file and prepend `command="ssh user@target”
- generate a key for the jump user
- paste the pub file in the authorized_keys file on the target machine user account
Now when the user accesss the jump server with the
-i creds, uid, pwd, and veriftcode… the console will be attached to the target machine.
(the connection and network traffic is being routed by the ssh cert.)
- Phone home - getting to machines behine a firewall… typically IoT devices
- dynamic passwords - change the user account password similar to GA.
- emails creds - consider some mechanism such that clicking on a website produces an email like a
forgot password and then filling in forms.
- I installed a couple of other projects manually. freedt, jailkit, fossil-scm, golang, jimsh, tcl
- There is a special hint to regenerate the OpenSSH Hosy Keys
regenerate Host Keys
on the server regen the certs
/bin/rm -v /etc/ssh/ssh_host_*
then on the client delete the fingerprint of the known host and regen
ssh-keygen -R <host>
I’m not sure you’re ever finished. At some point there is a realization that Micro SD cards have a limited lifespan. Also
you want to know if there are intrusions and whether people are attempting to hack. And since this is a jump server
you do not want the user to be able to access the admin (not root) account from the public side.
- If you think you can make a backup or automate this then great.
- at the very least make some good notes
- lastly do not create any back doors or you’ll likely use them and expose yourself.
- if this is a light’s out operation???
- logging and log rotation (drive full)
- system updates and upgrades:
sudo apt update && sudo apt upgrade -y
- deactivating users that leave the org
One pain point here is that developing and testing this configuration is a pain. My phone has to be close by and I’m constantly typing in my creds. Just keep in mind that
there is a payoff. Also, when configuring Google Authenticator you may have an urge to make it slightly less secure for some convenience. I urge you not to. Just
think a little more like Corp. IT.
haha… don’t forget to pick a public port and route that traffic from the public IP to the jump server. Keep in mind the public port number may or may not be it’s
defined number… instead of 22 choose 2222. Granted this is an obvious choice to those that understand but the idea is the same.