M
Moshe Goldfarb
On Sun, 13 Apr 2008 18:25:09 GMT, Kelsey Bjarnason wrote:
> Just playing around with ssh a bit today, for kicks.
>
> First item was a result of a "problem": my local NNTP server has gone the
> way of the dodo. Not unexpected few people were using it. Hmm, I have
> a working leafnode setup at home, can I somehow make use of that?
>
> What I do *not* want to do is open a port to leafnode the fewer services
> which are announced, the better. I also don't want to use something such
> as a firewall setup which allows me in from location X, but blocks
> location Y - if I want to check the news from somewhere else, that would
> keep me out as well.
>
> Hmm. Turns out ssh allows me to do port forwarding. Basically, I "map"
> a local port, such as 3119, to remote port 119, via ssh. Net result, ssh
> compresses, encrypts and tunnels the data from here to the remote
> leafnode server, while only ever admitting that ssh itself exists on the
> machine.
>
> So far so good. I can improve it a little. Set up a local leafnode
> instance, using the ssh tunnel, then point the local client at the local
> leafnode. Now I get to apply local leafnode blocks and filters, the
> benefits of leafnode caching, but via a remote leafnode cache talking to
> my home ISP's new server, while my local news client thinks it's just
> talking to a perfectly normal news server. All's good.
>
> Ya know, I've also got a squid caching proxy over there, complete with ad
> blocking and a mess of other funky stuff. Can I make use of that, too?
>
> Why yes, I can. I can set up another ssh tunnel, say from local port
> 8080 to remote port 3128 (squid's default), point my browser at the
> "local" proxy server 127.0.0.1:8080 and voila - I get the benefits of the
> squid proxy I set up at home, over a compressed, encrypted connection,
> without ever announcing anything on the home machine but the ssh port -
> and again, I can do this from anywhere, simply by providing proper ssh
> credentials.
>
> Okay, getting better. However, there's an app or two I run at home I'd
> like to be able to run here. Sure, I could simply install 'em here, but
> turns out they sometimes conflict (think IM clients, connecting to the
> same accounts from different machines). Much better if I could run 'em
> remotely.
>
> Hmm.
>
> Yeah, okay, there's vnc and the like, but, really, ick. No, seriously,
> ick. I don't want to run a remote desktop, I want to run a remote
> _application_... and have it _behave_ as if it were running locally,
> complete with minimizing to the local system tray, etc, etc, etc.
>
> Enter ssh again. I can launch an ssh session, forward X over it and
> voila my application is _running_ remotely, but _behaving_ as if it were
> running locally. Complete with system tray support and the like. And I
> *still* don't have to open a single port other than ssh.
>
> Oops. One of the remote clients writes logs. Not a problem, per se, but
> I'd like to keep the logs all properly synced up - not have half of them
> on the local machine, half on the remote. What can I do about this?
>
> Ah, yes. sshfs. Allows me to map a remote directory to a local
> directory, meaning whatever I write _here_ is automagically updated
> _there_. And, again, all over a nice compressed, encrypted channel and
> again, without ever admitting any services on the home machine other than
> ssh.
>
> So now I have secure remote "invisible" file mapping, secure remote
> "invisible" news service, secure remote "invisible" web caching, secure
> remote "invisible" application launching - which, again, behaves as if
> the app were run locally, none of this remote desktop nonsense - and all
> available from anywhere, as long as I have the proper credentials.
>
> Here's the real kicker, though. The only part of that I cannot
> reasonably expect to do with pretty much any stock Linux machine is the
> file mapping, as sshfs may not be installed. On the other hand, ssh _is_
> virtually certain to exist on a typical Linux box, meaning I can achieve
> every part of this except the file mapping on pretty much any typical
> Linux machine, using just the typical bundled tool set.
>
> What I really wanted to avoid was using a firewall to manage any of
> this. Not because a firewall couldn't do it, but because a firewall is
> going to be less effective. Sure, I can set up a firewall to allow
> remote file shares to machine a.b.c.d, but how do I set it up to allow
> remote file shares to an arbitrary machine _without_ even admitting the
> service is available on the box? That is, how does one set up a firewall
> to allow arbitrary machines to connect to port N, without admitting that
> port N even exists or is open? As far as I can see, you can't. With
> ssh, I can tunnel pretty much any port I want, without ever exposing the
> port to the outside world, yet still get to the port from any machine out
> there.
>
>
>
> So the obvious question becomes how to do the equivalent in Windows -
> Vista, say - using *its* bundled tool set?
>
> How does one tunnel connections?
> How does one set up port forwarding?
> How does one launch remote apps, which behave as if they're local?
> How does one map directories, without exposing the shares?
> How does one do this all using encrypted connections?
> How does one do this such that arbitrary machines can use all these
> services, without even admitting the services _exist_ - i.e. not exposing
> their ports?
>
> And perhaps most importantly, how does one do this without relying on
> additional software one _cannot_ reasonably expect to be available on an
> arbitrary Windows machine?
>
> I know Vista is so much better than Linux, since we keep getting told
> this day in and day out, so there must be a trivial way to duplicate this
> sort of setup, I'm just curious what that way is.
God are you boring Kelsey......
Why don't you find a boyfriend or something more interesting to occupy your
time.
--
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
http://linuxidiots.blogspot.com/
> Just playing around with ssh a bit today, for kicks.
>
> First item was a result of a "problem": my local NNTP server has gone the
> way of the dodo. Not unexpected few people were using it. Hmm, I have
> a working leafnode setup at home, can I somehow make use of that?
>
> What I do *not* want to do is open a port to leafnode the fewer services
> which are announced, the better. I also don't want to use something such
> as a firewall setup which allows me in from location X, but blocks
> location Y - if I want to check the news from somewhere else, that would
> keep me out as well.
>
> Hmm. Turns out ssh allows me to do port forwarding. Basically, I "map"
> a local port, such as 3119, to remote port 119, via ssh. Net result, ssh
> compresses, encrypts and tunnels the data from here to the remote
> leafnode server, while only ever admitting that ssh itself exists on the
> machine.
>
> So far so good. I can improve it a little. Set up a local leafnode
> instance, using the ssh tunnel, then point the local client at the local
> leafnode. Now I get to apply local leafnode blocks and filters, the
> benefits of leafnode caching, but via a remote leafnode cache talking to
> my home ISP's new server, while my local news client thinks it's just
> talking to a perfectly normal news server. All's good.
>
> Ya know, I've also got a squid caching proxy over there, complete with ad
> blocking and a mess of other funky stuff. Can I make use of that, too?
>
> Why yes, I can. I can set up another ssh tunnel, say from local port
> 8080 to remote port 3128 (squid's default), point my browser at the
> "local" proxy server 127.0.0.1:8080 and voila - I get the benefits of the
> squid proxy I set up at home, over a compressed, encrypted connection,
> without ever announcing anything on the home machine but the ssh port -
> and again, I can do this from anywhere, simply by providing proper ssh
> credentials.
>
> Okay, getting better. However, there's an app or two I run at home I'd
> like to be able to run here. Sure, I could simply install 'em here, but
> turns out they sometimes conflict (think IM clients, connecting to the
> same accounts from different machines). Much better if I could run 'em
> remotely.
>
> Hmm.
>
> Yeah, okay, there's vnc and the like, but, really, ick. No, seriously,
> ick. I don't want to run a remote desktop, I want to run a remote
> _application_... and have it _behave_ as if it were running locally,
> complete with minimizing to the local system tray, etc, etc, etc.
>
> Enter ssh again. I can launch an ssh session, forward X over it and
> voila my application is _running_ remotely, but _behaving_ as if it were
> running locally. Complete with system tray support and the like. And I
> *still* don't have to open a single port other than ssh.
>
> Oops. One of the remote clients writes logs. Not a problem, per se, but
> I'd like to keep the logs all properly synced up - not have half of them
> on the local machine, half on the remote. What can I do about this?
>
> Ah, yes. sshfs. Allows me to map a remote directory to a local
> directory, meaning whatever I write _here_ is automagically updated
> _there_. And, again, all over a nice compressed, encrypted channel and
> again, without ever admitting any services on the home machine other than
> ssh.
>
> So now I have secure remote "invisible" file mapping, secure remote
> "invisible" news service, secure remote "invisible" web caching, secure
> remote "invisible" application launching - which, again, behaves as if
> the app were run locally, none of this remote desktop nonsense - and all
> available from anywhere, as long as I have the proper credentials.
>
> Here's the real kicker, though. The only part of that I cannot
> reasonably expect to do with pretty much any stock Linux machine is the
> file mapping, as sshfs may not be installed. On the other hand, ssh _is_
> virtually certain to exist on a typical Linux box, meaning I can achieve
> every part of this except the file mapping on pretty much any typical
> Linux machine, using just the typical bundled tool set.
>
> What I really wanted to avoid was using a firewall to manage any of
> this. Not because a firewall couldn't do it, but because a firewall is
> going to be less effective. Sure, I can set up a firewall to allow
> remote file shares to machine a.b.c.d, but how do I set it up to allow
> remote file shares to an arbitrary machine _without_ even admitting the
> service is available on the box? That is, how does one set up a firewall
> to allow arbitrary machines to connect to port N, without admitting that
> port N even exists or is open? As far as I can see, you can't. With
> ssh, I can tunnel pretty much any port I want, without ever exposing the
> port to the outside world, yet still get to the port from any machine out
> there.
>
>
>
> So the obvious question becomes how to do the equivalent in Windows -
> Vista, say - using *its* bundled tool set?
>
> How does one tunnel connections?
> How does one set up port forwarding?
> How does one launch remote apps, which behave as if they're local?
> How does one map directories, without exposing the shares?
> How does one do this all using encrypted connections?
> How does one do this such that arbitrary machines can use all these
> services, without even admitting the services _exist_ - i.e. not exposing
> their ports?
>
> And perhaps most importantly, how does one do this without relying on
> additional software one _cannot_ reasonably expect to be available on an
> arbitrary Windows machine?
>
> I know Vista is so much better than Linux, since we keep getting told
> this day in and day out, so there must be a trivial way to duplicate this
> sort of setup, I'm just curious what that way is.
God are you boring Kelsey......
Why don't you find a boyfriend or something more interesting to occupy your
time.
--
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
http://linuxidiots.blogspot.com/