OpenSSH: Basic Configuration

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.

OpenSSH Prelude: Requisite Knowledge

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

Doctor, I've got audit complaints about my kernel log.

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.

Arrrgh!

Avast ye corned jiggers; it be Talk Like a Pirate Day.

Three Things to Avoid in a VoIP Provider

Like many others, when I set up my first Linux PBX I knew little about VoIP providers and with few sources of reliable, current information, I made a decision based on name recognition, perceived value, and minimal research. Like many others, I looked for companies who advertised a BYOD plan under the false assumption that said companies would have a clue regarding said devices, despite the cautionary warnings which politely explained that BYO, as used here, means “unsupported”. Like many others, I signed up with BroadVoice believing I had a pretty good deal; in fact, among similar plans offered by cable companies and Vonage, BroadVoice compares rather well.

By the time I started to suspect BroadVoice of stockpiling probiscus laden mammals and bleach, I had already paid setup fees and number transfer fees, and chagrined the thought of early termination fees, more number transfer fees, and a potential three to seven week transfer period. Rather than add to the copious corpus of BroadVoice complaints, I thought I'd focus on what to avoid when choosing a VoIP provider.