prerequisite concepts: prelude, basic configuration, port forwarding

Network address translation (NAT) is a very common method of providing secure access to hosts on a private network. Given the limited amount of IPv4 addresses, computer networks with relatively few, very few, and even a single public IP address are common. A typical small business customer of my consulting practice has one or more Linux servers on an office network protected by a firewall. The following is a close look at Example Industries, the theoretical owners of example.com; this customer receives support for two Linux servers, a mail server and a PBX, but only one public IP address between them. Through NAT, public services (namely mail and VoIP) on both servers are accessible via example.com. This works well for inbound mail and phone calls, which only need to access one or the other host, but SSH access is the lifeblood of remote system administration, and there’s the rub– when I enter ssh example.com I land at the mail server. SSH access to the PBX would seemingly threaten to litter my command line with unsightly extra characters, if not subsequent commands outright.

My carpals are tunneled enough, I don’t want to type more than ssh mail and ssh pbx to access these servers, and while I’m at it I want to have scripted log-ins as well– securely, not those namby-pamby no-password keys. In fact, I don’t even want to have private keys on either server.


Fear not! With the power of OpenSSH, I can fix this.
Continue reading »

prerequisite concepts: prelude, basic configuration

Port forwarding is a versatile feature which informs several popular concepts, including X Forwarding and tunneling which are briefly explained below; more advanced port magic will be addressed elsewhere.

X Forwarding
At the end of the previous installment of this series is an example SSH client configuration file, usually located at ~/.ssh/conf; a more complete description of the global declarations shown was deferred until this section, where they are more relevant. Continue reading »

prerequisite concepts: prelude

If you’re not already using a config file (~/.ssh/config) you should peruse the documentation to see what it offers; an ongoing benefit I enjoy is that it allows me to accomplish more while typing less. Suppose, for example, you need to access two mail servers which are both behind a firewall and sharing a single public IP address. One server uses NAT (port forwarding) to provide user access via IMAP-SSL, POP3-SSL, and perhaps even webmail, all on default ports; similarly SSH can be accessed on port 22. The other server happens to be a mail relay, which handles all of the spam and virus scanning for inbound and outbound mail; while the SMTP, SMTPS, and submission services all enjoy a NAT configuration using default ports, SSH access is on port 23 because port 22 already forwards to the IMAP server and the sysadmin hasn’t read this series of articles.
Continue reading »

This is a prelude to a series of articles focused on how the sophisticated power of OpenSSH may be harnessed to great advantage with less effort than one might think. Readers already familiar with OpenSSH and passwordless authentication may wish to skip ahead:

OpenSSH: Basic Configuration
OpenSSH: Port Forwarding
OpenSSH: Proxy Connections
OpenSSH: Environmental Override
SSH Coolness … Even On Windows

Continue reading »

AppArmor, introduced to Ubuntu with Gutsy, is yet another security tool unleashed upon the infosphere. In part, AppArmor is intended as an alternative to SELinux, which can easily be seen as daunting to configure; unfortunately, many such projects are daunting for those admins forced to walk the plank of unfamiliarity above a sea of expectations. Despite a troubled history, the project seems to be here to stay so it is likely only a matter of time before audit messages crop up in one’s kernel log. For those who find AppArmor unnecessary, unpalatable, or just untimely, herein lies a quick-and-dirty guide for telling AppArmor where to stick its audit complaints. Continue reading »

Verizon is a great company, doing great things, but that doesn’t mean they’re not evil. I’ve found that this is an effective maxim which allows me to extol the virtues of Verizon without sounding like I’m drinking the kool-aid. Today I’m hoping it works inversely as well. Continue reading »

Shortly after I last upgraded my mail server, one user reported that his mail client was failing to connect with the message:

"Unable to connect to your IMAP server. You may have exceeded the maximum number of connections to this server..."

He was the only one known to be having this issue, so after a cursory check of the server with no obvious problems, I suggested that this might be an error on his end, such as connecting to the secure IMAP port without using SSL/TLS. Occam’s Razor suggests that a server error is more likely than a client error which just happens to coincide with a server upgrade, so I eventually decided to dig up some infrequently used commands and perform a thorough analysis. Continue reading »

One of the reasons I’m a consultant is because I love to solve problems; this does not mean, however, that I enjoy all the problems I solve, nor that the pursuit is always rewarding in itself. This week I got stuck in a mind-bender that had all the satisfying crunch of a soggy pretzel. Continue reading »

Some time ago I enabled recipient delimiters (e.g. user+foo@host.tld) as a convenient way to know if shady web forms are err.png contributing to my spam folder. The idea is that when House Depot requires me to have an account before I can see if they have loose screws in stock locally, I can sign up with garrison+housedepot@codefix.net instead of my usual e-mail. With recipient delimiters enabled, postfix will try to deliver any incoming mail to garrison+housedepot but when it finds no such user, it will try garrison and I get my mail. The problem arises when I discover that House Depot’s broken web form rejects any e-mail addresses with “+” in the user name as invalid. I’m already using garrison+foo style addresses elsewhere so I don’t want to change the recipient delimiter, but neither do I trust my real address to a company that can’t even create a proper web form. Continue reading »

S.A.R.E. Ninjas are the folks over at SpamAssassin Rules Emporium who act as sort of an arms dealer in the Spam War: they publish custom rules and plugins for SpamAssassin, the Open Source world’s powerful anti-spam software. This article is about an imminent software release that promises big trouble for spammers. Continue reading »

© 2011 Penguins-On-Hudson Suffusion theme by Sayontan Sinha