iceflatline

NAS4free is an open source NAS (“Network Attached Storage”) platform based on FreeBSD that supports file sharing across Windows, Apple, and UNIX-like systems. Support for ZFS, Software RAID (0,1,5), disk encryption, S.M.A.R.T, email reports, CIFS FTP, NFS, TFTP, AFP, RSYNC, Unison, iSCSI, HAST, CARP, Bridge, UPnP, and Bittorent, are among its many features – all configurable through its GUI interface. NAS4Free can be installed on Compact Flash or USB flash drive, hard disk or booted into a “LiveCD” environment. NAS4Free code and documentation are released under the Simplified BSD License.

The ZFS (“Zetabyte File System”) is a combined file system and logical volume manager designed by Sun Microsystems. The features of ZFS include protection against data corruption, support for high storage capacities, snapshots and clones, continuous integrity checking and automatic repair. ZFS is implemented as open-source software, licensed under the Common Development and Distribution License (CDDL).

This post will describe how to setup a simple, yet resilient, ZFS-based RAID 1 (ZFS mirror) in NAS4Free. In RAID 1, data is written identically to two disk drives, thereby producing a “mirrored” set. If one disk becomes defective, the remaining disk still contains all the data. To help explain the steps involved, we’ll use two new 2TB (Terabyte) SATA 3.0 hard disks, along with the ZFS utilities available within NAS4Free, to create and configure our ZFS mirror. We’ll also discuss a few post-install activities to help maintain your ZFS mirror. All steps involved assume that the two hard drives have been installed correctly and are recognized by the BIOS, and that NAS4Free is installed and operational. The software versions used in this post were as follows:

NAS4Free v9.1.0.1 – Sandstorm (revision 636)

So, let’s get started.

Adding the Disks

The first thing we need to do is logically add the two new disks to NAS4Free so the system acknowledges their existence, permitting further configuration on them. Log in to the NAS4Free GUI (“Graphical User Interface”), navigate to Disks->Management, and select the “+” icon. (See Figure 1).

In the subsequent page you are presented with the configuration screen for adding new disks. Select the first 2TB disk from the drop-down menu under the “Disk” field, and select “unformatted” from among the options in the drop-down menu under the “Preformatted file system” field. The remaining options on this page can retain their default settings. Now select “Add” (See Figure 2).

Repeat these steps for the second 2TB disk. When complete, select “Apply changes” (See Figure 3).

Note: If you’re adding disks that have previously been formatted using ZFS, NAS4Free will likely not allow you to add these disks as unformatted. You can, however, add them by selecting “zfs storage pool device” under the “Preformatted file system” field and skip the following formatting step.

Format the Disks

Now that the disks have been added, we need to format them. Navigate to Disks->Format, and select one of the newly added disks from the drop-down menu under the “Disk” field. Select “ZFS storage pool device” from the drop-down menu under the “File system” field, then select “Format disk” (See Figure 4).

Repeat these steps for the second disk, then navigate back to Disks->Management and ensure that both disks are present and formatted as ZFS storage pool devices (See Figure 5).

Create a ZFS Virtual Device

We’ve added our two 2TB hard disks and formatted them. Now its time to create a ZFS “vdev” or virtual device.

Unlike traditional file systems, which reside on single devices and require a volume manager to use more than one device, ZFS filesystems are built on top of virtual storage pools called “zpools.” A zpool is constructed of virtual devices, or “vdevs,” which are themselves constructed of block devices: files, hard disk partitions, or entire disks, with the latter being the recommended usage. Block devices within a vdev may be configured in different ways, depending on needs and space available: non-redundantly (similar to RAID 0), as a mirror (RAID 1) of two or more devices, which is the focus of this post, or as a RAID-Z (similar to RAID-5) group of three or more devices.

In summary then, a vdev represents the disk drives that are used to create a zpool. A zpool can have any number of vdevs at the top of the configuration, known as a “root vdev.” If the top-level virtual devices contain two or more physical devices, the configuration provides data redundancy as mirror or RAID-Z virtual devices.

To create a virtual device consisting of our newly added hard disks, navigate to Disks->ZFS->Pools->Virtual device, and select the “+” icon. In the subsequent page, enter a name for the new virtual device under the “Name” field (e.g., “vd_1″), and select “Mirror” from among the options under the “Type” field. Now select both hard disks in the “Devices” field by holding the CTRL key and left-clicking each disk. You can also enter a description for the virtual device under the “Description” field, if desired. Select “Save” when complete (See Figure 6).

Create a ZFS Pool

Having created our vdev, let’s move on and create a zpool. Navigate to Disks->ZFS->Pools->Management, and select the “+” icon. In the subsequent page, enter a name for the new zpool under the “Name” field (e.g., pool_1). You should see the vdev created previously listed under the “Virtual devices” field. Select the vdev by left-clicking on it. Add a description for the virtual device under the “Description” field if desired. The remaining options can retain their default settings, resulting in the mount point for the zpool becoming /mnt/[your-zpool-name]. Select “Save” when complete (See Figure 7).

Create a ZFS Dataset

At this point you could start using your entire zpool as storage if desired. However, a significant feature of ZFS is the concept of “datasets.” A dataset is essentially a child filesystem of the parent zpool. Imagine that the zpool is a single hard disk. In a typical hard disk you would create a single, disk-sized partition, and then format that partition with a filesystem. But if later you’d like to add additional filesystems to the disk, you have to erase and redo your partition to create more partitions to contain the new filesystems, or use a tool to actively resize existing partition, and then create the new partitions and filesystems.

With datasets, all of these partitioning efforts are unnecessary. A ZFS dataset acts like another mounted partition with no locked-in size. The quantity of disk space it takes up is only as much space as you use in populating it, or children datasets of it (of course, it can never be larger than the size of its parent zpool). You don’t have to worry about resizing partitions as ZFS inherently handles all that for you. Additionally, each dataset can have its own special configuration by modifying different behavioral variables. For example, you can determine quota and permissions independently for each dataset. Finally, datasets provide more flexibility if you need to snapshot or clone your filesystems.

To add a dataset to the zpool, navigate to Disks->ZFS->Datasets->Dataset, and select the “+” icon. Enter a name (e.g., “files”) in the “Name” field (resulting in the mount point for the dataset becoming /mnt/[your-zpool-name]/[your-dataset-name]). Ensure that the zpool created previously is selected from the drop-down list under the “Pool” field. If you’re interested in performing periodic snapshots of the dataset (discussed below), I recommend enabling the “Snapshot Visibilty” option so that the snapshots are added automatically to /mnt/[your-zpool-name]/[your-dataset-name])/.zfs/snapshots. The remaining options can be configured according to your requirements. Select “Add” when complete (See Figure 8).

Wrapping up

We’ve successfully added two new 2TB hard disks to NAS4Free and formatted them, created a vdev and a zpool, and finally, created a dataset within our zpool. At this point you can start enabling services such as CIFS, NFS, UPnP, etc., to take advantage of your new ZFS mirror storage. Remember, when configuring some of these services to select the correct mount point for your dataset (e.g., /mnt/pool_1/files).

With the creation and configuration of our ZFS mirror out of the way, let’s move on talk about a few maintenance activities that should prove useful.

Replacing a defective hard disk

Occasionally you may have to replace a hard disk in your zpool that has become defective. To perform the replacement, navigate to Disks->ZFS->Pools->Information and note which disk is defective or missing (e.g. ada2). Next, navigate to Disks->ZFS->Pools->Tools and offline the disk if possible by selecting “offline” from the drop-down list under the “Command” field. Ensure that “Device” is selected under the “Option” field and that the correct pool is selected under the “Pool” field. Use the checkbox to select the defective disk under the “Devices” field, then select “Send Command!” (See Figure 9).

Power down NAS4Free, then identify and replace the defective disk with one of equal storage capacity using, if possible, the same SATA port [Pro-tip: Take the time to label your disks correctly (e.g. ada2) when you install them. It will make physically identifying the defective disk much easier!]. Restart NAS4Free and navigate to Disks->ZFS->Pools->Information to verify the device name for the new disk. If you were able to reuse the same SATA port, the device name should be same as the defective disk (e.g. ada2). Navigate to Disks->ZFS->Pools->Tools and replace the disk by selecting “replace” from the drop-down list under the “Command” field. Ensure that “Device” is selected under the “Option” field and that the correct pool is selected under the “Pool” field. Use the checkbox to select the defective disk under the “Devices” field and the new disk from the drop-down list under the “New Device” field, then select the “Send Command!” The replacement disk should resilver fairly quickly. Verify by navigating to Disks->ZFS->Pools->Information

Creating and managing snapshots

One of the many great features about using ZFS is its snapshot capability. A snapshot is a read-only reference to the state of a dataset at the moment the snapshot was taken. It is a reference, and not copy, because at the moment it is taken, it takes up no additional space. However, as data within the dataset changes, either because files are modified or deleted, the snapshot consumes disk space by continuing to reference the old data. This behavior allows you to easily recover files if necessary, but in doing so prevents disk space from being freed until the snapshot is deleted.

To take a snapshot manually, navigate to Disks->ZFS->Snapshots->Snapshot, and select the dataset you want to snapshot (e.g., pool_1/files) from under the “Path” field. Enter a name for the snapshot (e.g., snapshot_1), enable “Recursive” option, then select “Add” (See Figure 10).

NAS4Free also provides the ability to configure reoccurring snapshots under Disks->ZFS->Snapshots->Auto Snapshot. Here you can schedule a time the system should perform the snapshot and how long it should retain them, resulting in the oldest snapshot being deleted when the deadline is reached.

You have a couple of options when it comes to “rolling back” to a particular snapshot. In fact, though , rolling back is a slight misnomer, because what you’re really doing is locating the snapshot you’re interested in and copying over the files you’d like to recover. If you selected the option “Snapshot Visibility” when setting up your dataset in NAS4Free (See Disks->ZFS->Datasets->Dataset->Edit), then all snapshots for that dataset will be located in that filesystem under the directory /.zfs/snapshot (e.g., /mnt/pool_1/files/.zfs/snapshot). This allows you to simply navigate to the snapshot directory your interested in and copy files from that directory to the current filesystem.

Another way you can recover files from snapshots is to clone one to another directory. This approach has the advantage of allowing you to share out the cloned snapshot directory, say using CIFS or NFS, for some period of time until files are recovered. To clone a snapshot, navigate to Disks->ZFS->Snapshots->Snapshot and edit the snapshot you’re interested in cloning by selecting the small wrench icon. Ensure that “Clone” is selected under the “Action” field, then enter a path to the directory where the clone is to reside. Note that this path must be expressed as a relative path. So, for example, pool_1/files/oldfiles would work, but /mnt/pool_1/files/oldfiles would not, nor would /pool_1/files/oldfiles. Also note that the directory where the snapshot will be cloned does not have to be created in advance, rather it will be created automatically for you when you clone the snapshot. Now, select “Execute” when finished and your cloned snapshot will be available for use at the path you specified (e.g. /mnt/pool_1/files/oldfiles) (See Figure 11). Cloned snapshots can be destroyed at anytime by navigating to Disks->ZFS->Snapshots->Clone.

Data scrubbing

Performing a ZFS “scrub” on a regular basis helps to identify data integrity problems, detect silent data corruptions caused by transient hardware issues, and to provide early alerts to disk failures. This operation traverses all the data in the zpool once and verifies that all blocks can be read. Scrubbing proceeds as fast as the vdevs will allow, though the priority of any disk I/O generally remains below that of normal operations. So, while the scrub operation might negatively impact performance slightly, the zpool’s data should remain usable and nearly as responsive while the scrubbing occurs.

To schedule and manage scrubs on a ZFS zpool in NAS4Free, we’ll set up a cron job to run the zpool scrub command. Navigate to System->Advanced, and select the Cron tab. Ensure that the “Enable” checkbox is selected, then enter the command zpool scrub [your-pool-name] in the “Command” field. Ensure that the command is run as the root user and enter a description for the cron job if desired. Now select when you’d like the command to run in the “Scheduled time” field. If you have consumer-quality drives, consider a weekly scrubbing schedule. If you have data center-quality drives, consider a monthly scrubbing schedule. Also note that depending upon the amount of data in the zpool, a scrub can take a long time. Consequently, you may want to consider scheduling them for evenings or weekends to minimize the impact on performance. When complete, select “Add”, then “Apply changes”. The example shown in Figure 12 shows the command zpool scrub pool_1 will run every Sunday at 1300 local time.

Conclusion

This post described how to create and maintain a simple, yet resilient, ZFS mirror in NAS4Free, an open source NAS implementation based on FreeBSD.

References

http://wiki.nas4free.org/doku.php

Occasionally I find myself needing to mount a remote file system on a local *BSD or Linux machine. On one such occasion recently I had mounted an NFS file system from a Network Attached Storage (NAS) server to a local machine running FreeBSD, for the purpose of backing up some of the files to yet another machine offsite using the rsync utility. I had created a little script to run rsync periodically through cron. This script worked well until I noticed a few days later that the backups on the remote machine no longer existed. After some investigation I quickly determined that NAS file system was no longer mounted on the FreeBSD machine (I can neither confirm or deny that I may have configured something incorrectly). The rsync script, upon noticing that files no longer existed in the source, deleted said files at the target. It was at that point that I decided to include a small test in the rsync script to check on the existence of the mounted file system; then, if it still existed, the script would proceed with the rsync command, else it would write an error message to a log. Here is the code snippet I used in the script, which you can easily adapt for other situations:

df | grep -q /mnt/files
if [ $? = 0 ]; then
        $RSYNC $OPTIONS $SOURCE $TARGET >> $LOG 2>&1
else
        echo $ERR_MSG >> $LOG
fi

The df command simply displays statistics about the amount of free disk space on the specified file system. If a file system argument is not specified, statistics for all mounted file systems are displayed. The output of the df command is then piped through the venerable grep utility using its -q option, which instructs grep not to write anything to standard output, but rather exit immediately with a zero status if a match is found. Finally, the file system we’re interested in matching to, parsed from the output of the df command, is provided to grep. If the output of this df command is zero, the script runs a command (in this case my rsync command), else if it exits with anything other than zero, the script runs another command instead (in this case an error message).

Last week I recieved a “pingback” on this post. I was curious about what may have been discussed so I navigated to the site and discovered they had simply scraped the entire post, representing it as their own. Content scraping is nothing new of course and happens all the time on large, popular sites, but this was the first time this happened to me, to something I wrote. I was a little taken aback by how blantant it was.

I reached out the offending site’s administrator to request that he/she conform to the terms of the Creative Commons Attribution 3.0 license by providing attribution, or remove the content. I had little hope that they would comply, much less respond, and had resigned myself to hoping that Google could sort out which content source would be authoritative when it came to search queries. I was pleasantly surprised then when roughly a day later I received an e-mail from the site’s administrator admitting to copying the content (“because it’s beautiful”), but more importantly agreeing to attribute the content to me. We agreed on the following notice, which was placed at the bottom of the (copied) post: “This article was originally published at http://www.iceflatline.com/2011/11/how-to-install-apache-mysql-php-and-phpmyadmin-on-freebsd/ and is reprinted here with the author’s permission.”

All of the content I post here at www.iceflatline.com is provided under the Creative Commons Attribution 3.0 license. What this means is that you are free to copy, distribute and transmit this content, to adapt it to something you may be working on, even make commercial use of the content. All I ask is that you attribute the original content to me in some way.

The Ports Collection is a set of Makefile, patches, and description files stored in /usr/ports. This set of files is used for building and installing applications on FreeBSD, and other BSD-based operating systems.

This post will describe how to use portmaster, a utility for updating installed ports. portmaster is nothing more than a shell script (albeit a quite elegant and powerful one), written in /bin/sh. It does not depend upon other ports, external databases or languages, rather it’s been written in such a way as to make use of the information about a port’s dependencies, dependents, file locations and other information contained in /var/db/pkg to determine which ports to update.

The versions of software discussed in this post are as follows:

FreeBSD 9.1-RELEASE

portmaster-3.14_9

Okay, let’s get started. All commands are issued as the root user or by simulating the root user by using the command su. Let’s make sure that the Ports Collection is updated to its most current version with the following command:

portsnap fetch update

If you haven’t installed portmaster yet, let’s do that now. You’ll be prompted with several configuration options. Select any options you’d like and select “OK”:

cd /usr/ports/ports-mgmt/portmaster
make install clean
rehash

Now that the Ports Collection has been updated and portmaster installed, let’s check the installed ports against the updated Ports Collection to see whether any installed ports need to be updated. portmaster provides a way to list ports that need updating using the -L option:

portmaster -L | more

As you’ll see in the corresponding output of this command that portmaster groups all installed ports into four categories:

Root ports: port listed under this category have no dependencies, nor are they depended on by other ports.

Trunk ports: ports listed under this category have no dependencies, but other ports depend upon them.

Branch ports: ports listed under this category have dependencies and are also depended upon by other ports.

Leaf ports: Ports listed under this category have dependencies but are not depended upon by other ports.

Each installed port will be listed in one of these categories along with whether the port has a revised version available:

===>>> Root ports (No dependencies, not depended on)
===>>> bigreqsproto-1.1.1
===>>> inputproto-2.0.2
===>>> libcheck-0.9.8
===>>> libtool-2.4.2
===>>> lsof-4.87.a,7
        ===>>> New version available: lsof-4.87,8

Following the list portmaster will present a succinct summary of the status of your ports:

===>>> 96 total installed ports
        ===>>> 32 have new versions available

Before updating a particular port or ports, it’s a good idea to check the notes contained in /usr/ports/UPDATING to see if there are any issues related to updating one or more of them. /usr/ports/UPDATING contains all the last minute notes on all of the ports in the Ports Collection and documents, where applicable, some of the problems you may encounter when updating, and/or additional features or options that may be available. You could review this file line by line, comparing its contents with those ports determined by portmaster to have updates; however, there is a much easier to perform this task using pkg_updating, a utility for displaying only the entries in /usr/ports/UPDATING that pertain to the ports currently installed on the system. Here’s a couple of examples of how to use pkg_updating:

To show any entries in /usr/ports/UPDATING that pertain to the currently installed ports, simply use pkg_updating with no options:

pkg_updating 

To show only those entries that affect the currently installed ports after a specific date, use the -d option:

pkg_updating -d 20121001

The above command will list the /usr/ports/UPDATING entries that affect the currently installed ports since October 1, 2012. This is a good option to use to when you want to show only those entries that affect your ports since the last time you updated them.

How about only those entries that pertain to a select port or ports? The following command will show any entries for ports apache22 and php5:

pkg_updating apache22 php5

And this list could be narrowed even further by adding the -d option to show only those entries that affect these two ports since a certain date:

pkg_updating -d 20121001 apache22 php5

Follow the instructions contained in /usr/ports/UPDATING to update the affected ports. In most every case there will be instructions for how to use portmaster to perform the task. The remaining ports can be updated using the following command:

portmaster -dwv <portname>

The -d option tells portmaster to clean up the installation files (in /usr/ports/distfiles), which will help save some disk space. The -w option tells portmaster to save old shared libraries (in /usr/local/lib/compat/pkg/) before “deinstalling” the existing port, allowing those libraries to potentially be restored if there are any incompatibility issues between the new port and the installed libraries. Adding the -v option will direct portmaster to be a bit more forthcoming about what it’s doing. Finally, the name of the port should be one of the following: the full name of the port directory as specified in /var/db/pkg, for example apache22-2.2.23_3 or the full path to the port in the Ports Collection, for example /usr/ports/www/apache22.

After entering the command above portmaster will recurse through the port and its dependencies (if any) to handle any configuration options. If configuration options have changed since the last time the port was updated, portmaster will likely prompt for input. However, you can force the configuration dialogs for all ports by adding the force-config option to the command:

portmaster -dwv --force-config <portname>

If none of the port’s dependencies require updating, portmaster will simply download the necessary source files and perform the update, otherwise you will be presented a list of ports that will be updated and asked to confirm before portmaster proceeds. You can skip the confirmation step by adding the no-confirm option to the command:

portmaster -dwv --no-confirm <portname>

You can also update all of the outdated ports at once using the following command:

portmaster -adwv 

The -a options tells portmaster to review all installed ports and update them if necessary. Once again, if portmaster is unclear about the configuration options for a particular port, it will prompt for input, otherwise it will present a list of ports that it will update and ask to confirm before proceeding. The force-config and no-confirm options can be used here as well, if desired.

Adding the -x option will direct portmaster to avoid building or updating ports that match a pattern. For example, the following will update all installed ports except apache22:

portmaster -adwv -x apache22

The portmaster utility also provides some other useful functions. For example, portmaster can be used as a port installation tool by executing it as though you were updating a port. portmaster will recognize that it’s a new port and install the port’s dependencies as usual:

portmaster -dwv /usr/ports/www/apache22

Sometimes it’s helpful to have portmaster figure out what needs to be updated and in what order, but not actually do it. Adding the -n option directs portmaster to run through the configuration, but not actually update or install any ports

portmaster -nadwv 

There you have it. The portmaster utility is a simple yet powerful tool for updating your ports. It does not depend on other software or use an external database to track what you have installed, but rather uses the existing ports infrastructure, including what is located in /var/db/pkg. This post covered the basics. The portmaster man page contains a lot more information about portmaster, how it works and what choices are available to you.

This post describes how to securely login to your web site using an SSH (“Secure Shell”) tunnel created using dynamic SSH port forwarding. You will need to have access to an SSH connection to your web hosting account. Most web hosts should be able to provide you with one. While this post uses a WordPress-based web site as an example, the techniques described should be able to be applied to any web site so long as the web host permits SSH connections.

Introduction

A SSH tunnel consists of an encrypted data path created through a SSH protocol connection. A SSH tunnel can be used to transfer unencrypted traffic over an IP network, such as the public Internet, through an encrypted channel. Why use an SSH tunnel to login into your WordPress web site? In brief, better security. Unless you already have SSL configured on the server and have WordPress correctly configured to force SSL logins, your login name and password are passed in the clear each time you login to administer the site. Dynamic SSH port forwarding transforms the SSH client on a local machine into a SOCKS proxy server. Any traffic sent to the proxy will be sent to the SSH server, which will forward that traffic as its own firewall and routing rules permit. We can use this capability to our advantage to forward login credentials over the SSH connection to WordPress more securely.

To set up an SSH tunnel using dynamic SSH port forwarding, a port number is chosen for use as the SOCKS server port. Whenever a connection is made to this port, all traffic is forwarded to the SSH server, and the application protocol is then used to determine where to connect to from the SSH server. In our case that protocol is HTTP and our web browser must be configured specifically to use the proxy server (and must reconfigured when you stop using the proxy server). For purposes of example, we’ll use the standards SOCKS port 1080 (technically, you can use any port number, however be aware that some programs will only work if you use 1080), and Firefox as the web browser, and we’ll assume that the web host’s SSH server is listening for incoming connections on the SSH default port 22.

Dynamic Port Forwarding On Linux/Unix

Creating a SSH tunnel using dynamic port forwarding on a Linux/Unix system is quite easy. Simply start a termnal session and enter the following command:

ssh -D <port> <user@hostname>

The -D option specifies a local “dynamic” application-level port forwarding and the port parameter is the port chosen for the proxy server to listen on. The user@hostname parameter is the remote SSH server and associated account where you will forward your connection. In our case user will typically be your web host account user name and hostname will typically be your web site’s domain name. For example:

ssh -D 1080 iceflatline@iceflatline.com

If your web host’s SSH server is listening for connections a port other than 22 then you can specify the correct port in the command using the -p option, for example:

ssh -D 1080 -p 2022 iceflatline@iceflatline.com

If this is the first time you’ve attempted to connect to your web host provider using SSH, you’ll likely receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public key and asked if you’re sure you want to continue connecting. If you’re absolutely sure that you’re indeed connecting to your host provider, accept by entering Yes. You’re then typically requested to enter your account password and the connection will proceed. The command prompt should be returned to you without error indicating that tunnel was established successfully.

Now open Firefox and navigate to Tools->Options->Advanced->Network and select “Settings” (Note: in some implementations of Firefox, particularly on Linux, network connection settings are found under Edit->Preferences->Advanced->Network). Select “Manual proxy configuration” and enter localhost in the “SOCKS Host:” field and 1080 in the associated “Port” field, then select “OK” and once again in the Options menu to close it out. (See Figure 1).

Now simply point your browser to your WordPress login URL – usually your-web-site-url/wp-admin or your-web-site-url/wp-login.php – where you can login securely over your newly created SSH tunnel to administer the site. Note that you must maintain the SSH connection in order to maintain your connection to the web site. When finished using the tunnel, simply exit the terminal session that is maintaining the SSH connection and return Firefox to its default “no proxy’ settings.

Dynamic Port Forwarding On Windows

Creating an SSH tunnel using dynamic port forwarding on a Windows system is also easy; however, we’ll first need to download and install an SSH application (Windows doesn’t support SSH natively). There are several 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 your web site domain name in the “Host Name (or IP address)” field. If your web host’s SSH server is listening for connections a port other than 22 then modify the “port” field to reflect the correct port number (See Figure 2).

Next, under the “Category” column on the left side of the application, navigate to Connection->SSH->Tunnels. Enter 1080 in the “Source port” field and select the “Dynamic” radio button, then select “Add” (See Figure 3).

Now select “Open” to initiate the connection. If this is the first time you’ve attempted to connect to your web host provider using SSH, you’ll likely receive a popup from the PuTTY application with a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public key. If you’re absolutely sure that you are indeed connecting to your host provider, select “Yes” to add the public key to PuTTY’s cache and carry on connecting. Alternatively, if want to connect just once, without adding the key to the cache, select “No”. You’re then typically requested to enter your account password and the connection will proceed. The command prompt should be returned to you without error indicating that tunnel was established successfully.

Now open Firefox and configure the settings as described above in the Linux section. When complete, point your browser to your WordPress login URL where you can login securely over your newly created SSH tunnel to administer the site. Note that you must maintain the SSH connection (i.e., the PuTTY window must remain open) in order to maintain your connection to the web site. When finished using the tunnel, simply exit the terminal session that PuTTY created for the SSH connection and return Firefox to its default no proxy settings.

Conclusion
Well, there you have it. Would obtaining an SSL certificate be simplier? Perhaps. But until you do here’s a way to login more securely to your WordPress web site using an SSH tunnel created using dynamic SSH port forwarding.

References

Lucas, M. SSH Mastery. USA: Tilted Windmill Press, 2012. Print.