The title sounds like a crossword puzzle clue.
I'll word the question in a way that those who already know the answer
won't have to read the story.
How can I configure a host to keep users from forwarding ports to that
machine? Their attempts should be met with the response, "connection closed
unexpectedly" and the tunnel should say, "administratively prohibited".
My real question, of course, is, how can I _undo_ this bit of nonsense.
I have been setting up and learning how to use Subversion. In this world
of many source control tools and opinions of each, it may come down to
which one has useful documentation. Actually, I let my co-workers choose
which one we were going to use. But there is a free online book written by
the program's authors, and it is both comprehensive and comprehensible.
For the server, There's More Than One Way To Do It. I chose the svnserver,
which answers connects to port 3690. This is a good choice (and favored by
the authors) as it centralizes the connections and access rights, as well
as the location for the repositories. FYI there is also an Apache web
interface. I'll play with that later (if ever).
So, this thing works. I can issue a command like this:
svn list svn://localhost/sandbox/trunk
and it will show me the files that are there. This is useful in
determining that it is working; since half the resulting questions are
usually about verifying the "normal" operation. OK, so now I want to try
this from off site. All I have to do, then, is put the real hostname (or
IP address) in where "localhost" was. The server is accessible through a
hole in the firewall and doesn't have a name of its own. But I can put one
in my hosts file and pretend that it does:
svn list svn://xyzzy/sandbox/trunk
It doesn't work. It should, though. I can connect to that machine via
ssh, and while logged in, I can do it locally. So we have all the
connectivity. Ssh works, but svn doesn't.
The port must be blocked. This makes sense, since the Cisco guy asked us
which ports we wanted open, on the occasion of replacing the accident-prone
Linksys (oh wait, that's a Cisco product, too :) with one of their
four-digit-titled products.
OK, I know there's a workaround. People talk about tunnels all the
time. Folks like me are vaguely aware of such things until such time as we
need them. Then we suddenly realize how it all fits together. I can get
through port 22 with ssh, so I just want to have my svn connection access
port 3690 on the remote computer.
ssh -L 3690:xyzzy:3690 [EMAIL PROTECTED]
Then I use that svn command from above, the one that says localhost. When
it connects to 3690 on my local machine, ssh forwards it to 3690 on the
remote machine and things should happen as planned. They don't. I get
the previously mentioned errors. The response from the svn command is:
svn: Connection closed unexpectedly
While the currently running tunnel (with an active login shell) says,
channel 2: open failed: administratively prohibited: open failed
Some of the most vexing problems I've had, have to do with firewalls. They
kept me from using ssh initially. Then ftp. I still can't get samba to do
the "name service" thing. Most were resolved by running lokkit, aka "don't
watch my hands, just look at the curtain". Google shows that everyone
recognizes this message as meaning "the firewall is keeping you from
forwarding" but no one seems to actually remember how this is done.
Is it Subversion? I doubt it. Subversion just knows the connection
failed. It's the tunnel that gives the "prohibited" message. I even tried
the same thing with the webserver (port 80) instead; got the same result.
Is the tunnel working? While I can't prove it, I can find a lot of
examples that look just like mine. If I take down the tunnel the error
from svn changes to "connection refused".
Is the firewall blocking ports? iptables -L shows no rules at all;
hosts.allow/deny have no entries.
Is sshd blocking it? The config file(s) have everything commented out
except to allow X11 forwarding. Everything I've seen implies that the
default is to allow forwarding. Other messages I've read suggest that
blocking is so easy to circumvent that no one turns it on anyway.
What about "AllowTcpForwarding"? Well, the default is "yes". This is
actually the item referred to above. I guess I'll try it anyway.
How about "GatewayPorts"? That only affect other hosts trying to take
advantage of your tunnel.
You don't have permission? Port 3690 doesn't _need_ permission. It's
unprivileged. I logged in as root just to dispel any other theories about
user permissions or unprivileged forks.
Is it even sshd? Hard to say; that's why I'm posting the question. One
message I found associated the error message with the file "channels.c" In
there I found some error reporting but I'd have to collect the whole set to
find out where this error really comes from. And I suspect it may not even
be ssh's fault--it could be an open failure from the kernel. Which takes
us back to the firewall. Wherever that is these days.
Barry "Not too good at short questions"
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
