All posts by d h

Automatically connect to Private Internet Access VPN using OpenVPN client on Raspbian Stretch

Introduction

A Virtual Private Network establishes a secure encrypted connection between your system and a server. It allows you to connect to an untrusted network and tunnel all your network traffic so that it emerges from the VPN server to its destination. In this howto, we will configure the OpenVPN client to connect to the VPN servers hosted by Private Internet Access.

I’ve chosen to use Private Internet Access only because I already have an account with them and they support the OpenVPN client to connect to their VPN servers. I’m sure other VPN service providers would work the same way.

Although I initially tested this on Raspbian Stretch on a Raspberry Pi, I have since used the same steps on Debian Stretch and achieved the same results.

Installing all the prerequisites

To accomplish this task we are going to need to install openvpn, unzip, wget, curl and openresolv. We can do this by using the following command:


apt -y install openvpn unzip wget curl openresolv 

Setting up the directory structure

Just to keep things organized we will create a set of directories. This will help if we ever need to alter the configuration by only requiring the change of a couple of linked files. First we need to switch to “/etc/openvpn/client directory”.

cd /etc/openvpn/client

Once there we create several directories by issuing the following commands:

mkdir certs-available
mkdir confs-available
mkdir login-available
mkdir certs-enabled
mkdir login-enabled
mkdir vpn-bundles

Setting up all the configurations

Private Internet Access (as well as other VPN providers) provide configuration bundles for the OpenVPN default client. We are going to download those configurations, alter them a bit and use them to connect to the PIA VPN server as soon as our system finishes booting up.

Switch to the directory we created to store the configuration bundle by issuing the following command:

cd /etc/openvpn/client/vpn-bundles

Once in /etc/openvpn/client/vpn-bundles we can proceed to download the configuration bundle with wget by issuing the following:

wget https://www.privateinternetaccess.com/openvpn/openvpn.zip

Now that we have the zipped file with all the configurations we need to unzip it by using the following command:

unzip openvpn.zip -d "$(date +"%d-%m-%Y")"-PIA-openvpn

This command will unzip the openvpn.zip file into a directory whose name starts with the date followed by “-PIA-openvpn”. We are doing this so that in the future if there is a need to download a new set of configurations we can easily tell which directory contains the newly downloaded ones.

Once the file is unzipped we can start moving the configurations to the directories we previously created.

cd "$(date +"%d-%m-%Y")"-PIA-openvpn
mkdir /etc/openvpn/client/certs-available/PIA
cp *.crt /etc/openvpn/client/certs-available/PIA/
cp *.pem /etc/openvpn/client/certs-available/PIA/
mkdir /etc/openvpn/client/confs-available/PIA
cp *.ovpn /etc/openvpn/client/confs-available/PIA/

Because we want the OpenVPN client to start without user interaction, we need to add a couple of settings to all VPN configuration files we just downloaded. Change to the directory where we stored them by issuing the following command:

cd /etc/openvpn/client/confs-available/PIA

We need to alter all the configuration files so that they can get the user name and password from a file named “login” located at “/etc/openvpn/client/login-enabled/”. This can be accomplished by issuing the following command:

sed -i 's/auth-user-pass/auth-user-pass \/etc\/openvpn\/client\/login-enabled\/login/g' *.ovpn

We also need to add the following settings to all the configuration files. These settings deal with changing the DNS servers in order to prevent DNS leaks when the VPN is up.

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
down-pre

Going into each file to add the aforementioned settings would be too tedious, it is better to use a small script that goes into each file and adds the settings. The script is simple, just create a file named add_vpn_settings.sh with the following content:

#/bin/bash
cd /etc/openvpn/client/confs-available/PIA
for file in *
 do 
     echo "script-security 2" >> "$file"
     echo "up /etc/openvpn/update-resolv-conf" >> "$file"
     echo "down /etc/openvpn/update-resolv-conf" >> "$file"
     echo "down-pre" >> "$file"
 done

Next step is to make executable by issuing the following:

chmod +x add_vpn_settings.sh

And finally we run the add_vpn_settings.sh script by issuing:

./add_vpn_settings.sh

Now we need to backup the original update-resolv-conf file, this is because we are going to use a replacement that is better able to update the DNS servers in /etc/resolv.conf when they are pushed in by the VPN server. We can do this be issuing the following commands:

cd /etc/openvpn
mv update-resolv-conf update-resolv-conf-ORIG

If we ever need to return to the default script we just rename “update-resolv-conf-ORIG” back to “update-resolv-conf “.

Next we need to download the replacement update-resolv-conf file from https://github.com/masterkorp/openvpn-update-resolv-conf. We can issue the following commands to accomplish this:

cd /etc/openvpn
wget https://github.com/masterkorp/openvpn-update-resolv-conf/raw/master/update-resolv-conf.sh

Now we rename it and make it executable:

mv update-resolv-conf.sh update-resolv-conf
chown root:root update-resolv-conf
chmod 555 update-resolv-conf

Next we need to create a the file that contains the actual username and password for the PIA VPN server. Issuing the following three commands should do the job:

cd /etc/openvpn/client/login-available
echo "YOUR_PIA_USERNAME" > PIA-Login
echo "YOUR_PIA_PASSWORD" >> PIA-Login

Now we create a link from /etc/openvpn/client/login-available to /etc/openvpn/client/login-enabled/login by issuing the following:

ln -s /etc/openvpn/client/login-available/PIA-Login /etc/openvpn/client/login-enabled/login

Finally we link one of the configurations available to be the default one (I’ve used the UK London configuration as an example below, you can use whichever configuration you desire).

ln -s /etc/openvpn/client/confs-available/PIA/UK\ London.ovpn /etc/openvpn/default.conf

After a reboot, the openvpn client should be up and everything should be flowing through the vpn tunnel.

Setting up a mining system with xmr-stak built from source and Ubuntu 16.04

If using an Nvidia GPU, install the Nvidia CUDA toolkit:

Download installer type “deb(network)” from:

https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&target_distro=Ubuntu&target_version=1604

To install issue the following commands:

$ sudo dpkg -i cuda-repo-ubuntu1604_9.1.85-1_amd64.deb
$ sudo apt-key adv --fetch-keys http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/7fa2af80.pub
$ sudo apt-get update
$ sudo apt-get install cuda

Editing the enviroment to include the CUDA path:

$ sudo nano /etc/environment

Find the PATH variable and include the /usr/local/cuda-9.1/bin folder at the end of the string.

Save the file and reboot.

If using and AMG GPU, install AMD APP SDK 3.0:

Download and install the latest version from:

APP SDK – A Complete Development Platform

Untar the SDK to a location of your choice.

Decompress the file wit the following command:

$ tar -xvjf AMD-APP-SDKInstaller-v<3.0.x.y>-GA-linux64.tar.bz2

Run the installer:

$ sudo ./AMD-APP-SDKInstaller-v<3.0.x.y>-GA-linux64.sh

To fix libOpenCL issue:

$ cd $AMDAPPSDKROOT/lib/x86_64
$ sudo ln -sf sdk/libOpenCL.so.1 libOpenCL.so

then logout and login again.

Installing amdgpu-pro

Download the latest package from:
https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx

Decompress the file wit the following command:

$ tar -xJvf amdgpu-pro-17.40-492261.tar.xz
$ cd amdgpu-pro-17.40-492261
$ sudo ./amd-pro-install -y

Reference:
https://linuxconfig.org/install-amdgpu-pro-16-50-on-ubuntu-16-04-xenial-xerus-linux

Building xmr-stak from source

Install all dependencies:

$ sudo apt install git libmicrohttpd-dev libssl-dev cmake build-essential libhwloc-dev

Create a directory for the source files and clone the source:

$ mkdir GIT-sources
$ cd GIT-sources
$ git clone https://github.com/fireice-uk/xmr-stak.git

Create a build directory:

$ mkdir xmr-stak/build
$ cd xmr-stak/build

Configuring and building xmr-stak

If building xmr-stak for CPU only mining and without http server support, use the following cmake flags:

$ cmake .. -DCUDA_ENABLE=FALSE -DOpenCL_ENABLE=FALSE -DMICROHTTPD_ENABLE=FALSE

If building xmr-stak for AMD GPU mining and CPU mining, use the following cmake flags:

$ cmake .. -DCUDA_ENABLE=FALSE

If building xmr-stak for Nvidia GPU and CPU mining, use the following cmake flags:

$ cmake .. -DOpenCL_ENABLE=FALSE

If building for all (AMD GPU, Nvidia GPU and CPU mining)

$ cmake ..

After cmake finishes, execute the following to build:

$ make -j4 install

Final system configurations

If using GPU mining (Nvidia GPU or AMD GPU), ensure the user you will use to mine is part of the video group in /etc/group

$ sudo usermod -a -G video $LOGNAME

Enabling Large Page Support for AMDGPU-PRO

Edit /etc/default/grub and add GRUB_CMDLINE_LINUX=”amdgpu.vm_fragment_size=9″

After editing ggrub, do:
$ sudo update-grub
$ sudo reboot

Configuring Large Page Support for Operating system (applies to all GPUs and CPUs)

Create a file named 98-HugePages-miner.conf in /etc/sysctl.d with the following content:

############################
vm.nr_hugepages=128
############################

Add the following lines to /etc/security/limits.conf (where “miner” is the name of your mining account):

############################
miner soft memlock 262144
miner hard memlock 262144
############################

Then reboot with:

$ reboot

You will find the xmr-stak binary in ~/GIT-sources/xmr-stak/build/bin. Run xmr-stak and follow the prompts to begin mining.

Building a Root CA and an Intermediate CA using OpenSSL and Debian Stretch

A bit of background

A Root Certificate Authority is used to issue digital certificates to servers, clients or users.  It generates digital certificates that certify the ownership of a public key, allowing others to trust the certificate.

An Intermediate Certificate is a subordinate certificate issued by a Root certificate authority for the purpose of issuing certificates.  This creates a certificate chain that begins in the Root CA, through the intermediate and ending in the issued certificate.  This establishes a chain of trust that can verify the validity of a certificate.

In this post, we will step through the process of creating a Root CA, then an Intermediate CA and finally sign digital certificates for a server. A bit of warning, this setup should be sufficient for a homelab or a small local setup; you should not use this as a production service.

Prepare to build

Install Debian Stretch, the minimum should suffice.  There is no need any GUI.  Install SSH for ease of administration and to transfer you certificates securely out.

Make sure that the Fully Qualified Domain Name of the computer is set  correctly.

Make sure your time zone is correctly set.

Make sure the time and date are correctly set.

If you wish you can install ntp to ensure time is always correct.

# apt install ntp

Download the following configuration files:

openssl_root.cnf

openssl_intermediate.cnf

openssl_csr_san.cnf

After download rename all of them by dropping the “.txt” extension.

Creating the Root CA

Create the directory structure for the Root CA:

# mkdir /root/ca
# cd /root/ca
# mkdir newcerts certs crl private requests

While at /root/ca we should also create “index.txt” file for OpenSSL to keep track of all signed certificates and the “serial” file to give the start point for each signed certificate’s serial number. This can be accomplished by doing the following:

# cd /root/ca
# touch index.txt
# touch index.txt.attr
# echo '1000' > serial

Copy openssl_root.cnf to /root/ca, edit it and look for the following entries:

# The root key and root certificate.
private_key = $dir/private/ca.DOMAINNAME.key.pem
certificate = $dir/certs/ca.DOMAINNAME.cert.pem

# For certificate revocation lists.
crlnumber = $dir/crlnumber
crl = $dir/crl/ca.DOMAINNAME.crl.pem
crl_extensions = crl_ext
default_crl_days = 30

Change DOMAINNAME to something that matches the domain of your network, this isn’t strictly necessary but it makes for a more customized naming convention.

Generate the Root private key

(change DOMAINNAME to match what you used in the openssl_root.cnf):

# cd /root/ca
# openssl genrsa -aes256 -out private/ca.DOMAINNAME.key.pem 4096

Signing the Root Certificate

Use the root private key to sign the root certificate.
(change DOMAINNAME to match what you used in the openssl_root.cnf):

# openssl req -config openssl_root.cnf -new -x509 -sha512 -extensions v3_ca -key /root/ca/private/ca.DOMAINNAME.key.pem -out /root/ca/certs/ca.DOMAINNAME.crt.pem -days 3650 -set_serial 0

Ensure that when filling out the “Common Name” variable that you use the CA server + Domain name of the network

Creating an Intermediate Certificate Authority

Create a directory to separate the intermediary files from our root configuration

# mkdir /root/ca/intermediate

Also all the directories and files needed to support (similar to the ones we created for the Root CA):

# cd /root/ca/intermediate
# mkdir certs newcerts crl csr private
# touch index.txt
# touch index.txt.attr
# echo 1000 > /root/ca/intermediate/crlnumber
# echo '1234' > serial

Copy  openssl_intermediate.cnf to /root/ca/intermediate, edit it and look for the following entries:

# The root key and root certificate.
private_key = $dir/private/int.DOMAINNAME.key.pem
certificate = $dir/certs/int.DOMAINNAME.crt.pem

# For certificate revocation lists.
crlnumber = $dir/crlnumber
crl = $dir/crl/int.DOMAINNAME.crl.pem
crl_extensions = crl_ext
default_crl_days = 30

Change DOMAINNAME to the same thing that you used in openssl_root.cnf

Creating the private key and certificate signing request for the Intermediate CA

(change DOMAINNAME to the value you’ve been using so far)

# cd /root/ca
# openssl req -config /root/ca/intermediate/openssl_intermediate.cnf -new -newkey rsa:4096 -keyout /root/ca/intermediate/private/int.DOMAINNAME.key.pem -out /root/ca/intermediate/csr/int.DOMAINNAME.csr

Creating the intermediate certificate

(change DOMAINNAME to the value you’ve been using so far)

# openssl ca -config /root/ca/openssl_root.cnf -extensions v3_intermediate_ca -days 3650 -notext -md sha512 -in /root/ca/intermediate/csr/int.DOMAINNAME.csr -out /root/ca/intermediate/certs/int.DOMAINNAME.crt.pem

** Notice that the root CA configurtion (openssl_root.cnf) is used.

Creating the certificate chain

# cd /root/ca
# cat intermediate/certs/int.DOMAINNAME.crt.pem certs/ca.DOMAINNAME.crt.pem > intermediate/certs/chain.DOMAINNAME.crt.pem

What are all these files for?

So now that you have created all these files, which ones are the ones you need?

In /root/ca/certs, ca.DOMAINNAME.crt.pem is the Root CA certificate.
In /root/ca/intermediate/certs, int.DOMAINNAME.crt.pem is the Intermediate CA certificate.
In /root/ca/intermediate/certs, chain.DOMAINNAME.crt.pem is the concatenation of the Root CA certificate and the Intermediate CA certificate.

Creating server certificates

Copy openssl_csr_san.cnf to /root/ca/intermediate,  edit it and change the entries under [alt_names] so that the DNS.* entries match the Fully Qualified Domain Name of the server you wish to create a certificate for.  This will create a certificate with embedded  Subject Alternative Name (SANs), so no more warnings  from Chrome about NET::ERR_CERT_AUTHORITY_INVALID.

Creating the key and certificate signing request

(change “www.example.com” to your server’s FQDN)

# cd /root/ca
# openssl req -out intermediate/csr/www.example.com.csr.pem -newkey rsa:2048 -nodes -keyout intermediate/private/www.example.com.key.pem -config intermediate/openssl_csr_san.cnf

Creating the certificate by signing the signing request with the intermediate CA

(change “www.example.com” to your server’s FQDN)

# cd /root/ca
# openssl ca -config intermediate/openssl_intermediate.cnf -extensions server_cert -days 3750 -notext -md sha512 -in intermediate/csr/www.example.com.csr.pem -out intermediate/certs/www.example.com.crt.pem

In /root/ca/intermediate/certs you should now have a certificate for use in the server (www.example.com in the case of the example).

Creating a combined certificate for use with Apache server

(change “www.example.com” to your server’s FQDN)

# openssl pkcs12 -inkey www.example.com.key.pem -in www.example.com.crt.pem -export -out www.example.com.combined.pfx
# openssl pkcs12 -in www.example.com.combined.pfx -nodes -out www.example.com.combined.crt

Installing Guacamole 0.9.13 from source on Debian Stretch and Tomcat 8

Install build tools:

# apt install build-essential maven checkinstall

Install JDK, database and application server:

# apt install openjdk-8-jdk mariadb-server \
mariadb-client mariadb-common tomcat8

Secure your mysql/mariadb installation:

# mysql_secure_installation

Take note of the mysql root password you just created.

Install Guacamole build dependencies:

# apt install libcairo2-dev libjpeg62-turbo-dev \
libpng-dev libossp-uuid-dev libavcodec-dev \
libavutil-dev libswscale-dev libfreerdp-dev \
libpango1.0-dev libssh2-1-dev libtelnet-dev \
libvncserver-dev libpulse-dev libssl-dev \
libvorbis-dev libwebp-dev ghostscript freerdp

Untar the sources:

$ tar -xvzf guacamole-client-0.9.13-incubating.tar.gz
$ tar -xvzf guacamole-server-0.9.13-incubating.tar.gz

Untar the database related parts:

$ tar -xvzf guacamole-auth-jdbc-0.9.13-incubating.tar.gz
$ tar -xvzf mysql-connector-java-5.1.45.tar.gz

Build Guacamole Server

$ cd guacamole-server-0.9.13-incubating
$ ./configure --with-init-dir=/etc/init.d
$ make -j2
$ sudo make install

– or –

$ sudo checkinstall --pkgname=guacamole-guacd -D make install

If using checkinstall should get an output similar to this:

####################################################

*****************************************
**** Debian package creation selected ***
*****************************************

This package will be built according to these values:

0 – Maintainer: [ root@vm ]
1 – Summary: [ Guacamole Guacd ]
2 – Name: [ guacamole-guacd ]
3 – Version: [ incubating ]
4 – Release: [ 1 ]
5 – License: [ GPL ]
6 – Group: [ checkinstall ]
7 – Architecture: [ amd64 ]
8 – Source location: [ guacamole-server-0.9.13-incubating ]
9 – Alternate source location: [ ]
10 – Requires: [ ]
11 – Provides: [ guacamole-guacd ]
12 – Conflicts: [ ]
13 – Replaces: [ ]

Enter a number to change any of them or press ENTER to continue:

####################################################

Enter the number [3] to change the Version from “incubating” to 0.9.13

You should end up with something like this:

####################################################

This package will be built according to these values:

0 – Maintainer: [ root@vm ]
1 – Summary: [ Guacamole Guacd ]
2 – Name: [ guacamole-guacd ]
3 – Version: [ 0.9.13 ]
4 – Release: [ 1 ]
5 – License: [ GPL ]
6 – Group: [ checkinstall ]
7 – Architecture: [ amd64 ]
8 – Source location: [ guacamole-server-0.9.13-incubating ]
9 – Alternate source location: [ ]
10 – Requires: [ ]
11 – Provides: [ guacamole-guacd ]
12 – Conflicts: [ ]
13 – Replaces: [ ]

Enter a number to change any of them or press ENTER to continue:

####################################################

Press [Enter] to continue and wait for checkinstall to install and build a package

If you ever need to remove the guacamole and you used checkinstall you can do it with:

# dpkg -r guacamole-guacd

Link all the freerdp libraries to the system freerdp library location:

$ sudo ln -s /usr/local/lib/freerdp/* /usr/lib/x86_64-linux-gnu/freerdp/.

Run ldconfig:

# ldconfig -v

Build Guacamole Client:

$ cd ..
$ cd guacamole-client-0.9.13-incubating
$ mvn package

Create the directories to hold extensions and libraries:

# mkdir /etc/guacamole
# mkdir /etc/guacamole/lib
# mkdir /etc/guacamole/extensions
# mkdir /var/lib/guacamole

Deploying the Guacamole:

$ sudo cp guacamole/target/guacamole-0.9.13-incubating.war /var/lib/guacamole/
$ sudo ln -s /var/lib/guacamole/guacamole-0.9.13-incubating.war /var/lib/tomcat8/webapps/guacamole.war

Creating the properties file:

In /etc/guacamole create a file called guacamole.properties with the following content:

####################################################
# Hostname and port of guacamole proxy
guacd-hostname: localhost
guacd-port: 4822

guacamole.home: /etc/guacamole

#MySQL Properties
mysql-hostname: localhost
mysql-port: 3306
mysql-database: guacamole_db
mysql-username: [Guacamole_DB_USERNAME]
mysql-password: [Guacamole_DB PASSWORD]
####################################################

Make sure you take note of the [Guacamole_DB_USERNAME] and [Guacamole_DB PASSWORD] you decide to put in this file. They will be used later on to set up the database.

Link /etc/guacamole to tomcat home directory:

$ sudo ln -s /etc/guacamole /var/lib/tomcat8/.guacamole

Deploy database authentication:

$ cd ..
$ cd guacamole-auth-jdbc-0.9.13-incubating
$ sudo cp mysql/guacamole-auth-jdbc-mysql-0.9.13-incubating.jar /etc/guacamole/extensions/
$ cd ..
$ cd mysql-connector-java-5.1.45
$ sudo cp mysql-connector-java-5.1.45-bin.jar /etc/guacamole/lib/

Create the database:

# mysql -u root -p[MYSQL_ROOT_PASSWORD]
create database guacamole_db;
create user '[Guacamole_DB_USERNAME]'@'localhost' identified by '[Guacamole_DB PASSWORD]';
GRANT SELECT,INSERT,UPDATE,DELETE ON guacamole_db.* TO '[Guacamole_DB_USERNAME]'@'localhost';
flush privileges;
quit

Populate the database:

# cat guacamole-auth-jdbc-0.9.13-incubating/mysql/schema/*.sql | mysql -u root -p[MYSQL_ROOT_PASSWORD] guacamole_db

Ensure that guacd is enabled:

# systemctl enable guacd

and finally reboot…

If you ever need to backup the database:

# mysqldump -u root -p --add-drop-table guacamole_db > guacamole_db.sql

To restore the backup:

# mysql -u root -p guacamole_db < guacamole_db.sql

To further lockdown the installation

Fix permisions of guacamole.properties so only tomcat can read it by issuing the following:

# cd /etc/guacamole
# chown root:tomcat8
# chmod 640 guacamole.properties

Set up Autossh with systemd

Autossh is a great tool that is useful in establishing a persistent encrypted reverse tunnel between two computers.

A case for autossh

Let us say that you have a static IP on the internet and your friend (or relative) that always needs help fixing his computer has a dynamic IP address (constatly changes).  Whenever your friend (or relative) needs their computer fixed you could run to their house and fix it… or you could figure out a way to connect to their computer to fix it.  Now your friend (or relative) probably doesn’t know how to open ports on their router or may not be able to, so how could you make a connection between their computer and yours?…  Enter SSH tunneling…  With ssh you could have your friend (or relative) connect to your computer and establish a reverse tunnel back to them (even on Windows with PUTTY), but again this is the person who is not that good with computers.

We need to make something that is bulletproof, something that you could drop at your friend’s (or relative’s) house and that it does everything by itself.  This is where autossh comes into play.

With autossh running on a simple Linux box (maybe a Raspberry Pi) you can accomplish what is required to establish a persistent tunnel between your friend’s (or relative’s) network and yours.

Another scenario would be that you want to set up an off-site backup of you important data at a friend’s house, but you don’t want to mess about in their router configuration.  You want to give them something they can just plug into their network and turn on.  Autossh can establish a reverse tunnel from their network to your network and you can just use any of the myriad of network sync tools to accomplish your off-site backup.

How to install and configure autossh with systemd

Before we begin we need to make the following assumptions.

  1. Autossh will be running in a computer named “autossh_server” on a different network.
  2. The computer we want to use as our gateway to the other network via the autossh tunnel is named “otherserver”.
  3. We have at least one account (user1) on all computers and root privileges in order to change system configurations files.
  4. We are using Debian Stretch (or a similar distro like Raspbian)
  5. We will run autossh as a service under a user named “autossh”.

We begin by installing autossh in “autossh_server”.

# apt-get install autossh

In this example I’ve chosen “autossh” as the user that the autossh service will run as. We can create the user by executing the following command:

# adduser autossh

Even though the adduser command made a home directory when we created the “autossh” user,  this is a service and we don’t want it to use a home directory in the “/home” folder.  So lets create a folder named “autossh” in the “/var/run/” directory. Create the directory with the following command:

# mkdir /var/run/autossh

Now we make sure that the “autossh” user and the “autossh” group have ownership of the “/var/run/autossh” directory.

# chown autossh:autossh /var/run/autossh

Since “/var/run” is a directory usually mounted as tmpfs anything that is written to “/var/run/autossh” will be effectively destroyed on reboot. Because of this, we need a place to store keys for autossh and since we are running it as a service we might as well use a directory in “/etc”. Create the “/etc/tunnel” directory.

# mkdir /etc/tunnel
# chown autossh:autossh /etc/tunnel
# chmod 700 /etc/tunnel

For the initial setup we are going to use the “/home/autossh” directory.  Logout of the root account and login as the autossh user.  Make sure that you are in the autossh user directory (run “pwd”; it should return “/home/autossh”) and run the following as the “autossh” user:

$ ssh-keygen -t rsa -b 4096

This create an 4096 bit key.  Once it finishes do the following while still the user “autossh” and where “user1” is a user in the server “otherserver”, running the ssh daemon:

cat .ssh/id_rsa.pub | ssh user1@otherserver 'cat >> .ssh/authorized_keys'

This command basically logs into the remote server (“otherserver”) from the “autossh” user account using the “user1” account on the remote server and transfers the authorizing key to that account.  This allows for future logins to be accomplished without having to enter a password.  It also takes care of the initial registration of the remote server’s key (answer “yes” when prompted).

If you get an error like “bash: .ssh/authorized_keys: No such file or directory” ensure that the “.ssh” directory exists in the home directory of the user in “otherserver” and re-run the previous command.

Now we need to move the contents of the “.ssh” directory to its new home in /etc/tunnel:

$ cp -Rp .ssh /etc/tunnel
$ chmod -R 700 /etc/tunnel

The two above commands copy the newly created cryptographic keys to “/etc/tunnel” and lock down the directory so that it is only readable/writable/executable by the owner, in this case the “autossh” user.

Setting up the configuration in systemd

Now return to being root and create “/etc/default/autossh” with the following content:
##############################################
#Specifies how long ssh must be up before we
#consider it a successful connection
AUTOSSH_GATETIME=0
#Sets the connection monitoring port.
#A value of 0 turns the monitoring function off.
AUTOSSH_PORT=0
AUTOSSH_LOGLEVEL=7
AUTOSSH_LOGFILE=/var/run/autossh/user_ssh_error.out
SSH_OPTIONS="-N -o 'ServerAliveInterval 60' -o 'ServerAliveCountMax 3' -p 22 -R 20022:localhost:22 user@otherserver -i /etc/tunnel/.ssh/id_rsa"
###########################################

On the above configuration, notice the line that says:

SSH_OPTIONS="-N -o 'ServerAliveInterval 60' -o 'ServerAliveCountMax 3' -p 22 -R 20022:localhost:22 user@otherserver -i /etc/tunnel/.ssh/id_rsa"

This are the options you are passing to ssh.  The “ServerAliveInterval 60” ensures that every 60 seconds a null packet is sent to keep the connection alive.  The “ServerAliveCountMax 3” set to three the number of server alive messages that may be sent without getting a reply.  The “-p 22” is the port that the remote ssh server is listening on (ssh usually is at port 22).  The “-R 20022:localhost:22” is how we set up the reverse tunnel; in this instance  port 20022 on “otherserver” system connects you to port 22 on “autossh_server”.  You can add any other ports or even forward connections from “autossh_server” to other systems on its network.

For example:

Adding “-R 20080:httpserver:80” would take anything coming into port 20080 of “otherserver” and forward it to port 80 on a system called “httpserver” in the same network as “autossh_server”.

Also, “-R 20089:Windows_box_X:3389” would take anything coming into port 20089 of “otherserver” and forward it to port 3389 on “Windows_box_X”.  Port 3389 is the Windows Remote Desktop Protocol port, so by adding that little line now you can RDP into a windows box on another network over an encrypted tunnel from a system in your local network.

Now to continue with configuration, create “/lib/systemd/system/autossh.service” with the following content:

#############################################
[Unit]
Description=autossh
Wants=network-online.target
After=network-online.target

[Service]
#Type=simple
User=autossh
EnvironmentFile=/etc/default/autossh
ExecStart=/usr/bin/autossh $SSH_OPTIONS
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target
#################################################

Now, we can create a soft link in /etc/systemd/system:

# ln -s /lib/systemd/system/autossh.service /etc/systemd/system/autossh.service

Try out the connection as the autossh user:

$ ssh user1@otherserver

If you can ssh in without a password then everything is working as it should.

To further lock down the autossh user, in /etc/passwd change:

autossh:x:1001:1001:autossh,,,:/home/autossh:/bin/bash

to:

autossh:x:1001:1001:autossh,,,:/var/run/autossh:/bin/false

What we are doing here is changing the value for the home directory of the “autossh” user from ” /home/autossh” to “/var/run/autossh” and changing the default shell from “/bin/bash” to “/bin/false”.   As stated before, using “/var/run/autossh” as home ensures its contents is always reset to nothing on reboot.  By changing the default shell value from “/bin/bash” to “/bin/false” we make sure that the “autossh” user is not able to log into the box in any manner.

As started before the contents of “/var/run” doesn’t survive reboot, we need to ensure that the “/var/run/autossh” is created on boot every time.  To do this we need to create a file called autossh.conf in /usr/lib/tmpfiles.d with the following content:

#########################################
d /var/run/autossh 0700 autossh autossh
L /var/run/autossh/.ssh - - - - /etc/tunnel/.ssh
##############################################

What follows the “d” basically mean create the directory “/var/run/autossh” with the permisions set at 0700 and owned by user “autossh” and group “autossh”.  All that follows the “L” means to link the /etc/tunnel/.ssh directory to /var/run/autossh/.ssh.  All this ensures that everything is where it needs to be after a reboot.

Before we can start our service, we have to ask systemd to reload all unit files:

$ sudo systemctl daemon-reload

Now we enable the autossh service:

$ sudo systemctl enable autossh

Before we reboot and test everything out we need to also make some changes to “otherserver” that will allow anyone to connect to the forwarded ports.

Assuming that you are using OpenSSH as you ssh daemon, log into your “otherserver” and edit /etc/ssh/sshd_config.  Change:

#GatewayPorts no

To:

GatewayPorts yes

Also ensure that the parameter is not commented.  Daemons other than OpenSSH should have similar settings.  Restart the OpenSSH daemon or reboot.  Also reboot the computer running autossh.

Once the reboot is complete, we can check the status on the computer running autossh with:

$ sudo systemctl status autossh

If there are any problems, check /var/run/autossh/user_ssh_error.out

Now to test it out…  if you ssh from any machine into “otherserver” using port 20022 you will actually be connected to port 22 on “autossh_server”.

In essence the following command on your local network:

$ ssh -p20022 user1@otherserver

connects you to a computer on a remote network without the need to know the actual IP address of that computer.

 

Installing xrdp 9.4 and xorgxrdp 2.4 on Debian Stretch

This is similar to the other two previous xrdp and xorgxrdp how-tos, just needed to adjust for newer versions.

This how-to is based on the install instructions from XRDP’s github pages for installing on Debian 8.

Install xrdp’s dependencies:

$ sudo apt-get install git autoconf libtool pkg-config gcc g++ make libssl-dev libpam0g-dev libjpeg-dev libx11-dev libxfixes-dev libxrandr-dev flex bison libxml2-dev intltool xsltproc xutils-dev python-libxml2 g++ xutils libfuse-dev libmp3lame-dev nasm libpixman-1-dev xserver-xorg-dev

Get the xrdp and xorgxrdp sources:

$ mkdir -p GIT-sources/neutrinolabs
$ cd GIT-sources/neutrinolabs
$ wget https://github.com/neutrinolabs/xrdp/releases/download/v0.9.4/xrdp-0.9.4.tar.gz
$ wget https://github.com/neutrinolabs/xorgxrdp/releases/download/v0.2.4/xorgxrdp-0.2.4.tar.gz

Building and installing xrdp:

$ cd GIT-sources/neutrinolabs
$ tar xvfz xrdp-0.9.4.tar.gz
$ cd xrdp-0.9.4
$ ./bootstrap
$ ./configure --enable-fuse --enable-mp3lame --enable-pixman --enable-sound
$ make -j2
$ sudo make install
$ sudo ln -s /usr/local/sbin/xrdp{,-sesman} /usr/sbin

Building and installing xorgxrdp:

$ cd GIT-sources/neutrinolabs
$ tar xvfz xorgxrdp-0.2.4.tar.gz
$ cd xorgxrdp-0.2.4
$ ./bootstrap
$ ./configure
$ make -j2
$ sudo make install

Generate keys:

$ sudo xrdp-keygen xrdp auto 2048

Building the pulseaudio modules:

$ cd ~
$ mkdir -p Release-sources/pulseaudio
$ cd Release-sources/pulseaudio
$ sudo apt-get install dpkg-dev
$ sudo apt-get source pulseaudio
$ sudo apt-get build-dep pulseaudio

Change the permisions on the pulseaudio directory to your user:

$ sudo chown -R [USER]:[GROUP] pulseaudio-10.0
$ cd pulseaudio-10.0
$ ./configure

In change directory to “~/GIT-sources/neutrinolabs/xrdp-0.9.3/sesman/chansrv/pulse”

$ cd ~
$ cd GIT-sources/neutrinolabs/xrdp-0.9.4/sesman/chansrv/pulse

Edit the Makefile with your favorite editor and point it to the sources for pulseaudio by changing:

PULSE_DIR = /tmp/pulseaudio-10.0

to:

PULSE_DIR = ../../../../../../Release-sources/pulseaudio/pulseaudio-10.0

then:

$ make -j2

If the build is successful , copy the 2 modules to /usr/lib/pulse-10.0/modules.

$ sudo cp module-xrdp*.so /usr/lib/pulse-10.0/modules

Check the /usr/lib/pulse-10.0/modules directory:

$ ls -al /usr/lib/pulse-10.0/modules

If necessary, fix the ownership and permissions on the two modules:

$ cd /usr/lib/pulse-10.0/modules
$ sudo chown root:root module-xrdp-s*.so
$ sudo chmod 644 module-xrdp-s*.so

The modules are named module-xrdp-sink.so and module-xrdp-source.so

Enable the services:

$ sudo systemctl enable xrdp.service
$ sudo systemctl enable xrdp-sesman.service

Fixes for possible issues:

To run it as terminal server (also useful for Guacamole) add allowed_users=anybody to /etc/X11/Xwrapper.config to allow anybody to start X

To fix the thinclient_drives share error when connected via RDP to the client:

$ sudo umount thinclient_drives

logout and re-login via rdp

 

Installing xrdp 9.3.1 and xorgxrdp 2.4 on Debian Stretch

This is similar to the previous xrdp and xorgxrdp how-to, it is just adjusting to the newer versions of all the pieces of software.

This how-to is based on the install instructions from XRDP’s github pages for installing on Debian 8.

Install xrdp’s dependencies:

$ sudo apt-get install git autoconf libtool pkg-config gcc g++ make libssl-dev libpam0g-dev libjpeg-dev libx11-dev libxfixes-dev libxrandr-dev flex bison libxml2-dev intltool xsltproc xutils-dev python-libxml2 g++ xutils libfuse-dev libmp3lame-dev nasm libpixman-1-dev xserver-xorg-dev

Get the xrdp and xorgxrdp sources:

$ mkdir -p GIT-sources/neutrinolabs
$ cd GIT-sources/neutrinolabs
$ wget https://github.com/neutrinolabs/xrdp/releases/download/v0.9.3.1/xrdp-0.9.3.1.tar.gz
$ wget https://github.com/neutrinolabs/xorgxrdp/releases/download/v0.2.4/xorgxrdp-0.2.4.tar.gz

Building and installing xrdp:

$ cd GIT-sources/neutrinolabs
$ tar xvfz xrdp-0.9.3.1.tar.gz
$ cd xrdp-0.9.3.1
$ ./bootstrap
$ ./configure --enable-fuse --enable-mp3lame --enable-pixman --enable-sound
$ make -j2
$ sudo make install
$ sudo ln -s /usr/local/sbin/xrdp{,-sesman} /usr/sbin

Building and installing xorgxrdp:

$ cd GIT-sources/neutrinolabs
$ tar xvfz xorgxrdp-0.2.4.tar.gz
$ cd xorgxrdp-0.2.4
$ ./bootstrap
$ ./configure
$ make -j2
$ sudo make install

Generate keys:

$ sudo xrdp-keygen xrdp auto 2048

Building the pulseaudio modules:

$ cd ~
$ mkdir -p Release-sources/pulseaudio
$ cd Release-sources/pulseaudio
$ sudo apt-get install dpkg-dev
$ sudo apt-get source pulseaudio
$ sudo apt-get build-dep pulseaudio

Change the permisions on the pulseaudio directory to your user:

$ sudo chown -R [USER]:[GROUP] pulseaudio-10.0
$ cd pulseaudio-10.0
$ ./configure

In change directory to “~/GIT-sources/neutrinolabs/xrdp-0.9.3/sesman/chansrv/pulse”

$ cd ~
$ cd GIT-sources/neutrinolabs/xrdp-0.9.3.1/sesman/chansrv/pulse

Edit the Makefile with your favorite editor and point it to the sources for pulseaudio by changing:

PULSE_DIR = /tmp/pulseaudio-10.0

to:

PULSE_DIR = ../../../../../../Release-sources/pulseaudio/pulseaudio-10.0

then:

$ make -j2

If the build is successful , copy the 2 modules to /usr/lib/pulse-10.0/modules.

$ sudo cp module-xrdp*.so /usr/lib/pulse-10.0/modules

Check the /usr/lib/pulse-10.0/modules directory:

$ ls -al /usr/lib/pulse-10.0/modules

If necessary, fix the ownership and permissions on the two modules:

$ cd /usr/lib/pulse-10.0/modules
$ sudo chown root:root module-xrdp-s*.so
$ sudo chmod 644 module-xrdp-s*.so

The modules are named module-xrdp-sink.so and module-xrdp-source.so

Enable the services:

$ sudo systemctl enable xrdp.service
$ sudo systemctl enable xrdp-sesman.service

Fixes for possible issues:

To run it as terminal server (also useful for Guacamole) add allowed_users=anybody to /etc/X11/Xwrapper.config to allow anybody to start X

To fix the thinclient_drives share error when connected via RDP to the client:

$ sudo umount thinclient_drives

logout and re-login via rdp

 

Lego Batman — Making the minifigure look more like it does in the movie

My son has a fascination with Lego Batman.  Ok, I may have a bit to do with his fascination with Lego Batman, I’m the one that taught him to play it on our very old (but still functional) Wii.  When the Lego Batman movie came out we took him to see it and in the days after my wife got him several minifigres related to it.

Looking at the Batman minifigure, it irked me a bit that in the Lego Batman Movie, Batman’s eyes look like they light up, but the real Lego minifigure does not have light up eyes. Since my wife managed to score more than one Batman minifigure I decided to “enhance” one of them to look more like the movie.

The process was crude and simple.  I basically cut a slit into the head of the minifigure using the dremel.  The slit is in the same general area where the cut-outs for the eyes on Batman’s mask line up.  I then proceeded to grind down a blue LED to fit into the minifigure’s head.  The only reason I chose to use a blue LED is because I have a bunch of them left over from other projects.

Once the LED was stuffed into the head and light was shining out from the slit, it was time to make some hole in the minifigure’s body to accommodate the wires to power the LED.  Initially I thought of just stuffing a small battery into the minifigure’s chest, I quickly gave up on that idea (not much room in there).  Instead I ran wires down a hole I drilled into the “neck ” of the minifigure, then down a hole I drilled into one of the hips and finally out through the bottom of one of the legs into a hole I also drilled into a Lego brick.  The next step is building a small power supply to stuff into the Lego brick (although I may end up using more than one).

Overall the effect is close to what is seen in the movie [insert picture].  Of course the minifigure is no longer useful as a toy…  It is now more of a “showpiece”…

Lego Batman

Pydio 8 with PHP 7 and SSL on Debian Stretch

Installing all dependencies:

# apt install mysql-server php7.0 php7.0-fpm php7.0-mysql php7.0-curl php7.0-json php7.0-gd php7.0-intl php7.0-mbstring php7.0-xml php7.0-zip php7.0-exif php7.0-apcu
apt install libapache2-mod-php

Ensure that apache support for PHP7 is enabled:

# a2enmod php7.0

Installing Pydio:

Download the installation archive.  Choose the Pydio Community Tar.gz archive.

Untar the archive into /var/www/html:

# cd /var/www/html
# tar -xvzf pydio-core-8.0.1.tar.gz

Fix permisions on folders:

# chown -R root:root pydio-core-8.0.1
# chown -R www-data:www-data pydio-core-8.0.1/data/

Create a symlink to the Pydio installation:

# ln -s pydio-core-8.0.1 pydio

In /etc/php/7.0/apache2/php.ini change:

output_buffering = 4096

to:

output_buffering = off

Creating self-signed certificates for Pydio:

# openssl req -x509 -nodes -days 1460 -newkey rsa:2048 -keyout /etc/ssl/private/pydio-selfsigned.key -out /etc/ssl/certs/pydio-selfsigned.crt
# openssl x509 -in /etc/ssl/certs/pydio-selfsigned.crt -out /etc/ssl/certs/pydio-selfsigned.pem -outform PEM

Configuring Apache for SSL:

Enable ssl on apache:

# a2enmod ssl

In the /etc/apalche2/sites-enabled directory:

# rm 000-default.conf
# ln -s ../sites-available/default-ssl.conf default-ssl.conf

In default-ssl.conf change the follwing line from:

SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem

To:

SSLCertificateFile /etc/ssl/certs/pydio-selfsigned.pem

Also change the following line from:

SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

To:

SSLCertificateKeyFile /etc/ssl/private/pydio-selfsigned.key

Configuring Apache for Pydio:

Create a configuration file on /etc/apache2/conf-available:

# cd /etc/apache2/conf-available
# vi pydio.conf

In pydio.conf add the following:

Directory /var/www/html/pydio>
Options Indexes FollowSymlinks
AllowOverride All
Require all granted
</Directory>

Once finished creating /etc/apache2/conf-available/pydio.conf create a symlink to it in /etc/apache2/conf-enabled:

# cd /etc/apache2/conf-enabled
# ln -s ../conf-available/pydio.conf pydio.conf

Restart Apache:

# systemctl restart apache2

Configuring MySQL/MariaDB:

Setup a password for Mysql/Mariadb (follow the prompts):

# mysql_secure_installation

Creating the database and user for Pydio

Create the pydio database:

# mysql -u root -p
create database pydio;

Create a database user for Pydio to use and grant it all access to the pydio database:

create user 'webuser'@'localhost' identified by 'USE A REALLY LONG AND STRONG PASSWORD';
GRANT ALL on pydio.* to 'webuser'@'localhost' identified by 'USE A REALLY LONG AND STRONG PASSWORD';

Final configuration:

To finish configuration, using a browser visit https://[URL of Server]/pydio and follow the prompts.  Keep in mind the names you used in the steps above for the Pydio database and the Pydio database user, you will need them for configuration.

Marquee Letters and a 555

I actually made this a while ago, but now I finally have some time to post about it.  This whole endeavor started with my wife picking up a set of marquee letters on clearance.  They are basically letters made out of white plastic with LEDs on them.  Construction wise, they are “OK”, the plastic is sturdy enough and the LEDs are bright.  But I was disappointed because the lights did nothing special, they just powered on.

I took a look at my parts drawer to see what I had available to make something more interesting out of these marquee letters.  There were a couple of microcontrollers, some decade counters, resistors, capacitors and quite a few 555 timers (I must have picked up a bunch on clearance somewhere, because I have a lot of them).  Initially I though of using one of the microcontrollers to animate the lights, then I came to my senses.  The 555 timer and a decade counter are the right tools for this job, no need to whip out a microcontroller.

The circuit was simple enough (you can search Google for LED chasers using 555 and pick one) .  I had no issues putting it together and it makes for a good simple light show.  Now off it goes into our son’s room to eat away batteries and amuse him. See video below.

play-sharp-fill