As a Linux SysAdmin, of course my favorite desktop is OS X! On my MacBook Pro, I run CentOS using VMware. In my work, every day I use a fantastic technique called SSH Bouncing, both from within the VMware Linux environment and from Terminal on the Mac itself.
Explained in simple terms, assume you're on a computer, A, and you want to ssh into a computer (say, C) that is isolated from the world on a private network. If a computer B exists (and you already have an account on it) that has two network interfaces, one facing the internet (or at least the network you're on) and the other facing the private network, SSH Bouncing let's you ssh directly from computer A to computer C in one jump, with no added software or weakening of your security setup, as it requires the already-existing account on computer B.
This greatly simplifies file transfer, since you don't have to do the two step "SSH Hopping" of A » B, B » C. And popping a graphical X-Window off of C » A isn't possible at all without this technique. See this article for all the technical details on setting this up. It's very straightforward, and you'll need to understand it first for this hint to be useful.
Anyway, the point of this hint is that I used this all the time under Tiger, and when I upgraded my home and work Macs to Leopard, this broke. Specifically Mac » Mac » (destination) bouncing broke. I kept getting "Connection closed by remote host" errors.
Since most of my work involves MAC » RHEL4/5 » (dest) bouncing, the only thing this prevented me from doing was popping X-Windows off of the Linux VM on my laptop (usually left running on my desk at work) from my home Mac. A pain, but far from a show stopper. But what had changed with SSH? I spent a lot of frustrating hours scouring the new options in the config files for both SSH client and SSHD in Leopard, to no avail.
Recently, some Ubuntu machines came under my responsibility, and I found that Mac » RHEL4/5 » (dest) bouncing, which had never failed me before, was now failing with similar errors when (dest) was an Ubuntu machine. Maybe because this was becoming a show stopper, it spurred me to look at the problem in a new way, and I figured out the solution.
Here's where you need to understand the above-referenced bouncing hint page first: the problem here has nothing to do with SSH at all! It's with the executable ~/.ssh/netcat-proxy-command file! Specifically, where you see this line...
ssh $bouncehost nc -w 1 $target 22
...the nc -w 1 is a timeout value (in seconds) for netcat to give up on chaining the A » B and B » C connections together. If it can't do it all in one second, the connection is closed. All you need to do is raise that value (I went hog wild and put in 86400, i.e. a full day) and you're all set. Happy Bouncing!

