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


Click here to return to the 'A better solution (I think)' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A better solution (I think)
Authored by: cuberoot on Sep 29, '05 12:46:42PM

Dispensing with rsa verification is a bad idea at best, and dangerous at worst. The comment about using HostKeyAlias is definitely a better way to go but is also a bit of a pain to manage.

However, with modern ssh clients there is no need to set up a bunch of local port fowards to access hosts through the other end of an ssh connection. Enter DynamicForward.

Instead of using something like this in your config plus some set of workarounds for the resultant ssh host key mismatches:

Host remotetunnelmachine
   Localforward 1234 remotehost1:22
   Localforward 1234 remotehost2:22

Just use one:

Host remotetunnelmachine
   DynamicForward 1080

The above will set up a localhost listener on port 1080 that is in fact a SOCKS server that forwards all connection requests through remotetunnelmachine. This means you can also set your web browser proxy config to SOCKS on localhost:1080 and browse websites on the other end.

The only additional piece you need to make the magic happen is a command line SOCKS tool. I use connect.c because it's very lightweight, but socat (sysutils/socat) from darwinports works just as well.

My config for various endpoints looks something like this:

Host remotehost1 remotehost2
  ProxyCommand ~/bin/connect -4 -S 127.0.0.1:1080 %h %p

If you're using socat use this ProxyCommand instead:

  ProxyCommand socat - socks4:127.0.0.1:%h:%p,socksport=1080,nodelay

Of course, this assumes you'll always be using the ssh port foward to connect to the listed hosts; Either live with that, use the FQDN for one place and the short name for another, or do what I do:

ProxyCommand can easily be a shell script that autodetects if the appropriate DynamicForward listener is up, uses it if so, and otherwise connects directly.

The above lets you type 'ssh remotehost1' no matter where you are, avoids key mismatch problems, and generally makes life good. I use some PAC (proxy autoconfig) magic to do automatic detection for the webbrowser too. This works so well I don't use the company VPN client any more. O.K. it was actually the company VPN client that ... *cough* encouraged me to do this in the first place, but hey. ;)

For those interested, the autodetecting ProxyCommand script is just a simple:


#!/bin/sh
if connect -n 127.0.0.1 1080 >/dev/null 2>&1 </dev/null; then
    exec connect -4 -S 127.0.0.1:1080 "$@"
else
    exec connect -n "$@"
fi

Happy ssh'ing!

No purchase necessary. Offer not valid with all ssh client versions. Void where prohibited by security policy or AllowTcpForwarding. See DynamicForward entry in ssh(1) for details.



[ Reply to This | # ]
A better solution (I think)
Authored by: jweber on Sep 30, '05 04:42:39PM

I usually just put a bunch of entries in my /etc/hosts file, e.g.
127.0.0.1 host1.localhost
127.0.0.1 host2.localhost
...

Then I can ssh to host1.localhost instead of just localhost. This keeps the names separate so known_hosts doesn't get confused, and has the added benefit that it's always clear which host I'm connecting to.



[ Reply to This | # ]