Hardening SSH on your Ubuntu Server

Hardening SSH on your Ubuntu Server

Secure Shell (SSH) is an amazing cryptographic network protocol, and it undoubtedly helps secure a huge slice of today’s Internet – giving sysadmins robust remote access to their servers, but also so much much more.

I’ve been using SSH on Linux Servers for longer than I can remember. Well, not quite. I do remember those “telnet” days when nobody had a care in the world, and Edward Snowden was a kid playing video games. Or something.

I’ve learned a thing or two about hardening SSH and locking it down, including generating certificates, and using it as a remote proxy in all kinds of ways. Here is a brief brain dump that I hope you enjoy.

General SSH Configuration Tips

Configuration of SSH starts with the sshd_config file.

sudo nano /etc/ssh/sshd_config

Change the Default Port

The first is the “Port 22” default that SSH listens on; I will usually change this to a different number other than the default, or run it on multiple ports depending.

# What ports, IPs and protocols we listen for
#Port 22
Port 2222

If you don’t change the port from 22 you’ll just be subjecting yourself to endless probes and brute-force logins from everywhere. While changing to something else is not guaranteed to stop any of that, in my experience it will reduce it. A lot.

Ensure you’re using Protocol 2 (SSH2)

The second thing to check, particularly if you have an older Linux server is the version of the SSH Protocol – the line “Protocol 2” does that. Ensures you’re using SSH2 which is far superior that earlier versions of the protocol and shouldn’t be an issue today.

Protocol 2

Don’t Permit Root Login

I’m a strong advocate of always connecting to a server using my own account, and if I need superuser access I’ll “sudo” to get it. This means there’s never a valid reason ever to login as the root user.

Unfortunately, some of today’s cloud VPS hosting providers will provide you with a root login straight away. Um, no thanks.

PermitRootLogin no

Turn Off Password Authentication (if using Certificates)

If you’re using certificate based authentication (which I highly recommend – here’s some useful information on that) you’ll want to turn off any kind of password authentication, by locating and modifying the lines below to “no”.

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Restrict to Known Users

Another thing you can do, which I think a lot of people never bother doing, but might be useful, is to restrict SSH access to certain known users on the system. Even with the right password or certificate a user not in this list (if the setting is present) will not be able to login.

AllowUsers john bob alice

Using the “AllowUsers” setting could be vital if your server is hacked and somebody tries to create a backdoor user – at least this will prevent them getting any remote access, and the failed attempts may show up in your log files.

Disabling Potentially Compromised Modulus

There is some conjecture that the NSA (and others?) could intercept TLS and SSH communications by obtaining the shared private key during the “Diffie Helman” key exchange process.

The speculation about this weakness with DHE is potentially feasible. The concern is that there exists the ways and means through supercomputing power to factor the large primes commonly used for DHE.

Here’s one example news story suggesting it’s possible, which led me to researching and discovering some practical hardening tips here that I’ve refined a little further.

You’ll have to edit the moduli file:

nano /etc/ssh/moduli

Comment any lines that have a value less than 2047 shown in the 5th field on each line – and then don’t forget to restart the SSH service.

I’ve also made this SED one-liner below that you can run as root which will comment out the lines mentioned in one hit as well.

sudo cp /etc/ssh/moduli /etc/ssh/moduli.bak
sudo sed -r -e '/[[:space:]](1023|1535)[[:space:]]/ s/^/#/' -i /etc/ssh/moduli

Restarting the SSH Service

If you’re connected to a remote server via SSH already, and you’re editing the sshd_config there is a real risk that you could inadvertently cut yourself off if you get something wrong.

The biggest tip I can give you is to NEVER logout from any existing sessions until after you have verified your new SSH config is working.

systemctl restart sshd

After you have restarted SSH, try a new connection to the server and if successful everything is fine. If you have any problems, you’ll need to go back to your existing logged in session and fix up the sshd_config (check the log files for reasons why if not clear). You’ll then need to repeat and restart the SSH service until you can login with a new session.

I hope these tips help you secure your SSH server, and until next time, stay safe out there.


Huntercoin node on Ubuntu 16.04

Huntercoin node on Ubuntu 16.04

Following on from some recent research into Cryptocurrencies, I’ve been looking at the somewhat unique Huntercoin. It claims to be a so-called “human mine-able” cryptocurrency.

I’m not so much interested at the moment in actually playing what I presume is some kind of online game for mining the coins, as I see there is a core peer-to-peer client that can run on Linux, and I presume is a fork of Bitcoin anyway.

As with many of these emerging altcoin projects, this one too has a very sketchy compile guide, and since my preferred OS is Ubuntu 16.04 LTS Server 64-bit there’s unlikely to be anything else as up to date as what I’m about to leave right here.

Initial requirements

I’m starting with a fresh Ubuntu 16.04 Server running on VMWare hypervisor, in my case a standard 2 x CPU, 2048 Gb RAM, 48 GB HDD spec machine.

Whatever hardware you choose is up to you, if you just run the huntercoind just to keep a full copy of the blockchain and maybe even do some transactions, you’ll get by with any old machine.

I’m not doing any mining here, so I don’t have any advice for running GPU’s or anything like that.

Anyway, my new Ubuntu server is just a straight default install with only OpenSSH added to begin with, and set a static IP address because I’ll be port forwarding from my firewall later, and I do the usual updating things like:

sudo apt-get update && sudo apt-get -y upgrade && sudo reboot

Now to get started…

Step 1. Install required libraries

While getting Huntercoin up and running for the first time, I made careful note of all the required libraries you’ll need for a successful build – here they are:

sudo apt-get install build-essential libssl-dev libboost-all-dev

And there are a couple more, this next one took me a while to find for Ubuntu 16.04 when I kept getting this compile time error:

/usr/bin/ld: cannot find -lgthread-2.0
collect2: error: ld returned 1 exit status
Makefile:118: recipe for target ‘huntercoind’ failed
make: *** [huntercoind] Error 1

This error had me searching high and low for ‘gthread’ and ‘libg’ and all sorts of things, and even ‘libqt4-dev’ (but I hate installing that one because of all the X11 dependencies) until I found this:

sudo apt-get install libglib2.0-dev

This next one is also required, “libdb” which is actually the Berkeley DB library.  When compiling bitcoin-core and other forks of bitcoin this one can be a problem and you need to use the older 4.8 version – but installing this one (which is 5.3 in Ubuntu 16.04) appears to work just fine.  It you are wanting to move any *.dat files between systems though, this might be an issue (I explain more about this in my Namecoin build).

sudo apt-get install libdb++-dev

Step 2. Download the huntercoin source

Now it’s time to fetch (or should I say clone) the latest source from the Github repository.

cd ~
git clone https://github.com/chronokings/huntercoin.git

Because I’m using a dedicated machine only for Huntercoin in this case, I’m not going to bother moving the source to somewhere like /usr/src or /usr/local/src as I know some people like to do.  It just sits in my home folder on this server.

You should end up with something like this.  In the /src folder is where we’ll be building.


Step 3. Compiling huntercoind

You’ve done all the groundwork, now it’s time to build!

cd ~/huntercoin/src

That’s pretty much it, there is not “make install” like you might expect, so to make the shiny new huntercoind binary (mine was version 1.3.01) available I did this.

sudo ln -s ~/huntercoin/src/huntercoind /usr/local/bin/huntercoind

Step 4. Test huntercoind

You should now be able to start the huntercoind in daemon mode with:

huntercoind -daemon

Unlike some other crypto core clients, this one doesn’t seem to mind running without any configuration file at all, and it will happily start up.

You can check the progess of what it’s doing with:

tail -f ~/.huntercoin/debug.log

(Use Ctrl+C to exit it)

Feel free to have a look at some of the other commands you can issue.

huntercoind help

Once it has created the .huntercoin file in your home directory, I would recommend stopping it gracefully and downloading the blockchain in advance to same some time.

huntercoind stop

Step 4. Download blockchain (optional)

Your hundercoind core client is going to take a while once you fire it up as it begins to ask the peer-to-peer network for all the blocks in the blockchain. This process can literally take days.

My up and running Huntercoin client has around 12 GB of blockchain data in the ~/.huntercoin/ folder to give you some idea. Letting your huntercoind client retrieve this in many individual P2P requests is inefficient (but arguably more failsafe from a security point of view if you’re really paranoid).

So, if you want to shortcut this process you can download an archive of the blockchain database in advance from here: http://chain.huntercoin.org/



I can’t speak for the legitimacy of it, so make sure you follow the instructions and check the SHA256 hashes that have also been signed with a PGP key.

Once you have downloaded the zip file, simply unzip all the files into your .huntercoin folder and overwrite any other files.

Step 5. Port forward at your Firewall

If you’re doing this from a standard home gateway/router chances are this has been taken care of via the UPNP protocol, but if not you’ll need to port-forward TCP externally on Port 8398 to the internal IP of your Huntercoin box.

I’ll leave you with the rest, feel free to comment below.  Happy Hunting. Or something.

Building a Namecoin server with Ubuntu 16.04

Building a Namecoin server with Ubuntu 16.04

In what has turned out to be an in-depth look at multiple cryptocurrencies recently, I’ve been having a deeper look into Namecoin.

This research has meant having to spin up test virtual machines and since Ubuntu 16.04 is my server OS of choice (the 64-bit LTS server version) here’s how I’ve setup a Namecoin node.

Your results may vary, and I make no promises or guarantees on the outcome of these steps, other than to say it worked for me.

Initial requirements

You’ll need to start with a freshly installed Ubuntu 16.04 LTS 64-bit server (in my case running on a VMWare hypervisor with 2 x CPU, 2048 Gb RAM, 48 GB HDD; hardware/platform is up to you).

I simply installed it from scratch, creating a user account for myself, changed the IP address to a static configuration (I have instructions for that here) and also did a full update and reboot.

sudo apt-get update && sudo apt-get -y upgrade && sudo reboot

The steps following assume you have SSH’d into the box (or at the console) using your own account.

Although I do have a bad habit of using “sudo -i” to get a root prompt, when it comes to building projects from source code I always stick to using my own account.

Step 1. Install required libraries

There are a bunch of packages you’ll need to install, the most important of which begins with all the essential build tools included in the “build-essential” package.

sudo apt-get install build-essential

Then there are a bunch of other packages you’ll need later on, I compiled this list from trial-and-error the first time I did this.

sudo apt-get install autoconf libtool pkg-config
sudo apt-get install libboost-all-dev libssl-dev libevent-dev

Step 2. Download the namecoin-core

cd ~
git clone https://github.com/namecoin/namecoin-core.git

This will retrieve a clone of the git repository that contains the latest version of the namecoin-core project.

I simply run this from my home folder and it creates a namecoin-core/ folder in my home directory.  I know some people like to put source code into /usr/src and other such places, but since this is a single purpose built test-server I don’t bother.

We’re not going to do anything with this just yet, but you’ll need it in the next step.

Step 3. Getting BerkeleyDB 4.8 libs

This was a stumbling block that I encountered caused due to Ubuntu 16.04 being so new. I kept getting this error during the configuration of the namecoin build.

If you have no version of Berkeley DB installed:

checking for Berkeley DB C++ headers… no
configure: error: libdb_cxx headers missing, Namecoin Core requires this library for wallet functionality (–disable-wallet to disable wallet functionality)

Or if you’ve somehow already installed libdb++-dev (or libdb5.3++-dev) which you’ll need to apt-get remove to proceed further:

checking for Berkeley DB C++ headers… default
configure: error: Found Berkeley DB other than 4.8, required for portable wallets (–with-incompatible-bdb to ignore or –disable-wallet to disable wallet functionality)

Let me quickly explain what this is all about.

Namecoin, like Bitcoin, provides a wallet for your coins. This functionality is provided by storing encryption keys in a special file called “wallet.dat” – which is a Berkeley DB file (a type of file-based database), and in the early days of Bitcoin it was the 4.8 library version that was originally used.

The problem is that Ubuntu 16.04 is created to only provide a package for the Berkeley DB library 5.3 and while this would normally be fine, it means your wallet.dat file would not work on other systems if you were to move it elsewhere.

Once a Berkeley DB file (i.e. wallet.dat in this case) is accessed by a program using a later version of the Berkeley DB library the file being accessed is upgraded automatically – and the file can never be converted back to the previous version. Hence, most wallet.dat files are using 4.8 so we should probably stick to that for peace of mind.

The solution at it turns out isn’t that hard, like most things when you eventually find the correct answer!

wget http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz

If this download doesn’t work, maybe visit the Oracle website and find the link that does.

tar xzvf db-4.8.30.NC.tar.gz
cd db-4.8.30.NC/build_unix/
../dist/configure --enable-cxx
sudo make install

My sincere thanks to the discussion on this Github page for the steps above.

In addition to compiling and installing the Berkeley DB 4.8 lib, I still had issues and had to create the following symbolic links so the headers and lib files could be found. Thanks to the thread here for that.

sudo ln -s /usr/local/BerkeleyDB.4.8 /usr/include/db4.8
sudo ln -s /usr/include/db4.8/include/* /usr/include
sudo ln -s /usr/include/db4.8/lib/* /usr/lib

Once you have compiled and installed the Berkeley DB 4.8 library from source, you now need to edit a file in the namecoin-core source to help it find the header files that are needed for the compile of Namecoin.

cd ~/namecoin-core/
nano build-aux/m4/bitcoin_find_bdb48.m4

Look for the line starting with bdbdirlist= and add the full path to that /build_unix/ folder from earlier. In my case it was in /home/mjm/db-4.8.30.NC/build_unix but it will no doubt be different for you.


Step 4. Compiling namecoin-core

Now we being with the build of the namecoin-core binaries.

cd ~/namecoin-core/
sudo make install

Note that these steps may take some time, especially the make command above – it took about ten minutes or so for me.

Once this is complete you’ll have the following files in your /usr/local/bin/ ready to go.

  • namecoind
  • namecoin-cli
  • namecoin-tx
  • test_namecoin
  • bench_namecoin

You’ll want to start up namecoind to run in the background and in a separate article I’ll cover the best-practice of using systemd to keep that up and running in the background.

You should also create a separate ‘namecoin’ user with less privileges to run the namecoind daemon.

Hopefully this has been some help to you.

Configure static IP address on Ubuntu 16.04 LTS Server

Ubuntu 16.04 has been out for just over a month now, and I’m in the process of upgrading some boxen. In some cases I’ve been completely reinstalling them for that clean fresh feel, and find myself once again having to configure static IP addresses.

Doing this can be problematic (made worse by the fact that even the official Ubuntu LTS documentation doesn’t give correct advice), particularly when it comes to DNS resolution, and in my case, a very-old-school habit of blindly wanting to edit the /etc/resolv.conf file which you really should not be doing any more these days.

Step 1. Edit the /network/interfaces file

sudo nano /etc/network/interfaces

sudo nano /etc/network/interfacesThe interfaces file is where you need to change from the default “dhcp” setting to add some information about the “static” IP address that you want to configure.

In this case, look for the line in the file that says “# The primary network interface” and directly beneath this you’ll see something like (the default DHCP configuration):

auto ens160
iface ens160 inet dhcp

If you’ve been using previous versions of Ubuntu you might have noticed that the interface name above “ens160” looks a bit odd. It used to be called “eth0” or “eth1”, but as from Ubuntu 15.10 the interface name is now allocated based on a few other factors – read more about that here if you’re interested.

Simply comment, remove or edit the line that says ends with “dhcp” and add the following information (here’s an example only):

iface <interface> inet static

Next you’ll want to add the nameservers by adding the line “dns-nameservers” followed by a list of IP addresses.  A lot of people use Google’s public DNS, or if you have details from your service provide use them instead.


PRO-TIP: Double-check the file again, and ensure all details are correct, before proceeding.  If you are configuring a remote system you could easily cut yourself off if you get it wrong.

Save the file, and you’re done.

Step 2. Restart the networking service (or reboot)

Once you are confident the change has been made, and if you don’t want to reboot you can just restart the networking service.

sudo /etc/init.d/networking restart

After doing this, and provided you don’t get any errors, your primary network interface should now be configured with the static IP address details you have provided.

Failing that, a reboot will also do the trick quite nicely, and with the current version of 16.04 I suspect there’s a bug that is causing “ifconfig -a” not to update unless you perform a reset.

sudo reboot

Good luck, and may your boxen be correctly addressed.