I want to serve webpages from a server that will only have port 22 open
for ssh traffic. Using the latest versions of openssh on Redhat 9.0 and
putty on a Windows XP box, I have a functional connection and port
forwarding of L3080 to port 80 on the server in putty. I can access the
default page (index.php) on the server by looking for
http://localhost:3080 on the windoze machine, but I run into trouble
when I try to reference pages in directories below the top level (httpd
message 301).

I am guessing that it is the httpd server who is getting confused by the
addressing, but I am at a loss as to what would be the appropriate way
to work around this problem. Any suggestions would be much appreciated.

Thanks,

Stefan Engström

[ Post a follow-up to this message ]

Set your browser to use the forwarded socket as an HTTP proxy and use the
correct URL's for the information.

--
Richard Silverman
res@qoxp.net

[ Post a follow-up to this message ]

Richard E. Silverman <res@qoxp.net> writes:
quote:

>Set your browser to use the forwarded socket as an HTTP proxy and use the
>correct URL's for the information.


Why?  Just so that he can turn off the proxying anytime he wants to go
elsewhere?  Is it worth it just to avoid configuring the HTTP server
correctly?

Fix the server.  There's nothing "incorrect" about what's being done.

--kyler

[ Post a follow-up to this message ]

I don't understand the point of the exercise at all.

SSL/TLS.  QED.

SSLv3 w/client auth?

[ Post a follow-up to this message ]

>>>>> "KL" == Kyler Laird <Kyler@news.Lairds.org> writes:

KL> Richard E. Silverman <res@qoxp.net> writes:[QUOTE] 

KL> Why?  Just so that he can turn off the proxying anytime he wants
KL> to go elsewhere?  Is it worth it just to avoid configuring the
KL> HTTP server correctly?

A web server using HTTP 1.1 is sensitive to the hostname portion of the
URL, delivered to it via the HTTP "Host" attribute.  This is commonly used
to allow a single web server to deliver different content for the same
path depending on the hostname, i.e. "virtual hosting."  This works
because the admin can reasonably control what names are available to reach
the server machine, and configure the web server to recognize them.

This breaks down, however, if a client uses some other name unknown to the
server in order to reach it.  The server's response in this case is
implementation-dependent; it might just return an error.  Apache will
interpret the URL path in the context of the first virtual host defined in
its configuration.

This problem comes up when trying to access a web server via simple SSH
forwarding.  To access the forwarded port, the user types in a URL with a
hostname referring to the SSH client (in this case, "localhost", but it
might be anything).  But this not only allows the client to make the
connection; the hostname is also delivered as-is to the web server as part
of the request.  The server is not generally configured to recognize
"localhost" as one of its virtual web domains, and so something usually
goes wrong -- the poster says he gets the correct "default page," but has
trouble accessing other pages; this is typical of what happens with Apache
in this scenario, where it serves up content from the default virtual
host in response to an unrecognized Host attribute.

KL> Fix the server.  There's nothing "incorrect" about what's being
KL> done.

There is no way to "fix the server," in general.  The server depends on
receiving correct Host attributes from the client to serve up its various
content trees.  It cannot know in advance what name the client might use
in order to access its SSH-forwarded ports.  Furthermore, there will
generally only be one of those, whereas there may be several different
virtual hosts whose data the client may want to access.  To fix this on
the client side, you would have to arrange for the client's naming service
to map the domain names of the virtual hosts to the IP address of the web
server -- thus wreaking havoc with any other attempts to reach the same
machine using another application or protocol.  And the local setup would
have to be frobbed any time new names and virtual hosts are defined on the
server.  This approach is fragile and more trouble than it's worth.

The simple way to get correct behavior is to decouple the name used for
accessing the server TCP socket from the name supplied as part of the
URL.  Setting the forwarded socket as the browser's HTTP proxy does this.

--
Richard Silverman
res@qoxp.net

[ Post a follow-up to this message ]

>>>>> "MS" == Michael Sierchio <kudzu@tenebras.com> writes:

MS> I don't understand the point of the exercise at all.
MS> SSL/TLS.  QED.
MS> SSLv3 w/client auth?

The OP would have to answer, but typically one does this to access a web
server which is behind a firewall, where the only way in is SSH.  It may
not be practical to make the web server accessible to the Net.  Even if it
is, there is a cost in doing so, since now you have yet another exposed
service to monitor, another piece of software to watch out for security
updates on, typically another set of AAA info to manage for separate HTTP
and/or SSL user authentication, etc. -- instead of just taking advantage
of the existing SSH setup.

--
Richard Silverman
res@qoxp.net

[ Post a follow-up to this message ]

Thanks to all who responded for the feedback, it was educational
although it was a peculiarity of the server that caused me the problem -
it would not recognize the default content of a directory unless there
was a "/" at the end of the address.

"Fixing the server" seems to be the most closest to the needed fix,
although just adding the slash certainly is easy :-)

The reason for doing this is rooted in paranoia. Port 22 will be the
only thing open on this machine for security reasons, but much of the
applications I need are web-based databases.

-Stefan

Kyler Laird wrote:
quote:

> Richard E. Silverman <res@qoxp.net> writes:
>
> 
>
>
> Why?  Just so that he can turn off the proxying anytime he wants to go
> elsewhere?  Is it worth it just to avoid configuring the HTTP server
> correctly?
>
> Fix the server.  There's nothing "incorrect" about what's being done.
>
> --kyler

[ Post a follow-up to this message ]

Richard E. Silverman <res@qoxp.net> writes:
quote:

>A web server using HTTP 1.1 is sensitive to the hostname portion of the
>URL, delivered to it via the HTTP "Host" attribute.


Yes, but it's probably not required in this case.  Have I missed something
to the contrary?

Even if it is, the default for access through the loopback interface could
be set in the configuration to do what's desired.
quote:

>Furthermore, there will
>generally only be one of those, whereas there may be several different
>virtual hosts whose data the client may want to access.  To fix this on
>the client side, you would have to arrange for the client's naming service
>to map the domain names of the virtual hosts to the IP address of the web
>server -- thus wreaking havoc with any other attempts to reach the same
>machine using another application or protocol.


I commonly set up names such as foo.localhost to point at the loopback
adapter (to get around SSH known_hosts problems).  With control of both
the SSH client and the HTTP server, it'd be easy to make it work.

It's still not clear to me that the OP needs that complexity though.

If that level of complexity *is* needed and a clean solution is desired,
I'd suggest putting Apache on the remote end and proxying everything
through it.  Then tell it how to use the SSH tunnels.  (I've done this
too.  It's slick.)

--kyler

[ Post a follow-up to this message ]