Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.5: A fix for failing SSH Bouncing UNIX
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!
    •    
  • Currently 2.13 / 5
  You rated: 5 / 5 (8 votes cast)
 
[12,070 views]  

10.5: A fix for failing SSH Bouncing | 14 comments | Create New Account
Click here to return to the '10.5: A fix for failing SSH Bouncing' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.5: A fix for failing SSH Bouncing
Authored by: casperghst42 on Mar 24, '09 08:06:39AM

This is awsome, I've been relying on openvpn and ssh redirects for years, this is some much easier.



[ Reply to This | # ]
10.5: A fix for failing SSH Bouncing
Authored by: mzs on Mar 24, '09 08:12:41AM
I've used the ssh gateway trick instead before:

http://quark.humbug.org.au/publications/ssh/ssh-tricks.html

That's pretty terse, I think I originally learned about it from the snail book. The reason is that I find nc often is not installed on a gateway machine but little more than ssh, it needs to be secure after all. The other annoying thing is that netcat has all sorts of different options depending on version. Also do you really need the -w at all in your approach?

Finally when all else fails:

ssh foo | ssh bar cat baz > baz

[ Reply to This | # ]
10.5: A fix for failing SSH Bouncing
Authored by: mzs on Mar 25, '09 03:30:01PM
Oh yeah it was in the snail book and the excerpt is online:

http://www.onlamp.com/lpt/a/1669

Also this gives more details if you need help creating the keys:

http://www.netadmintools.com/part549.html

[ Reply to This | # ]
10.5: A fix for failing SSH Bouncing
Authored by: mzs on Mar 25, '09 03:32:22PM
DOH! I forgot about the first page:

http://www.onlamp.com/lpt/a/1668

[ Reply to This | # ]
10.5: A fix for failing SSH Bouncing
Authored by: jochen K├╝pper on Mar 24, '09 08:55:28AM

What's wrong with "ssh -t"?



[ Reply to This | # ]
10.5: A fix for failing SSH Bouncing
Authored by: Alrescha on Mar 24, '09 09:30:07AM

I do this:

ssh -L 9022:hostc:22 hostb
ssh -p 9022 localhost

if you don't want the term on hostb, you can use -f on ssh, push the first
session into the background, and just use the second ssh session. Eg:

ssh -f -L 9022:hostc:22 hostb sleep 60;ssh -p 9022 localhost

and you're on host c.

A.



[ Reply to This | # ]
10.5: A fix for failing SSH Bouncing
Authored by: Soliman on Mar 24, '09 09:44:48AM
Actually this has to do with netcat since the hint page you mention creates an executable for no good reason (even worse, it does fork a shell for nothing): the standard way is to include directly the netcat command in the ProxyCommand line of your .ssh/config
ProxyCommand ssh mybouncehost nc -w 1 %h %p
However, as mentionned, netcat is a bit tricky in the way it handles timeouts, creating either failures or even zombie processes on the bouncehost. Usually a few seconds is enough.

---
Sylvain

[ Reply to This | # ]

10.5: A fix for failing SSH Bouncing
Authored by: richardl on Mar 24, '09 10:24:30AM

Also, If you usually log into a different userid on HostC (then you are currently on the mac), then you can add the "User xxx" option in your config as well

This will allow you to: ssh hostc (same as ssh xxx@hostc)

A little less typing for the folks that ssh all day



[ Reply to This | # ]
10.5: A fix for failing SSH Bouncing
Authored by: eagle on Mar 24, '09 10:51:53AM
I do this all the time. Here's what I do:

In my ~/.ssh/config file, I have:
host nest
hostname eagles.nest.com
user eagle
Cipher blowfish
Compression yes
LocalForward 5022 boston:22

host boston
hostname localhost
port 5022
Host "eagles.nest.com" is the publicly accessible system. Host "boston" is the unreachable system.

So, in one window, I issue the command "ssh eagles.nest.com," and in another window I issue the command "ssh boston."

Et voila.

[ Reply to This | # ]
10.5: A fix for failing SSH Bouncing
Authored by: cuberoot on Mar 24, '09 02:57:21PM
OpenSSH has supported the -D/DynamicForward option for almost 8 years! (since OpenSSH 2.9) Get with the times! ;)

I used a nc based solution back then too, but it's much less reliable.

SSH includes SOCKS server support, but not client support so you'll need connect.c or similar (socat, for example) to use locally for your ProxyCommand.

The basic setup looks like this:

Get and compile connect.c:
mkdir ~/bin
cd ~/bin
curl -O http://www.meadowy.org/~gotoh/ssh/connect.c
gcc -Wno-pointer-sign -o connect connect.c -lresolv

The ssh config looks like:
Host proxyhost.workdomain.com
        ProxyCommand none
        DynamicForward 1080

Host *.workdomain.com
        ProxyCommand ~/bin/connect -w 8 -S4 127.0.0.1:1080 %h %p

Then all you have to do is:
ssh -Nf workproxy

That'll leave a connection to workproxy running in the background and listening on 127.0.0.1 on 1080.

Then:
ssh foo.workdomain.com

That'll transparantly use the DynamicForward for anything matching *.workdomain.com!

I go a step beyond and use ~/bin/myconnect which checks to see if there's a listener on 127.0.0.1:1080, uses it if so, and if not tries to connect directly.

That way everything works the same for me regardless of my network location:
#!/bin/sh
# This is purposefully inefficient so it'll work on almost any *nix
listening() {netstat -an | grep -i tcp | grep -w LISTEN | grep -qE "[.:]$1[ t]" >/dev/null 2>&1}
if listening 1080; then
    exec ~/bin/connect -w 8 -S4 127.0.0.1:1080 "$@"
    exit
fi

exec connect -n "$@"
Enjoy!

cheers,
Christopher

[
Reply to This | # ]
10.5: A fix for failing SSH Bouncing
Authored by: cuberoot on Mar 25, '09 01:17:48AM

grep -qE "[.:]$1[ t]" should read grep -qE "[.:]$1[ \t]"



[ Reply to This | # ]
10.5: A fix for failing SSH Bouncing
Authored by: bauldrywc on Mar 24, '09 07:37:25PM

Since no one's mentioned it yet, I'll add my favourite technique: just forward the ports via ssh through the linking box with something like
   ssh -N -p 22 -c 3des [account@tunnerl.host]> -L 5022/[target.host]/22
and follow with a
   ssh -p 5022 [target_account]@localhost



[ Reply to This | # ]
10.5: A fix for failing SSH Bouncing
Authored by: efraim on Apr 05, '09 05:24:57AM

Again, why not use ssh -t?



[ Reply to This | # ]
10.5: A fix for failing SSH Bouncing
Authored by: efraim on Apr 05, '09 05:29:19AM

ssh <hosta> -t ssh <hostb>
Sorry for posting twice, just wanted to make sure it is clear what I meant.
it is that simple and keep your scripts, folks, but this works for a few of you I bet. Think of x or auth forwarding, too.



[ Reply to This | # ]