sshd also talking HTTP

[Jan Pieter Cornet]

On Thu, Jul 10, 2003 at 07:37:51AM -0700, Dan Kaminsky wrote:
>    Your hack is useful, but (being a bit more diplomatic than Damien 
> *smiles*) indeed should be generalized into an external application.  

OK, fair enough. I'll hack up a wrapper instead.

> Rather than launching separate instances of SSHD, however, you may 
> simply use the delay to select your port forward destination.  So, your 
> app listens on 80; if any bytes are read from the 
> client(GET/HEAD/POST/TRACE/etc) you forward to a web server running 
> elsewhere, and if no bytes are read, you forward to 22.  Though 
> trickier, you can actually fool the server into believing it had the 
> original socket (thus getting the correct IP in your logs); see the 
> stunnel source to see how this is done.  It may be Linux specific, 
> though.  Anyway, this prevents loss of entropy.

Err... stunnel uses a really dirty trick that only works on recent
linux kernels with a certain masquerading module present. Rather
unportable. I'll just stomach the entropy hit and use sshd -i for now.

>    The described tactic should also work with SSL/443, which also gets 
> through firewalls well.  And, of course, there's httptunnel, which can 
> be used as an ssh transport via ProxyCommand.

Hm, httptunnel looks interesting too, but unfortunately it's by far not
mature enough to consider as a "server" application.
 
> We agree -- although, concievably, we could accept some form of proxy 
> notification from external proxies like the one I described.  There's 
> lots of precedent for this -- squid proxies notify over HTTP who they're 
> requesting pages for, and mail servers add to the headers which IP 
> address sent them the mail to be delivered.  This could be much cleaner 
> and more portable than the "transparent proxying" hack used by stunnel, 
> and would involve little more than the proxy appending 
> "ProxyFor=1.2.3.4" after the client banner (thus retaining compatibility 
> with existing servers).

That would be useful indeed, allowing me to forward to port 22 regardless.
It also allows things like httptunnel to know the correct remote IP.

Another option I considered was to allow sshd to accept fd's via a unix
domain socket. This is still hairy, but at least more portable than the
stunnel "bind(socket, some-remote-IP-addr)".

> We would have to be careful to only believe such proxies if they came 
> from localhost...

You can't even trust localhost, since any local user might connect from
it. You'd either have to configure "trusted" proxies (eg. localhost,
port <1024) or make sure a "ProxyFor=x.x.x.x" can only be used to lower
the priviledge (so for any checks against remote hosts, check both the
proxy and the proxied client).

-- 
#!perl -pl	# This kenny-filter is virus-free as long as you don't copy it
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}->(map{/p|f/i+/f/i}split//,$&)+97):('m',p,f)[map{((ord$&)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$&;$f.eig;				   # Jan-Pieter Cornet