Todd's TechnoGeek Journal

I use scp all the time for file transfers, but it often annoys me to have to have to browse around using a separate ssh session. Of course, OpenSSH ships with sftp, but it's seriously lacking as a client protocol. My primary complaint about sftp is that it doesn't support shell globbing or filename/directory completion. This makes it fairly clunky for navigation and horrible when trying to find a single file in a crowded directory.

Luckily, there's a solution: the FISH protocol. FISH implements an ftp-like interface over standard SSH. Since it interacts with the shell, it supports standard globbing constructs as well as completion.

The protocol itself is fairly obscure, though. Apparently, it was originally developed as a virtual file system layer for Midnight Commander (a console-based file manager), but was later integrated with the Konqueror and Nautilus file managers, and is currently supported by the lftp program, too.

Googling around for several days turned up exactly one document providing a specification for the protocol. As a result, it's been fairly difficult for me to get information on the security implications of using the FISH protocol.

It can be assumed that the use of FISH is, from an external perspective, just as secure as OpenSSH itself. In fact, since FISH is running over SSH, the security of the connection should be be sufficient for most purposes. However, the security of the protocol has not really been subjected to much scrutiny, as far as I can tell.

It would appear from the specification that the FISH client is supposed to make some reasonable attempts to avoid doing Bad Things™. However, since the protocol and its implementations have not been scrutinized extensively, it remains an open question as to whether there are any significant flaws.

From a practical standpoint, if someone has legitimate shell access on a remote system via SSH, there is already an acceptance of a certain level of risk. So, the fact that some FISH implementations allow arbitrary shell commands to be executed is not inherently any riskier than standard SSH, although since it is hiding the SSH interaction layer from the user, there is an increased risk that a poorly-implemented function could cause damage to the remote system.

Despite the fact that FISH has been around for almost six years at this point, it has not received widespread attention from either the user or security communities. It's probably time that both take a look at this nifty protocol. Meanwhile, I've found it to be an elegant, if obscure, solution to my file transfer needs, and would recommend giving it a try.

There are days when I think that the GUI tools for Windows are more functional than the Unix command-line equivalents. Wednesday was one such day. I was trying to log the output of an OpenSSH session, and couldn't find a flag to turn on logging. How was I supposed to capture output to disk without a log-enabling flag?

Now, I'm pretty familiar with puTTY and SecureCRT, both of which support session logging. Both, of course, are for Windows, and will not run natively on Linux.

Well, the solution ended up being fairly simple. I ended up using tee to pipe the output to a file:

ssh root@example.com | tee example.log

This worked like a charm, but was a bit mysterious because I could still interact with the OpenSSH session while tee was logging to disk. Normally, when you pipe output from a command in Unix, it passes control to the next tool in the pipeline after it's complete--or at least, that's how it appears from a user's perspective. But the more I thought about it, the more I realized that I had oversimplified the process.

What tee (or any pipelined command) actually does is treat its standard input as a FIFO. So, rather than taking the completed output of ssh after it terminates and redirecting it to disk, it uses the standard output from ssh as a FIFO and continually reads it while ssh is running. As for the interaction, tee doesn't redirect standard input, so the keyboard continues to interact with ssh, allowing interaction with the original process while still redirecting its output to disk through tee. If you're a really crufty Unix guy, you probably already knew this. But if, like me, 90% of your pipelines point to more or less, this subtlety may have escaped you, too.

Now that my faith in the flexibility and adaptability of Unix command-line tools is restored, I need to get back to work. I have a lot of data to log from various OpenSSH sessions.

Sourcefire is a commercial reseller of Snort-based IDS systems. Their core products are appliances for sensors and centralized IDS management, which require valid license keys before they'll even allow you to configure the units through the GUI.

Well, fair enough. While I think license keys are an extra hassle for the customer, I can understand why a company based on open-source software might require a license key to run the proprietary layer that sits on top of the open-source components. But what I can't understand in the mind-set that goes into Sourcefire's particular implementation.

First of all, their appliances do not ship with the appropriate keys installed. This might be understandable if they had warehouses full of standardized units, but apparently they build to order. So, while building the unit and installing the OS, why not install the proper license key at the same time? For $15,000-$25,000 per appliance, you would think that taking such a basic customer-focused step would be a no-brainer.

Secondly, if you're going to require that license keys be installed by the customer, consider the fact that very few enterprises throw a new box onto a production network. In many cases, new units go into a lab without outside connectivity to allow for configuration and hardening in a secure environment.

Then we have Sourcefire, which requires that licenses be requested by email. No slips of paper with typable license keys for Sourcefire users; no floppy disks with license files that can be easily installed offline. Instead, you have to email a MAC address to Sourcefire, at which point they will email you back a license key which looks suspiciously like cipher text from a modified OpenPGP implementation.

But that's not even the best part. The really nifty thing about Sourcefire's licensing process process is that it's not automated--or if it is, it's automated very poorly. As of the time of this writing, it's been over 17 hours since I requested a pair of license keys for some new sensors. It was several hours between request and receipt for the management console's key, which was bad enough, but apparently they need to fetch sensor keys from the outer solar system--probably from beyond Pluto, based on the turn-around time.

So, there you are, working on installing a new Sourcefire sensor. You load up the box, and fire up the management interface. But guess what? You can't configure it: no license. Since you don't have Internet access in the lab, you copy the MAC address onto the back of your hand and run around the building trying to find a place to send out a request email. Then you get to spend the next two days at a stand-still because you don't receive your license key back in a timely fashion. Of course, when you do, you will then need to put the license key on removable media and trot it back to the lab, because 884-character license keys simply won't fit on the back of your hand, and would probably give you carpal-tunnel syndrome if you tried to type it all in anyway.

Someone needs to buy the Sourcefire people some seats on the Clue Train, because the idea of an appliance as something easy to install apparently left the station without them. You can hear the Clue Train's whistle fading off into the distance...which is where Sourcefire's customers will be heading if Sourcefire isn't on the very next train.