Since we haven't had a command of the day lately, and 
the people who didn't know the ssh trick I showed with
tar a while back, I thought I would throw out a few
more ssh tricks to help get some creative juices flowing.

It is possible to route local ports on your computer
threw ssh to a remote machine. This is helpful for all
those nice embedded devices that come with web gui front
ends but don't support ssl encryption. Put the appliance
behind a firewall with a machine running sshd(yes this 
could even be a windows box with cygwin and a sshd running)
The machine behind the firewall needs to have ssh passed
through to it. Then you use ssh to connect to that sshd
and port forward a local port to the remote IP behind the
firewall at the port it needs. 

For instance, at one of our colo facilities, we have a APC
PDU. As best I can tell, it is not doing ssl over http, but
supports ssh. Anyways, since this one interface can power
off our machines that are critical for business, we hide it
on a private network. In this case, it is on a point to
point with another machine. 

ssh [EMAIL PROTECTED] -L8080:192.168.0.22:80

That lets me log into remote.machine and I will get a nice
prompt. Then once the ssh session is established, I can
point a browser to http://localhost:8080 and I will get
redirected to the remote machine's route to IP 192.168.0.22
and port 80 on it. This lets me use my local webbrowser to
use the web gui on the other side.

Similarly, you can use -X with ssh to do X11 forwarding.
Using -X also sets the remote sides DISPLAY environment
variable so that you can run the X apps on the remote server
and have them show up locally. This is helpful for running
some gui admin apps that can't be port forwarded. And for
many of the web developers around here, you can also use it
to validate your website using an outside of your current
network connection. I am sure many of us run linux boxes at
home. We can ssh -X to our home machine and use the web 
browser there. And that points out that you can hide your
web browsing habits from work that way as well.

Using the remote browser is nice, but you might find that 
the performance sucks a little due to sending the rendered
images across the connection instead of the image itself or
html. In this case, why not fire up the -D option and configure
your local browser to use the socks proxy in ssh to redirect
your browsing out the remote machine.
ssh -D 23456 [EMAIL PROTECTED]
will produce a proxy at localhost:23456 that will send your
requests out the remote.machine such that you appear to be from
remote machine. Also think of that with all the other apps that
let you use socks proxies as well. I think some IM apps will
let you do the same. yep, looks like pigeon will connect using
socks to bypass your local network managers. 

While doing all this redirection and such. It is likely that
you are on a low upstream bandwidth connection if you are
hitting your home machines. Using -C turns on zlib compression
and will buy you a little overhead on some of your connections.
If you are moving files and stuff locally across your lan with
ssh, try changing the cipher with -c to something less compute
intense. I seem to find better throughput with -c blowfish than
the normal ciphers.

I can't think of a good reason for using the -R option right
now but I assume there was a good one for doing it. -R is the
reverse of -L. You open a port on the remote machine being sent
back to your machine. 


Okay, I think that is enough for this email.

-- 
Steven Critchfield [EMAIL PROTECTED]

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/nlug-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to