Tag: server

BSD

Install and Configure Hamachi on FreeBSD

Update: Due to protocol changes instituted by LogMeIn on or around July 30 2012, the linux-hamachi client version referenced in the post can no longer be used to login to Hamachi servers. This post will be retained for archival purposes.

In this post I’ll discuss how to install and configure Hamachi and SSH on a machine running FreeBSD. If you’re not familiar with LogMeIn Hamachi (formerly known as just “Hamachi”), it is a hosted VPN service that is capable of establishing secure LAN-like links between computers, even if they’re behind Network Address Translation (NAT) devices. You can use it to create secure virtual networks on demand, across public or private networks.

In order for Hamachi to work, a “mediation server,” operated by the LogMeIn, is required. The mediation server stores machine nicknames, statically allocated 5.0.0.0/8 IP addresses and the associated authentication token of the user. Hamachi is free for non-commercial use. However, the Hamachi security implementation is closed source and as such is not available for review by the general public.

The versions for the software used in this post were as follows:

  • FreeBSD 9.0-RELEASE
  • linux-hamachi-0.9.9.9.20

Install Hamachi

Hamachi requires Linux binary compatibility which is not turned on by default in FreeBSD 8.2-RELEASE. The easiest way to enable this functionality is to load the linux KLD object (“Kernel Loadable Object”) by typing the following as root:

Then add the following line to /etc/rc.conf:

Now we’re ready to install Hamachi. If you’ve installed the FreeBSD ports collection then run the following as root to install the Hamachi port:

Otherwise you can grab the binary package and install it:

Now, let’s configure Hamachi and create our VPN. Hamachi requires the tap kernel driver to create and manage its virtual Ethernet network interface. No worries though, Hamachi adds the script /usr/local/etc/rc.d/hamachi that will automatically load the tap driver if_tap.ko. This driver must be loaded and running before starting Hamachi itself. You can have it load automatically when FreeBSD starts by adding the following line as root to /etc/rc.conf:

If you want only to run Hamachi periodically and not start the tap driver automatically at boot time, you can use forcestart/forcestop as root, which will ignore the setting in /etc/rc.conf:

Our next step generates the cryptographic key pair and creates a directory at ~/.hamachi where Hamachi will store these keys, as well as its configuration and state. This step only needs to be performed once per Hamachi install; however, it must be done for each user account that you plan to use Hamachi from, including root. Consequently, we’ll run the following commands from our user account:

Okay, now let’s start Hamachi. First, make sure the tap driver is loaded by rebooting the machine (assuming the hamachi_enable=”YES” line is in /etc/rc.conf as described above) or by using the forcestart command, then:

When Hamachi is run for the first time, the Hamachi daemon stays offline. Let’s bring it online:

Next, create a nickname for the FreeBSD machine so that we can identify it easily from another machine on your Hamachi VPN:

Now, let’s create our Hamachi VPN. In this step you’ll need to enter a unique name for your network as well as a password for it. If your network name is already in use somewhere you’ll need to keep trying until you land upon one that’s unique. If you’ve setup a Hamachi VPN previously and simply want to add your FreeBSD machine to it, then substitute join for create in the following command:

Now let’s put the FreeBSD machine online on the VPN:

That’s it. Your Hamachi VPN should now be up and running with your FreeBSD machine added as one of the hosts. What if we reboot, do all these commands need to be entered again? The answer is no. Once the Hamachi VPN is created/joined, the nickname established, and the machine added with the go-online command, should you need to reboot your box, you can simply restart the tap driver (assuming you elected not have it start automatically) and then start Hamachi, you’ll then be back online. However, you can also have Hamachi start automatically at boot time by adding a shell script in your system startup sequence. You will of course want to have the tap driver start automatically as well for this to be of any benefit. Here’s a generic version of the script I use:

To use this script simply add your account user name, save it as hamachi_start.sh in /usr/local/etc/rc.d/ and make it executable. You’re free to choose a different name, however, note that scripts within /usr/local/etc/rc.d/ are executed in lexicographical order. Since it is desirable that the existing script hamachi start first in order to load the tap driver, you should name the hamachi start script something that will ensure it starts after hamachi. Numbers may be used as a prefix to the filename.

You can display the status of the Hamachi daemon at any time by running the command hamachi without any arguments:

The following commands will retrieve the nicknames and print a list of the hosts that are currently members of your Hamachi VPN, as well as their Hamachi IP addresses (you will not see the machine you issued the command from listed):

And if needed, you can stop Hamachi with the command hamachi stop:

Now then, to initiate a terminal session with another host on your Hamachi VPN:

If this is the first time connecting, you’ll likely receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. Accept by typing yes and you’ll be presented with the login and password prompt (this warning prompt will only occur once per machine). The public key from the remote host will be stored in ~/.ssh/known_hosts. If you don’t want to have to remember the Hamachi IP address each time you want to run a session with another host, simply add this IP address along with a name (e.g. home-server-ssh) to your hosts file (/etc/hosts). Next time you use Hamachi/SSH to connect to this host, use the name instead of the IP address and the host file will resolve the IP address for you.

SSH Server

Now that we’ve installed Hamachi, created or joined a VPN, and perhaps tested it by connecting to another host on the VPN. Let’s make sure there’s a running SSH server on our FreeBSD machine so that incoming SSH requests can be answered:

Should you need to install sshd, type sysinstall. Select Configure ->Networking and select sshd from among the options. Make sure sshd enabled by checking the /etc/rc.conf file for the line sshd_enable=”YES”. This will load sshd the next time your system starts. You can also start sshd manually as root through the /etc/rc.d/sshd script:

Conclusion

This post described how to install and configure Hamachi on a machine running FreeBSD. The reason I like using LogMeIn Hamachi is that it allows me to connect via SSH, SCP or SFTP to my FreeBSD machine at home from essentially anywhere I have an internet connection without the need to make any changes to my router/gateway. To learn how to install and configure Hamachi on Linux or Windows machines, as well as how to improve the security of the connections over the Hamachi VPN using public key authentication, please see my previous post.

References

http://www.openssh.com/
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/

Linux

How to Install Apache, MySQL and PHP on CrunchBox Linux

So, you’re a CrunchBang Linux user but you want to get a little web development work done? This post will describe how to install and configure Apache, MySQL, and PHP on your box. Once set up, you’ll be able to use your LAMP server to do basic web development and code testing, maintain local copies of your web sites, etc.

The software discussed in this post are free and open source. Apache is licensed under the terms of the Apache License, a free-software license authored by the Apache Software Foundation. MySQL is available under the terms of the GNU GPL. PHP is distributed under the PHP license v3.01, an open source, BSD-style license certified by the Open Source Initiative. The remaining software, phpMyAdmin and WordPress, are not required, however, they are available under the terms of the GNU GPL. The versions for the software discussed in this post are as follows:

  • Apache v2.2.11-2ubuntu2
  • MySQL v5.1.30really5.0.75-0ubuntu10
  • PHP v5.2.6.dfsg.1-3ubuntu4
  • phpMyAdmin v4:3.1.2-1
  • WordPress v2.8.5

Let’s get started.

Install Apache

Let’s grab the latest version of the Apache HTTP server:

Once successfully installed, the Apache server will start automatically. You may notice Apache complaining with “Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName.” No worries, it simply means that Apache could not find a qualified domain name like foo.com in its configuration file. Let’s prevent this message from popping up though by binding the server name to the localhost IP address. Open /etc/apache2/apache2.conf as root and append the following line to the end of the file:

Now restart the Apache server with the following command:

Let’s also make sure now that the server is working. Open a web browser and enter http://localhost. You should see Apache’s time tested “It Works!” message.

Install MySQL.

Now that the Apache HTTP server is up and running, let’s download and install the MySQL server:

During the installation you’ll be asked several times to enter a password. You can leave it blank, but for obvious security reasons and to avoid configuration problems later, I would strongly suggest entering a password. Like Apache, once the MySQL server is installed, it will will start automatically. Now, let’s make sure the server is bound to the local host IP address like we did with Apache. Open /etc/mysql/my.cnf as root and make sure the following line exists. If not, simply append it to the end of the file:

Now restart the MySQL server with the following command:

Install PHP

Almost there. Let’s download and install PHP:

Brilliant. Now let’s test to make sure PHP was installed correctly. Navigate to /var/www/ (Apache’s web root folder) and create the following file:

Open that file as root and enter the following PHP function:

[php light=”true”]

[/php]

Open your web browser and enter http://localhost/phpinfo.php. You should see a page providing some information regarding your PHP installation (See Figure 1).

Screenshot of the of the phpinfo function output

Figure 1

A completely optional but handy package to have for administering your MySQL server is phpMyAdmin. This package gives you the ability to create, copy, rename, alter and drop databases and tables using a web interface instead of the terminal. To install phpMyAdmin:

During the installation you’ll be asked to chose the web server that should be automatically configured to run phpMyAdmin. You’ll want to chose Apache2. PhpMyAdmin will also indicate that it needs to have a database installed and configured before it can be used, and offer to set up a temporary configuration for you using db-config. Since we already have our MySQL server up and running we should choose No here. Once the install finishes, open your web browser and enter http://localhost/phpmyadmin. You should see the logon page for phpMyAdmin (See Figure 2).

Screenshot of the phpMyAdmin logon page

Figure 2

That’s it for the installation. Now let’s move on make sure everything works together.

Testing our LAMP installation using WordPress

WordPress is a full-featured blogging tool (This web site was built using WordPress. The author is not full-featured) that makes heavy use of Apache, MySQL and PHP. We’ll install it on our LAMP server to ensure we have these packages installed correctly. Let’s start by downloading WordPress directly from the developers site. You can also download and install using Aptitude but I don’t recommend it as the repository’s release is a version or two behind the most current release. Navigate to your home directory (or wherever you’d prefer to download the package to) and download and untar the package:

Let’s move the extracted wordpress/ directory to Apache’s web root folder:

Now let’s create an MySQL database for our WordPress installation. Open phpMyAdmin in your browser. Enter root for the Username and the password you set during the MySQL installation (or simply leave this field blank if you skipped entering a password). To create a database, enter a name for it in the Create a new database field. For purposes of our example, let’s use wordpress as the name. Now select Create (See Figure 3).

Screenshot of a database being created through phpMyAdmin

Figure 3

Now we need to do a little pre-configuration on one of the wordpress files in preparation for installation. First, navigate to /var/www/wordpress/. As root, copy the file wp-config-sample.php to wp-config.php. Open the latter file and enter the database name as well as your MySQL login and password. If you chose not to create a password when you installed the MySQL server, make sure to leave two single quotes with nothing in between in DB_PASSWORD. When complete, it should look like the following:

Now let’s install WordPress. Open your web browser and navigate to http://localhost/wordpress/wp-config.php. If everything is configured as it should be you will be greeted with WordPress’s installation wizard (See Figure 4).

Screenshot of the wordpress install wizard

Figure 4

Final thoughts

One issue you may encounter is phpMyAdmin complaining that it can’t load the MySQL extension. More than likely the problem in this case is that phpMyAdmin wants the MySQL PHP module loaded automatically when Apache starts (it isn’t by default). To fix this, open /etc/php5/apache2/php.ini and uncomment following line extension=mysl.so. Save the file and restart Apache.

Finally, you may not want your LAMP server running continuously but rather only when needed. There’s a couple of ways to keep Apache and MySQL from running at boot time. First, you could simply remove their corresponding entries from /etc/rc2.d. A more elegant way to manage these daemons, however, is to download and install sysv-rc-conf.

sysv-rc-conf provides an easy to use interface for managing rc.d symlinks. The interface comes in two different flavors, one that simply allows turning services on or off and another that allows for more fine tuned management of the symlinks. To use it just enter sysv-rc-conf on a command line as root.

When you want to use your LAMP server again you’ll need to start Apache and MySQL from the command line:

Well, that’s it. With a couple of open source packages and a few minutes of your time you can a get a fully configured web server up and running on your CrunchBang Linux box.

References

http://httpd.apache.org/
http://dev.mysql.com/doc/refman/5.1/en/
http://php.net/index.php
http://www.phpmyadmin.net/home_page/index.php
http://wordpress.org/

Networking

Remote Access To Your Ubuntu Server Using PuTTY, Hamachi and SSH

(20130205 – This post has been amended to reflect the most recent version of LogMeIn Hamachi — iceflatline)

This post will describe how to set up a secure virtual private network (VPN) to your Ubuntu home server using the Linux version of LogMeIn Hamachi. Once configured, you’ll be able to use secure shell (SSH) to access and manage your server from anywhere outside of your home network without the need to forward ports or make any other configuration changes on your home network gateway/router.

LogMeIn Hamachi is a hosted VPN service that is capable of establishing secure LAN-like links between computers, even if they’re behind Network Address Translation (NAT) devices. You can use it to create secure virtual networks on demand, across public or private networks. In order for LogMeIn Hamachi to work, a “mediation server,” operated by the LogMeIn, is required. The mediation server stores machine nicknames, statically allocated IPv4 (IP) addresses in the 25.x.x.x range and the associated authentication token of the user. An overview, including protocol-level details of the security architecture employed by LogMeIn can be found at LogMeIn Hamachi.

LogMeIn Hamachi provides three network types for flexibility in meeting diverse use case scenarios. They differ mainly in network topology. LogMeIn Hamachi clients can be members of any network; however, depending on the network owner’s LogMeIn Hamachi subscription, networks have the following limitations:

  • Free subscription allows you to have five members in a network
  • Standard subscription allows you to have 32 members in a network
  • Premium subscription allows you to have 256 members in a network
  • Multi-network subscription or a LogMeIn Central subscription allows you to have 256 members in all your networks

Further information regarding the subscription types can be at LogMeIn Hamachi.

SSH is a open source program for logging into a remote machine and, in most cases, for executing commands on that machine. It provides secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel. It is intended as a replacement for rlogin, rsh and rcp, and can be used to provide other applications with a secure communication channel. To use SSH, you will need to install an SSH client on the computer you connect from (most Linux distributions and Unix variations include an SSH client), and an SSH server on the computer you connect to. The most popular open source SSH client and server are maintained by the OpenSSH project.

The versions for the software used in this post were as follows:

  • LogMeIn Hamachi (Linux) v2.1.0.86-x64 (beta)
  • LogMeIn Hamachi (Windows) v2.1.0.284
  • OpenSSH Server v1:5.9p1-5ubuntu1
  • PuTTY v0.62
  • PuTTYgen v0.62
  • Ubuntu server v12.04 (x64)

So, let’s get started.

Installing the SSH Server

As you may recall, the OpenSSH server is an option you have the opportunity to select when you installed and setup your Ubuntu server. If you did not select that option, you’ll need to install the OpenSSH server manually:

If the SSH server was already installed apt will let you know, otherwise the installation will proceed. When complete, the SSH server daemon will start automatically. To check to make sure it’s running, use the following command:

Install and Configure LogMeIn Hamachi on the Ubuntu Server

The LogMeIn Hamachi Linux client comes as a single executable binary compiled for the platform of your choice. This binary includes the Hamachi daemon, the control application, and the setup utility. However, before we can successfully install LogMeIn Hamachi on our Ubuntu Server we must first install the Linux Standard Base (LSB). LSB is a standard Linux core system that some third-party applications written for Linux, like LogMeIn Hamachi, use for successful implementation across a variety of distributions:

With that dependency out of the way, let’s download the 64-bit Linux version of LogMeIn Hamachi to our Ubuntu server.

Then install it:

After LogMeIn Hamachi is installed it will start up as a background process (daemon) automatically. However, you can stop, start or restart the Hamachi daemon manually from the command line with the following commands:

When the Hamachi daemon is run for the first time it stays offline. Let’s bring it online:

You can change its status back to offline at any time using the following command:

Note that the daemon remembers its state if the Ubuntu server it is shutdown or if shutdown using the sudo /etc/init.d/logmein-hamachi stop command. So if its state was online, it will automatically go online when started next time. If it was offline, it will stay offline.

Next, let’s create a nickname for our Ubuntu server so that we can identify it easily from a remote client machine:

Now, let’s create our LogMeIn Hamachi network. In this step you’ll need to enter a unique name for your network as well as a password for it. If your network name is already in use you’ll need to keep trying until you select one that’s unique. If you’ve previously setup a LogMeIn Hamachi network and want to simply add your server to it, then substitute join for create in the following command:

That’s it. Your LogMeIn Hamachi VPN should be up and running with your Ubuntu server added as one of its member hosts. You can display the status of LogMeIn Hamachi at any time by running the command sudo hamachi without any arguments. To display a full list of all the LogMeIn Hamachi command options, use sudo hamachi -h.

Install and Configure LogMeIn Hamachi on a Linux Client

Now that we’ve installed LogMeIn Hamachi on our Ubuntu Server and created a secure VPN, it’s time to install LogMeIn Hamachi on any Linux-based machines you’d like to use to access your server remotely. You can follow the steps explained above for the Ubuntu server in order to download and install LogMeIn Hamachi on your Linux macbine. Once installed, bring the logmein-hamachi daemon online:

Create a nickname for your remote client machine:

Then join the network you created at the server:

Let’s check to make sure we can see our Ubuntu server on our LogMeIn Hamachi VPN. The following command will your networks (and their hosts) that you are a member of:

Assuming that LogMeIn Hamachi is running on your Ubuntu server, you should see the nickname you created for the Ubuntu server listed, as well as the IP address assigned to it by LogMeIn (e.g., 25.x.x.x). An asterisk next to a host indicates that corresponding machine is currently online (Note: you will not see the machine your’re running the command from listed). Now that we have our Ubuntu server and our remote Linux client machine online, let’s see if we can initiate a terminal session with the server using SSH:

You may receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. If you’re absolutely sure that you are indeed connecting to your Ubuntu server, accept by typing yes and you’ll be presented with the login and password prompt. The public key from your Ubuntu server is stored in ~/.ssh/known_hosts. If you don’t want to have to remember the LogMeIn Hamachi IP address each time you want to run an SSH session with your server, simply add the IP address along with a name (e.g. home-server-ssh) to your hosts file (/etc/hosts). Next time you use LogMeIn Hamachi/SSH to connect to your server, use the name instead of the IP address and the host file will resolve the IP address for you.

Install and Configure LogMeIn Hamachi on a Windows Client

Configuring a Windows machine to access your Ubuntu server remotely is easy too. Download and install the Windows version of LogMeIn Hamachi. When you fire up the application for the first time, LogMeIn Hamachi will be in the offline state. Select the Power On icon on the top left of the application). A pop-up screen will appear asking you to enter the nickname to assign to your remote machine. After it is entered, the application will go online; however, we won’t see our Ubuntu server just yet, we first must add ourselves to the network we created. Select the “Join an existing network” and fill in the name of the network and the password you created when setting up the Ubuntu Server and select “Join”. You should see the name of the LogMeIn Hamachi network we created, as well the LogMeIn Hamachi IP address and nickname for our Ubuntu server appear in the screen (See Figure 1). Once installed, the LogMeIn Hamachi application will start whenever Windows starts and the user has logged in. You’ll find various configuration settings for the application under System->Preferences.

Screenshot of the Hamachi Application

Figure 1

We’re almost there. Now we need to download and install an SSH application (Windows doesn’t support SSH natively). There are many out there to choose from, but the one I typically use is PuTTY, a free implementation of Telnet and SSH for Win32 and Linux/Unix platforms. Download PuTTY.exe (or the Installer version if you’d prefer) and run it. Enter the LogMeIn Hamachi IP address for your Ubuntu server in the Host name field, make sure to select the SSH radio button, and then select “Open” (See Figure 2).

Screenshot of the PuTTY Application

Figure 2

You may receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. If you’re absolutely sure that you are indeed connecting to your Ubuntu server, accept by selecting Yes; a terminal emulator will open and you’ll be presented with the login and password prompt.

If you don’t want to have to remember the LogMeIn Hamachi IP address each time you want to run a session with your server, then simply add the address along with a name of your choice (e.g. home-server-ssh) to your hosts file (/windows/system32/drivers/etc/hosts). Next time you use SSH to connect to your server, use the name instead of the IP address and the hosts file will resolve the IP address for you.

Additional Security

As you may have noticed, we’re using conventional password authentication in order to prove to our Ubuntu server who we claim to be. That may be an acceptable level of authentication considering we’re also authenticating over SSH and a secure VPN tunnel. However, you may want to have a more secure form of authentication. Public key authentication is an alternative means of identifying yourself to your Ubuntu server. Instead of typing a password, you generate a key pair, consisting of a public key (which your server is allowed to know) and a private key (which you keep secret and do not give out). The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key; but anybody who has your public key can verify that a particular signature is genuine. Public key authentication is more secure and more flexible, but a little more difficult to set up. We’ll walk through the steps on both a Linux and a Windows client machine in the follow examples, but in essence what is involved is generating a key pair on our remote client machine, and copying the public key to the Ubuntu server. Then, when the server asks to prove who we are, the SSH application can generate a signature using your private key. The server can verify that signature (since it has your public key) and allow you to log in.

    Linux Client

Let’s set up our remote Linux client for public key authentication. We first need to generate the public/private key pair:

By default the RSA keys are 2048 bits. You can increase this to 4096 bits if desired with the -b option:

You’ll be asked by the script where it should store the keys (~/.ssh is the default), and then asked to enter in a passphrase in order to encrypt the private key that will be stored in this machine. If you don’t want to be asked for a passphrase each time you connect, just press enter. It is up to you to decide whether or not you should password encrypt your key when you create it. However, if you don’t, then anyone gaining access to your private key will automatically have SSH access to the server. After you enter a passphrase and confirm it, or simply hit enter, your encrypted private key (id_rsa) and your public key (id_rsa.pub) are generated and stored in ~/.ssh (assuming you accepted the default directory).

Now that our keys are generated, let’s move the public key to our Ubuntu server. Ensure that LogMeIn Hamachi is running, then enter the following command:

This command will copy your public key to ~/.ssh/authorized_keys on your Ubuntu server. That’s it. Now, next time you use SSH/LogMeIn Hamachi to initiate a session with your server you’ll be asked to provide the passphrase (if you provided one when you generated the keys) for your private key instead of your server password. Congrats, you’re now using public key authentication to login to your server. Once you know your key pair works back up both the public and private keys files to an offline media, such as a USB flash drive or CD.

    Windows Client

Configuring our remote Windows client for public key authentication requires a little more work. First, we need a Windows application that can generate the public/private key pair. We’ll use PuTTYgen, PuTTY’s key generation utility, to perform this task. PuTTYgen is installed automatically if you use the Windows installer version of PuTTY, else you can simply download and use the standalone version of PuTTYgen.

Start PuTTYgen and verify that “SSH-2 RSA” is selected and change the “Number of bits in a generated key” field to 2048 (or more). Select “Generate” where you’ll be asked by PuTTYgen to move your mouse over the applications blank area in order to generate “randomness.” PuTTYgen will then proceed to create your public/private key pair (See Figure 3).

Screenshot of the PuTTYgen application after generating a public/private key pair

Figure 3

You may now enter a passphrase for you private key and confirm it. Again, it’s up to you to decide whether or not to protect your private key with a passphrase. However, electing not to means that anyone gaining access to your private key will have SSH access to the server. You also have the opportunity to modify the “Key comment” field. The default entry is the key type and the date it was created. If you intend on creating additional keys, you may wish to populate this field with something different in order to help you differentiate between the various keys.

When complete, select “Save private key” and choose a file name and a location to save the *.ppk file. Next, carefully copy the text contained in the “Public key for pasting into OpenSSH authorized_keys file” box into a text file and save it. Using a program like WinSCP copy the text file to your user account on the Ubuntu server. Now, login to this account and append the contents of this text file to the file ~/.ssh/authorized_keys and make sure permissions are set correctly:

We’re done with PuTTYgen so let’s exit the program. Now fire up PuTTY and navigate to Connection->SSH->Auth. Under Authentication parameters select the Browse button and select the *.ppk file you saved in the previous step (See Figure 4). Now, navigate back up to Session and enter the LogMeIn Hamachi IP address for your server in the Host name field, make sure to select the SSH radio button, and then select Open (of course, LogMeIn Hamachi should be running). You may receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. Accept by selecting Yes; you’ll be asked to provide the passphrase (if you created one) for your private key instead of your server password. Congrats, you’re now using public key authentication to login to your server. Once you know your key pair works back up both the public and private keys files to an offline media, such as a USB flash drive or CD.

Screenshot Showing the Private Key Load Screen in the PuTTY Application

Figure 4

Now that we have public key authentication set up, you may be wondering if you can still logon to the server without a private key? In other words, can you still use your server username and password? The answer is yes. However, that can be changed. After you’re sure that public key authentication is working on the remote machines you’ll be using to access your Ubuntu server, you may want to consider shutting down password authentication. To do that, logon on to your server and open the OpenSSH server’s config file (/etc/ssh/sshd_config). Look for the line #PasswordAuthentication yes and change it to PasswordAuthentication no (Make sure to uncomment the line). Then restart the SSH server with the following command:

Conclusion

Good times eh? Using some open source tools and LogMeIn Hamachi, we set up a secure VPN between remote Windows and Linux clients, and our Ubuntu server. And, we didn’t have to touch our home gateway/router. We also improved the security of the network by using public key authentication.

References

https://help.ubuntu.com/community/SSH/OpenSSH/Keys
http://the.earth.li/~sgtatham/putty/0.60/htmldoc/
http://www.openssh.com/
http://www.ibm.com/developerworks/library/l-keyc.html

Networking

How to Install and Configure MRTG on Ubuntu Server

(20161025 – The software versions used in this post were updated — iceflatline)

(20150902 – The steps and script in this post were amended to remove logging — iceflatline)

This post will describe how to install and configure Tobi Oetiker’s MRTG (Multi Router Traffic Grapher) on your Ubuntu server. All steps assume that the Apache http server is installed and operating correctly. Once configured, you’ll be able to use MRTG to monitor the traffic in and out of your network using the SNMP capability in your network’s gateway\router. MRTG generates static HTML pages containing PNG images which provide a visual representation of this traffic. MRTG typically produces daily, weekly, monthly, and yearly graphs. MRTG is written in perl and works on Unix/Linux as well as Windows. MRTG is free software licensed under the GNU GPL.

Software versions used in this post were as follows:

  • Ubuntu Server v16.04.1 x64 LTS)
  • mrtg v2.17.4-3ubuntu1

So, let’s get started.

Download and Install

First, update your package list:

Then download and install MRTG:

If this is the first time installing MRTG on your server you’ll likely be presented with the following message (See Figure 1). Answering “Yes” means that the MRTG configuration file will not be readable by others (file permissions set to 640). Answering “No” means that the file is readable by others (file permissions set to 644). In this example we’re going to accept the default Yes.

Screenshot showing install message regarding MRTG file permissions

Figure 1

MRTG installs a sample configuration file /etc/mrtg.cfg used to hold the SNMP information obtained from your gateway\router. For a full listing of what MRTG installs and where, run the locate command:

Technically speaking, mrtg.cfg could remain in /etc, but just to keep things tidy let’s create a directory for it and move it into that directory:

That’s it for installing MRTG. Now let’s move on and configure it.

Configure

MRTG includes a script called cfgmaker that will help us populate /etc/mrtg/mrtg.cfg with the information obtained from your gateway\router. But before you run cfgmaker, you should setup the SNMP service in your gateway\router. This usually involves logging into your gateway\router and enabling SNMP. The default SNMP community name is typically “public.” If you change the SNMP community name to something else, make note of it. Now, run the following command, substituting your SNMP community name, if you’ve changed it, and adding the IP address of your gateway\router:

If you would like to add more than one gateway\router to MRTG simply append the additional URL(s) to the same mrtg.cfg file. Then, when you build the web page using the indexmaker command described below, all the gateway\routers (and their associated graphs) will be displayed on the same HTML page.

Next, open /etc/mrtg/mrtg.cfg and make sure under Global Configuration Options that the lines “WorkDir: /var/www/mrtg” (under Debian), and “Options[_]: growright, bits” (under Global Defaults) are uncommented. Finally, add the following lines to the existing line EnableIPv6: no under the Global Defaults section:

What does all this do? The line RunAsDaemon: Yes will enable MRTG to…um… run as a daemon. This is beneficial because MRTG is launched only once, thus the parsing of the /etc/mrtg/mrtg.cfg file is done only once, not repeatedly as would be the case if one were to run MRTG as a cron task – another acceptable method for running MRTG. Also, when running as a daemon, MRTG itself is responsible for timing the measurement intervals; therefore, we need to add the Interval line option and assign it a value – in this example 5. This means that every five minutes MRTG will poll the SNMP service in your gateway\router and update its graphs. Finally, since many gateway\routers do not currently support SNMP over IPv6, we’ll retain the line EnableIPv6: no.

Speaking of graphs, by default MRTG graphs grow to the left, so by adding the option “growright” the direction of the traffic visible in MRTG’s graphs flips causing the current time to be at the right edge of the graph and the history values to the left. We’ve also chosen the “bits” option, which means that the monitored traffic values obtained from your gateway\router are multiplied by 8 and displayed bits per second instead of bytes per second.

Okay, now it’s time to create the web pages which display the MRTG graphs using the indexmaker command. Run the following commands:

Open /etc/apache2/apache2.conf and add the following lines in the section containing similar Directory directives:

Then restart Apache:

When restarting Apache you may receive a warning concerning its inability to “…reliably determine the server’s fully qualified domain name…” This non-critical error can be fixed by adding the following line to /etc/apache2/apache2.conf:

MRTG has been configured. Let’s start it up and see what it displays.

Start

There’s something important to keep in mind when starting MRTG, and that is that MRTG requires the environmental variable “LANG” to be C in order to run properly. Since most Linux systems these days, including Ubuntu server, use UTF-8 (run echo $LANG to see what your system uses), let’s change LANG to C and start MRTG using the following command:

When you run MRTG for the first time you may see a lot of complaints about missing log files. No worries, this is normal for the first 2-3 times you start MRTG this way. If, however, it continues to complain you may want to look into the source of the problem.

Well, that’s it. Now point your browser to http://your-server-address/mrtg and you should see a page that resembles Figure 2. You may have more or less graphs depending on the number of interfaces reported by your gateway\router(s).

Screenshot showing the default MRTG web page

Figure 2

Because of the aforementioned option in /etc/mrtg/mrtg.cfg, you’ll see the graph starting “grow” to the right as the traffic is monitored over time, and the Y axis displayed as bits per second. If you click on any one of these graphs you’ll be taken to another page showing individual graphs for 30 minute, two hour, and daily averages, along with the maximum, average, and current bit rate in and out of that particular interface. Only interested in displaying one particular interface? Want to graph other SNMP data? No worries, just remember to run indexmaker again to update the MRTG index.html file.

Okay, so now that we have MRTG installed, configured and running let’s move on and discuss how to keep it running.

Operate

Starting MRTG by hand is not ideal in the long run. So perhaps after you’ve done some tweaking on MRTG and are satisfied with the results, you can automate the process of running MRTG by using a startup script in your system startup sequence. Here’s the script that I use:

To use the script, save it to your home directory as mrtg and make it executable. Then move or copy it to /etc/init.d:

Now, link the mrtg script to all of Ubuntu server’s multi-user run levels (2-5):

Now, let’s start MRTG using our script. If it’s currently running then substitute restart for start in the following command:

That’s it. Now if for some reason your server is rebooted, MRTG should fire up automatically. If you would like to remove the MRTG script from the server’s multi-user run levels, use the command sudo update-rc.d -f mrtg remove).

Conclusion

This concludes the post on how to install and configure MRTG on Ubuntu server. As you can see, MRTG isn’t terribly complicated and proves to be a really nice open source package for monitoring and displaying traffic in and out your network from virtually anywhere you have a web browser. For a full list of all the configuration options and other information I encourage you to visit the MRTG web site.

References

http://oss.oetiker.ch/mrtg/doc/index.en.html