A plain vanilla HTTP-Proxy will happily forward any tcp/ip-connection for web browsers or any other program that asks it to do so. This can be used to establish a connection to a remote sshd, even through a local firewall (in common firewalled situations). I would very much like to see the neccessary functionality to actually do this added to ssh. (For the time being, one can probably get this up and running via "-o ProxyCommand" somehow, given appropriate external software.)
I found the documentation of the HTTP that's needed in RFC2817, in particular section 5.2. See http://www.ietf.org/rfc/rfc2817.txt .
Why should ssh have code to operate over HTTP proxies (and SOCKS proxies, and telnet proxies, and [fill-in-the-blank]) when that's exactly what ProxyCommand is for? (BTW, for HTTP a suitable proxycommand is http://www.taiyo.co.jp/~gotoh/ssh/connect.html).
> Why should ssh have code to operate over HTTP proxies ...? Convenience for its users. If the ssh authors agree with me: * There are many HTTP-Proxies out there, so * enough users could make good use of the feature under discussion, and * it is easy enough to implement it, without introducing bugs (or at least no security-related bugs), then the authors may want to choose to support it within ssh proper. Which is exactly what I propose. > telnet proxies, and [fill-in-the-blank] I agree with you. Ssh should not try to support all protocols known under the sun. When the ssh authors think a particular protocol is of minor use to the ssh user community at large, those few users that would want to use it may well be burdened with the extra hassle of integrate external software. Similar things might be said for protocols that are deemed sufficiently hard to implement flawlessly. > http://www.taiyo.co.jp/~gotoh/ssh/connect.html That is an option. Still, I think implementing the feature I request would enhance the situation, from a typical ssh user's perspective. Of course, with a package such as ssh, secrity is an important issue for its users. Personally, I have an extended previous history with, and a certain amount of trust in, that particular Linux distribution (Debian, im my case), from which I obtained my ssh installation. Using external software such as the one you propose, from a source that I have no previous relation with, is, to me, a somewhat different story. It may well be wonderful software. Yet I find myself considering to spend a certain amount of time reviewing its source. In that sense, it's an expensive software (from my point of view). If unfairly viewed as a programm to solely get the particular HTTP job done I need, it is deplorably inefficient. This should never take almost 3000 lines of code. Also, for the particular software you propose, there is no bug tracking database, such as this one. In my opinion, this does not shed a good light. Neither does the author's decision to pack that much code into a single file. At least, the revision history available informs us about previous bugs the software had, which is good. So, to sum it up: That external software you propose, definitely an option an probably well worth being considered, does not seem to come out quite on the same high level as this project does.
Sorry, but I don't think we will be adding native HTTP proxy support to OpenSSH. We have a perfectly functional mechanism which allows you to do what you need without adding more code to ssh (that we have to write, debug, document and maintain). Your perceived lack of a project surrounding Goto-san's connect.c is not a reason for us to make changes to ssh. If you don't like connect.c (which is perfectly functional - I use it myself), then you can probably cook something up in a dozen lines of Perl.
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.