Setup SSH Tunnel for SytemD

The what:

There are several cases when you just need some SSH tunnel to another system with some port redirections.
If the tunnel fails for whatever reason, it should reset itself. Setting up a SSH tunnel with port redirection as a service is the answer!

The How:

Creating SystemD config

The setup is a “user defined” config. When the user is logged on to the system, the service will become active.
You need to setup SSH password less login setup (with keys) to be able to use this.

First you need to created some directories (if not present)

Then create a SystemD service definition file inside this location
Name the file:

The content….:

After creating the file, SystemD needs to know that this file is present. You need to do a reload of SystemD

Almost done…..

Define the tunnels

To define a tunnel, add the following lines to your ~/.ssh/config file. If not present, create the file.

More tunnels? just duplicate the block with other params.
If you need more option for SSH, take a look at man ssh_config

Running the tunnels

Lets get your hard work up and running!
Use the systemctl command to start/stop/status you’re tunnel

To set-up autostart, use the same command but replace start with enable
This will start the tunnel when you log-on to your system.

Thats it! you’re up and running!

Checking / Stopping the tunnel

For status checking, use the systemctl command

To stop the tunnel



Apache serves the first SSL host vhost found on a none-SSL domain.

Your hosting two name based domains and For the domain you have a SSL and non-SSL vhost configuration .
The domain has only a none-SSL vhost config plane and simple.

When a user connects to the site, there will be no error message telling the vhost (domain) doesn’t exist. Instead apache serves the site in SSL……. Pretty weird!
This is default behavior for apache. It serves the first available SSL vhost when the requested one is not found.


For many reasons you just won’t want this to happen. This behavior can be changed by adding a vhost configuration that listens to *:443 and serve one of the apache error codes back to the client. For a complete list of error codes look here.

  1. Create a file named 10-localhost.localdomain-ssl.conf at the location apache reads your configuration files. On a RHEL/CentOS based os, the default location is /etc/httpd/conf.d
  2. opy the stuff below into your file

    Checkout the config section Redirect rules

    This tells apache which error code/page the client receives. So tweak it with the message you want to return
  3. Create a SSL cert and key for localhost.localdomain
    Check this how to for creating certificates and stuff…
  4. Copy the new cert and key file to
  5. Restart apache and go test!

How To Generate SSL Key, CSR and Self Signed Certificate For Apache

If you want to convert your website from HTTP to HTTPS, you need to get a SSL certificate from a valid organization like Verisign, Quovadis, Thawte, etc. You can also generate self signed SSL certificate for testing purpose.

In this article, let us review how to generate private key file (server.key), certificate signing request file (server.csr) and webserver certificate file (server.crt) that can be used on Apache server with mod_ssl.

Key, CSR and CRT File Naming Convention

I typically like to name the files with the domain name of the HTTPS URL that will be using this certificate. This makes it easier to identify and maintain.

  • Instead of server.key, I use localhost.localdomain.key
  • Instead of server.crt, I use localhost.localdomain.crt

Generate Private Key on the Server Running Apache + mod_ssl

First, generate a private key on the Linux server that runs Apache webserver using openssl command as shown below.

That generates a 2048-bit RSA key pair, encrypts them with a password you provide, and writes them to a file. You need to next extract the public key file. You will use this, for instance, on your web server to encrypt content so that it can only be read with the private key..

Export the RSA Public Key to a File

The command to do that is

The -pubout flag is really important. Be sure to include it.

Next open the public.crt and ensure that it starts with a -----BEGIN PUBLIC KEY-----. This is how you know that this file is the public key of the pair and not a private key.
To check the file from the command line you can use the less command, like this:

Visually Inspect Your Key Files

It is important to visually inspect you private and public key files to make sure that they are what you expect. OpenSSL will clearly explain the nature of the key block with a -----BEGIN RSA PRIVATE KEY----- or -----BEGIN PUBLIC KEY-----

You can use less to inspect each of your two files in turn:

  • less localhost.localdomain.key to verify that it starts with a -----BEGIN RSA PRIVATE KEY-----
  • less localhost.localdomain.crt to verify that it starts with a -----BEGIN PUBLIC KEY-----

The Generated Key Files

The generated files are base64-encoded encryption keys in plain text format. If you select a password for your private key, its file will be encrypted with your password. Be sure to remember this password or the key pair becomes useless.

The private key file looks something like this

The public key file looks somthing like

Protecting Your Keys

Depending on the nature of the information you will protect, it’s important to keep the private key backed up and secret. The public key can be distributed anywhere or embedded in your web application scripts, such as in your PHP, Ruby, or other scripts. Again, backup your keys!

Remember, if the key goes away the data encrypted to it is gone.Keeping a printed copy of the key material in a sealed envelope in a bank safety deposit box is a good way to protect important keys against loss due to fire or hard drive failure

WordPress with SSL (https) behind a Reverse Proxy (Apache)

As you can see, this blog is accessible through SSL (https) encryption only. Normally this is not a huge problem but WordPress is a little bit clunky if it comes to a setup that also includes a reverse proxy.

The following text is a sum up some pages which can be found on the internet but often lacks information. This WordPress blog that you are currently reading is running on an Apache httpd on localhost. In front of it, there is a second Apache httpd which acts as reverse proxy for different tasks. One of these tasks is to offload SSL (https) encryption.

WordPress installation

In the described setup you should first install the WordPress software on http (port 80) without SSL. If you enable SSL at this time chances are good that you end up in a redirect loop.

Configure SSL (https)

On the reverse proxy configure SSL as usual but be aware, that you have to set RequestHeader set X-Forwarded-Proto "https" inside the SSL virtual host! This information is important as otherwise the URL’s generated by WordPress will be http links and therefore you will get browser warnings later. Do not force a permanent redirect from http to https at this point or you will not be able to install the necessary WordPress plugin which take care on your URL’s.

After you have enabled basic https support install the WordPress extension SSL Insecure Content Fixer and configure it to use the X-Forwarded-Proto header. Afterwards you have to modify the wp-config.php to reflect this settings. If you want use Jetpack, you also have to specify SERVER_PORT otherwise you will receive a error message on during the configuration of your social media connections (There was an error retrieving your site settings.). You also have to force admin SSL usage.

Hopefully this will help some people out there to get this up and running. If this config does not help you, leave a comment!

Apache http reverse proxy config

Nginx reverse proxy

I dont use Nginx at the moment, but it should work in the same manner. Just be shure that the X-Forwarded-Proto header is submitted by the reverse proxy to the backend.

WordPress wp-config.php