If you’ve read my OpenSSH series, perhaps even if you haven’t, you are probably aware of the power SSH offers to those who know how to use it. 
There are many ways to protect the service from unauthorized usage, focusing on self-contained or single host solutions, one finds two common flavors: those which make use of the Linux kernel’s packet filtering tools (netfilter and iptables), and those which rely on Wietse Venema’s TCP Wrappers. Netfilter certainly offers power and flexibility, but this may be at the cost of simplicity and management ease. While no security measure ought to be implemented blindly, there is an undeniable benefit to simple measures which can be configured quickly and with little fuss — in this arena, TCP Wrappers stands tall.
Continue reading »
Philip has posted a brief follow up to Managing Line Endings over at Armadillo. He’s also got some articles which may be useful for anyone forced to use SSH on Windows.
prerequisite concepts: prelude, basic config., port fwd, proxy conn.
I don’t often have the opportunity to experiment on computers running Windows, but every 
once in a long while it simply cannot be avoided. I recently found myself wanting to look up a password in Revelation, a password manager for the Gnome Desktop on Linux; I have previously written about using OpenSSH’s ProxyCommand directive to tunnel through a firewall and forward X11 (GUI) applications remotely from a an isolated workstation on a private LAN, the difference here was that I needed to forward that application to a Windows workstation.
prerequisite concepts: prelude, basic configuration
This post is as much about customizing the root shell as it is about SSH environment variables, but I’m adding this to my OpenSSH collection because it’s applicable to any user.
I occasionally work on servers where, for a variety of reasons, I share an account with one or more other users; this is almost always suboptimal, but it does happen nonetheless. Over time I’ve grown somewhat partial to zShell, so one method I’ve used is to log in to a default shell, usually bash, then run zsh. Continue reading »
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
Recent Comments