"Nailed Up" SSH connection for Cisco devices

To all my fellow Cisco switch & router admins: have you ever been frustrated by the built-in, non-modifiable timeout for SSH support on the devices?

Well, there's a work-around that doesn't require tapping on the keyboard at least every 9:59...

The exec-timeout control for vty lines has no effect on SSH sessions; officially, you can't disable the timeout. Leave an SSH connection idle for 10:00 and it'll terminate from the remote (device) side. The alternative is to remote into your device using telnet; with that protocol, you can greatly extend or even disable the timeout.

But we don't like to use telnet, right? All data is sent in the clear, both keystrokes and screen paints, which includes authentication and logon credentials.

So how do we get the best of both worlds: secure, private connectivity of SSH with the extended, configurable (or disabled) timeout of telnet?

Answer: use both.

Seriously. Use both.

If you use SSH to remotely access a device, you'll get stuck with the 10:00 timer. But if you immediately telnet (or rlogin) back into the same device, you'll "mask" the SSH timeout with the telnet timeout (if one exists).

From the outside, this appears totally safe: all traffic going to and from the device is effectively encrypted by SSH. The telnet/rlogin session is happening "inside" the device where no man-in-the-middle or sniffer can see the traffic.

How does this work? Essentially, the timeout only measures idle time at an EXEC prompt; when you're using telnet (or SSH or rlogin, for that matter), the originating session is no longer in EXEC, it's running an operation.

One obvious negative to this is that you must keep telnet enabled as a valid transport for your device. A second negative is the practice of disabling timeouts on your vty lines. The fix for the first issue is to create a loopback interface for the express purpose of being a telnet endpoint; you then apply ACLs so that it is the only interface on your device that is permitted to accept connections on tcp/23. Assuming you build your ACLs so that telnet connections are only accepted when originated from the device itself, you will have effectively boxed in the insecure protocol inside the device. There's no real solution to the poor timeout choice, except making it long enough for most work without disabling it.

Hypocrisy, thy name is Microsoft

So back in July 2011, when VMware announced vSphere 5 to the world along with its controversial new licensing model, VMware's competition was quick to join the hue and cry from customers that felt VMware was taking away something that, until then, was free.

You can Google it yourself; just put "vTax" in your search bar and you can get lost in all the write-ups,  venom and FUD.

One of my favorites is a TechNet article from the Microsoft virtualization team that attempts a side-by-side cost analysis between vSphere 5 and Hyper-V, showing how the increasing RAM and core density of a single server causes rapidly-escalating prices for licensing. While the author presents reasonable math on the cost to migrate from low(er) density hosts to high(er) density hosts, I have yet to see real-world Hyper-V support the consolidation ratio of VMware. In my personal experience, I've been unable to start up three 2GB VMs on an 8GB Hyper-V system for a classroom environment, while I've run five 2GB VMs on an 8GB ESXi server. In both cases, the host was strained to the point that the running VMs (2 vs 5) were sluggish and slow to respond, but I use the example to suggest that at scale it could take 50% less VMware infrastructure compared to Hyper-V, making a 10-to-10 cluster comparison no more appropriate than comparing apples to oranges for Vitamin C nutrition. And while both products have a limited set of approved/supported platforms for hardware compatibility, the VMware set is much broader than Hyper-V, giving the purchaser more options for savings that can offset the raw costs of licensing.

And on top of all that, Microsoft marketing money also paid for a spoof of VMware with the "VMlimited" microsite.

But today, Microsoft exposed its hypocrisy by unveiling a new licensing model when they announced the next version of SQL Server, SQL Server 2012.

In the same way that VMware is accused of "taking back" free features and benefits, Microsoft has done the same by eliminating the per-processor (socket) licensing option in favor of a per-core (physical thread of execution) model.

Like with VMware's old model, the old model for SQL Server allowed organizations to provision high(er)-density servers (in terms of both RAM and cores-per-socket) in place of low(er)-density servers without running into the need to acquire new licenses. The new model takes that away, and also puts the burden of reoccurring subscription expenses (Software Assurance, or "SA") into the mix in order to best-leverage the combination of SQL Server and virtualization.

Under the old model, an organization could pay $164,970 (USD, list) for six sockets of SQL Server Enterprise Edition; in a 6-socket VMware cluster, a DBA could then implement an unlimited number of SQL instances on up to 8 VMs per host. If the organization paid an additional $41,244/year for SA, the VMware cluster would be able to run unlimited instances on an unlimited number of VMs (subject to OS licensing limits—if any—and resource constraints of the virtual environment). Further, the old model had no limitations for the migration of SQL-hosting VMs from one server to another (i.e., vMotion). With modern, high-density servers that provide 512GB RAM and 24 cores of execution per 2-socket box, it's conceivable that dozens of multi-vCPU VMs could be hosted for costs in the neighborhood of $365,000 over a 5-year period.

Now compare that to the new model. At a (list) price of $6874 per core, that same six-socket, 12-core-per-socket cluster would cost $494,928 plus an additional 25% annually for SA, making the 5-year cost for the same hardware environment in excess of $1.1 million.

That's a 300% increase in costs for the new licensing model.

Hmmm.... Shall we now call per-core licensing the SQL Tax?