W.Kenworthy wrote:
Move the sshd instance on your server to port 443 (if you are not
running an ssl aware webserver that is ...)
This is (pretty much) what I do- I mapped port 443 to 22 at my
NAT/Firewall/router - that way I only have to deal with a peculiar port
when using SSH from remote locations. I found that corkscrew (
http://www.agroman.net/corkscrew/ ) was useful where I was forced to use
a proxy which required authentication at remote locations.
A question that I've recently been mulling is how I can retain this
invaluable capability to accept remote SSH connections on port 443 - but
also run a standard HTTPS website without needing another public IP
address. I fiddled with netcat and discovered that the two protocols
(SSH and HTTPS) behave quite differently in spite of both being
encrypted. As far as I could tell SSH required an initial message from
the server to the client, whereas HTTPS started with the client sending
the start of the request. Given that I wouldn't mind waiting a few
seconds to establish a SSH connection, it occurred to me that it should
be possible to intercept both SSH and HTTPS connections arriving on port
443; distinguish between them (by waiting to see if an HTTP request
arrives pretty quickly after the connection is established) then
forwards the data to the correct service...
+-------+ +-----+---443-->[apache]
O---443-->|NAT-BOX|--1443-->| ? |
+-------+ +-----+---22--->[sshd]
Is anyone aware of something I can use to implement the box labelled
"?"? I suppose I could write a simple proxy myself... but don't really
want to re-invent the wheel... I'm also vaguely hopeful that there may
be a more efficient lower-level solution which wouldn't require the
overhead of a process to 'pass-on' the tcp data... maybe integrated with
ipchains or pf or similar?
Any ideas?
--
[email protected] mailing list
