Richard Bucker

Raspberry Pi Config - as a jump server

Posted at — Feb 3, 2020


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)


Well it’s not free and that first config is going to require some accessories

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.

The initial config

Now you want to make some basic config changes by launching: sudo raspi-config

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 root and pi should not be accessable for start. And john is probably also not a good name.

$ sudo apt install libpam-google-authenticator
$ google-authenticator

Install some extra tools

You really do not need much because you want this machine to be a passthru.


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

Other topics

regenerate Host Keys

on the server regen the certs

/bin/rm -v /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
/etc/init.d/ssh restart

then on the client delete the fingerprint of the known host and regen

ssh-keygen -R <host>
ssh user@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.


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.