Re: Reverse Tunnel problems

English Network/Internet
#1

On 08/26/2013 04:06 PM, zekeb wrote:
>
> I just replaced Mageia with openSUSE on my home computer. My work
> machine is behind a firewall and is running Mageia. I have a script
> that runs autossh to establish a reverse tunnel from port 22 on the work
> machine on port 2210 on my home machine.

I presume by this you mean that the connection is setup from 2210 at home
to 22 at work only, and it is initialized by connecting home via some
other method that isn’t blocked as much as connecting to work would be.
Please confirm that this assumption is correct.

> I had RSA keys in place to automate the tunnel.
> When I got to work I could ssh into my SUSE box at home with no
> problem, no password - the RSA keys did the trick.

Not using any tunnels… this seems to be fine. Just calling that out to
be sure I understand the issue.

> When I try to ssh to port 2210 on my home machine I get the following:

Just to be really clear, I assume you are running this command FROM the
home machine, as you have SSH’d from work to home and are now SSHing to
TCP 2210 on your home machine, which should be a reverse tunnel back to 22
at work. If that is incorrect please correct me. An alternative may be
to SSH directly to TCP 2210 from anywhere (in the world, assuming your box
is open to the world) which I would expect NOT to work, but I would also
expect it to not get as far as you showed below in the debugging output.

The reason the exact method matters to me is I am not sure how you have
setup keys. YOu said “I had RSA keys in place to automate the tunnel”
which, to me, means you have a private key on your work box to automate
the tunnel created when you SSH to your home box (public key previously
placed there on the home box), and that is fine. That, though, does not
mean you have setup a private key on your home box which can SSH to your
work box, or a private key on your work box that could access your home
box’s tunnel accessing the work box. Only the first situation, of those
three, should work as I’m reading this unless you also setup keys from
home to work and are now accessing work, from the home box, via the
work-box-established reverse tunnel.

Good luck.

#2

On 08/27/2013 07:06 AM, zekeb wrote:>
> Also, my firewall is down right now, to ensure I am not blocking myself
> with it.

Leave the firewall up. It never blocks connections from the local
machine, by default.

What is the 'OS switch" to which you refer? I do not remember you
mentioning that before and it may be relevant. Was it your home system,
work system, or both that switched? SSH can be VERY particular about
permissions on the ~/.ssh directory and related files, particularly when
using keys for authentication, since if a key’s permissions are incorrect
then the key may be compromised and will no longer be allowed for use.

It sounds like before the “OS switch” everything you are now trying to do
did work, so that’s a good data point to know.

A few other statements that you made could use some clarification for my
simple mind:

> I looked at the message log, and it seems like it is trying to log in
> to my work machine with: homeaccount@home.ip.address:2210
> rather than workaccount@home.ip.address:2210

Where do you see this? The command you typed used the ‘brett’ user, so it
should be using that account. If that is not your work account, fix the
portion before the ‘@’ sign in the SSH command.

Also:

> In Yast, I have opened port 22 and 2210 in the sshd configuration. If
> I remove port 2210,the connection is refused

This would have been good to know, as it explains basically everything,
when combined with everything else. I’ll try to help you come to the same
conclusion I have, which is basically that your SSH attempt to
192.168.0.196 is wrong. Please take the following as intended, to help
you learn, even if sounds a little belittling as that is not the
intention; you’re dealing with advanced stuff and everybody gets confused
on tunnels, much less reverse tunnels, at one point in time (I do every
stinkin’ day).

My guess is that you originally tried this command (from your original
post) and it failed with a connection refused:

Code:

~/.ssh> ssh -p 2210 brett@192.168.0.196 -vvv

You knew what Connection Refused meant, and knew you were trying to SSH,
so then you made a logic error and tried to configure Yast to allow access
to SSH via 2210, but you did this on your home machine. The logic error
is that you are not trying to access your home machine but instead are
trying to access your work machine. Telling Yast on the home machine is
not desired since that will cause any attempts to SSH to 2210 to access
the home machine, and not the work machine. As a result you get those
nasty “public key doesn’t match something I know” warnings that you pushed
through in your original post. My guess, though, is that the public key
posted there is actually the one for your home machine. This is what
happens when the home machine is listening on the TCP 2210 socket and you
then tell the SSH command to access that socket.

But, you ask, I had a tunnel setup. Why did it not use the tunnel? This
is an assumption error. You are assuming, as do many/most, that your
reverse tunnel is listening on all IP addresses. By default SSH’s
programmers opt for security more than convenience and, unless specified
otherwise, a tunnel listens on 127.0.0.1 by default and NOT any other IP
address, and certainly not all IP addresses. As a result your SSH command
executed at home to use the reverse tunnel should be:

Code:

~/.ssh> ssh -p 2210 brett@127.0.0.1

This will go directly to the tunnel that is listening. To verify the
tunnel is there and listening use the following command:

Code:

/usr/sbin/ss -planeto | grep :2210

Note that the output shows ‘ssh’ as the command holding open the listening
socket/tunnel. From my system I see this specifically (one line for IPv4,
one for IPv6, as I have both enabled it would seem):

Code:

LISTEN 0 128 127.0.0.1:2210 : uid:1000 ino:11581220 sk:229fb600ffff8800
LISTEN 0 128 ::1:2210 :::* uid:1000 ino:11581219 sk:b8b0c080ffff8800

In the end, leave your firewall as is, leave sshd (on both systems) as
they are (unless you really want to change ports away from 22 as I would
recommend doing on your home system to avoid a bunch of login attempts
from scum), and the rest should just work.

I hope that helps.

Good luck.

#3

Thanks ab, for reposting this. I responded right as the database crashed.

You were exactly right, there was a problem with the secure keys, I think on the work side. Anyway, regenerated both sets of keys and replaced my .ssh/authorized_keys files and it works!

Once that was working, I figured out how to get it to listen on the ip address so I could login from other machines (-g apparently does not work anymore, it did on Mageia before the OS switch?). Anyway, once I got that figured out I was up and running.

Thanks!

#4

Gateway ports should still work, but it will only work if the server
allows it, and most do not by default. Modify the /etc/ssh/sshd_config
file appropriately and restart the sshd service on the system that needs
to listen on all IPs and then try again.

Good luck.