ProxyCommand ssh {gw} netcat -w 1 {host} 22
Here {gw }and {host} are placeholders for the gateway and the host.
But it is also possible when netcat is not installed on the gateway:
ProxyCommand ssh {gw} 'exec 3<>/dev/tcp/{host}/22; cat <&3 & cat >&3;kill $!'
The /dev/tcp is a built-in feature of standard bash. The files don't exist. To check whether bash has this feature built-in use run cat < /dev/tcp/google.com/80 on the gateway. To make sure that bash is used, use:
But it is also possible when netcat is not installed on the gateway:
ProxyCommand ssh {gw} 'exec 3<>/dev/tcp/{host}/22; cat <&3 & cat >&3;kill $!'
The /dev/tcp is a built-in feature of standard bash. The files don't exist. To check whether bash has this feature built-in use run cat < /dev/tcp/google.com/80 on the gateway. To make sure that bash is used, use:
ProxyCommand ssh {gw} "/bin/bash -c 'exec 3<>/dev/tcp/{host}/22; cat <&3 & cat >&3;kill $!'"
And it even works together with ControlMaster.
(Updated on Oct 22 to include kill to clean up background cat)
(Updated on Oct 22 to include kill to clean up background cat)
(Updated on Mar 3 2011 to make placeholders more clear and explain /dev/tcp)
8 Kommentare:
That is one great trick, I'll try this one on different UNIX/Linux systems! Thanks for this hint!
Not bad the idea, but for me that leaves one idle cat around after teminating the connection.
Yes, it leaves one cat around. Didn't worry about it. Not sure how one could prevent that.
How about closing the file descriptor #3 after everything was done? Will this work? --
ProxyCommand ssh {gw} 'exec 3<>/dev/tcp/{host}/22;(cat <&3 & );cat >&3; exec 3>&-;'
Closeing the file descriptor doesn't exit the background cat for me. But your comment made me realized one can just kill the background cat after the connection is finished. Thanks. I updated it in the article.
I am sorry to bump up an old post, I am trying your solution with a slightly different approach, but doesn't seem to work and it's mainly because I don't think I understand the proxy command line correctly.
What's the {gw} string? and is the {host} the same as the %h variable?
And on a second note /dev/tcp directory doesn't exist either on my local or remote machine during an ssh connection.
Is it possible to explain the expression with the exec:
exec 3<>/dev/tcp/{host}/22
My setup looks something like this:
Host proxy
Hostname proxy.server.com
User myuser
DynamicForward localhost:3128
Host *.server.com
ProxyCommand /usr/bin/nc -x localhost:3128 -Pmyseconduser %h %p
In a perfect world, I'd ssh to proxy, then ssh in another console to the dev.server.com, and use proxy to browse the same server on ports 80 and 3000
The problem is that proxy doesn't have netcat installed. so no nc love there.
Any help that allows me to rewrite this trick and adapt it to my context would be appreciated.
I updated the post to make it more clear. Yes you can use %h if that is the valid hostname. gw is the gateway you use as intermediary machine. And you need to make sure you use bash with /dev/tcp enabled.
I came across this having the problem of no netcat on the gateway, but unfortunately it has no /dev/tcp either.
I did nonetheless eventually find a solution! See, there _was_ a copy of netcat on the final target, and I could use that with an extra ssh hop:
ProxyCommand ssh {gw} ssh {host} netcat -w1 {host} 22.
It does end up with an extraneous loopback from the target to itself, but otherwise seems to work.
Post a Comment