[NCLUG] ssh question

[Bob Proulx]

Jim Hutchinson wrote:
> I'm wondering if any of the tech gurus on this list can help me with an ssh
> question. First, some background. I'm running an ssh sever at home. It
> listens on port 5151. I would like to be able to tunnel web traffic over the
> ssh connection for security when using open networks.

The tunnel connection you describe protects your data in an encrypted
tunnel from your localhost over the Internet to your home server.
At your home server this is now no longer encrypted and accesses the
Internet normally.

> I think I know how to do this. Normally I pick a random port for a
> socks proxy in firefox like port 8080. The command I use is
> 
> ssh -D 8080 -p 5151 user at ip_of_ssh_server
> 
> This does work. I can set up a socks proxy in firefox and as far as I can
> tell my web traffic is tunneled.

Sure.  I would probably pick a different port than 8080 because it
shouldn't matter and often other web proxy processes will want to use
8080 and you will have consumed it for your proxy.

> However, there are times when I would prefer not to have traffic on
> a random port as that might alert the network police. A bunch of
> traffic on port 8080, for example, might look out of place.

What is your local host environment?  Is this a personal workstation
of some sort?  Or is this a shared system with other users?

With the configuration you have described network sniffers on the
local network will only see ssh port 22 traffic.  They will not be
able to determine that you are using port 8080 on your localhost to
connect to the ssh tunnel.  They will only be able to see encrypted
data packets flowing to port 5151 at ["ip_of_ssh_server"].

On the local host that you are launching the ssh from the connection
will be seen as a TCP endpoint listening for connections.  Depending
upon the ssh configuration the listening port will either be localhost
only on 127.0.0.1 or accessible from the network on 0.0.0.0 which is a
wildcard address for all addresses associated with the host.  This
information is only visible from the local host itself and is not
visible from the network.

  netstat -na | awk '$NF=="LISTEN"' | less

Therefore if this is your own personal workstation the choice of ports
isn't really important.  Only you will be able to look at what is
listening there.  Many services need to listen such as the NFS
portmapper and imap servers and gnome configuration servers and email
notifiers and various other random things.  Picking a random port off
in the rural area of ports would probably be lost in the noise even if
someone were looking.

> It seems to me it would be possible to use port 443 for the tunnel
> and that would then cause all web traffic to look as if it's just
> normal encrypted SSL traffic - or at least that is how I understand
> it. To do this I just change the command to
> 
> ssh -D 443 -p 5151 user at ip_of_ssh_server

I think there is confusion here.  The remote port would still be 5151
and would still be visible in network statistics.  This would change
the port on the local host that is being used for the socks proxy.
This port is probably not the one you would need to hide because it
would be encrypted into the ssh tunnel.  This local port would only be
visible to processes on the local host.

Also picking a well known service like 443 would raise suspicion in my
network scans.  Corporations often do stupid things.  I have seen them
in the past rule that all web servers must be outsourced offsite.
Then in order to enforce this they force a local scan of ports on
every host looking for anything running on ports 80 and 443.  Any host
with such a port in use gets flagged to be shut down and the web
service moved offsite.  I *have seen this*.  The corp assumption was
that in their experience web servers were single tasked and cost
zillions of dollars per second to operate and so the entire machine
would be shut down to enforce saving that money.  They had no concept
of a multiple purpose machine which could many different things and
the incremental cost of having it do something simple additionally was
virtually zero.  Therefore picking a non-WKS (well known service) is
probably better.  You would be a one-off something not worth pursuing
as opposed to one of a group of a hundred to be wacked.

> As root of course for ports under 1024. This too seems to
> work. Going to a "what's my IP" type site tells me my IP is my ssh
> server IP and not the IP of the network I'm actually on.

Of course.

> What I'm wondering is if it's actually doing what I think it's doing.

Almost.  But I think it is doing something slightly different than I
interpret your thoughts here.

> Everything I read talks about having the ssh server listen on port 443
> rather than forwarding that port
> ...
> Under what scenario would you want to have the ssh server listen on
> port 443?

The problem those talks are addressing is what do you do when you have
a firewall blocking *outgoing* connections?  Some sites have very
restrictive rules and only allow web browsing.  That means only
allowing ports 80 and 443 outbound.  If the only outgoing connections
allowed are port 80 and 443 then you can set up an sshd server running
on your remote system listening on port 443 and it can get out.  If
you can connect on port 5151 then you don't have the same problem this
tactic is trying to solve.

> but when I tried that nothing worked (i.e.  connection just timed
> out and didn't connect).

You tried setting up an sshd listening on port 443 and then tried
connecting to it with:

  ssh -D 8080 -p 443 user at ip_of_ssh_server

??  I would expect that to work unless port 443 is being blocked by a
firewall.

> The only thing I can think of is if your work or whatever
> blocks all ports but 80 and 443 and there is no way to ssh out on a
> random port like 5151. Is that accurate?

Yes.  You are correct.

> Does it matter what port the ssh server listens on (assuming you
> don't use a port that is used for something else)?

No.  It is arbitrary.  The default is 22 and if you use something
other than the default then you will always need to specify the
non-default value in a configuration either on the command line or in
an ssh client configuration file.  But otherwise it won't matter.
Whatever you choose you will need to let it into your firewall on your
system assuming that you have a firewall in place.  (Unix/GNU/Linux
systems are often operated without a firewall because the intrisic
security is okay without it and it really doesn't need one except as
an additional layer of safety net.)

> Additionally, some people suggest using a command like
> 
> ssh user at IP -L 8080:localhost:80

I like options first as POSIX and traditional use requires:

  ssh -L 8080:localhost:80 user at IP

> Or something similar. I find this syntax much more confusing that a simple
> -D switch.

The -L does something quite a bit different from -D.  The -L sets up a
single tcp tunnel from point to point.  The -D sets up a socks proxy
which can be used for a range of tcp connections from a point to the
network on the remote machine.  There is a huge difference between
those two functions.  Both do set up network tunnels.  But after that
point the behavior is quite different.  One is a boat.  The other is
French.

> Is there a solution for setting up a socks proxy that uses the -L
> (or -R) options or is this a different use? Is there any reason that would
> be better than the way I'm doing it above (i.e. ssh -D 443 -p 5151
> user at ip_of_ssh_server).

You could set up an http proxy (such as squid or simpler) on your
remote home server.  It could listen on port 8080 or some such.  Then
you could tunnel to your remote proxy using a single -L tcp
connection.  There are advantages and disadvantages.  It would
probably be higher performance because it would cache pages on the
remote end.  It would also be a little bit more complicated too.  But
not unduly.  Many people set up caching proxies and there are many
HOWTOs available.

> Hope that makes sense to someone. Thanks in advance for any help.

Hope this helps,
Bob