>> > Also I suppose i should ask is does sslr* have an officially sanctioned
>> > port number? and ofcourse does it have an rfc?
No, though I guess it should - I run it on port 414
And it has been suggested that the service name should be shells not SSLshell.
The next release may address these and have a more clearly stated
license policy :-)
>> It uses port 22, which is still unassigned to my last version of the
>> Assigned Numbers (RFC 1700, 1994/10). Until now there's no RFC about
>> it, but the package comes with a draft.
>Not good. That's what ssh is using too.
Actually the question was about SSLr*, but the guy was talking about
ssh.
>My big question, is SSLr* proxyable? SSH isn't (you have to log in to the
>proxy host, then run a separate ssh from there, which rules out SCP and
>the like).
Not really, SSLr* _is_ r* only the transport an authentication model
are changed. Though you can override the port to be used, so you
could setup plug-gw's on various ports. Not really what I'd call
proxying.
If there is much demand for it, ssl_rcmd() could probably be modified
to handle HTTPS's CONNECT protocol, so you could possibly just use
your WEB proxy - I'll look into that. Anyway you do it though, you
can forget your secondary error/signal channel...
For interactive sessions, you can proxy ssh btw. At one site where I
work I have set up tn-gw to treat port 22 as a "raw" port, and the
guys who use ssh have hacked themeslves a simple proxy that negotiates
the connection via tn-gw, and then hands the socket to ssh - I think
that is how it works.
Oh, and SSLr* does not include rlogin - way too many system
dependencies and stelnet using X.509 certs provides for auto login
anyway.
--sjg
--
Simon J. Gerraty <sjg @
quick .
com .
au>
#include <disclaimer> /* imagine something _very_ witty here */
Follow-Ups:
References:
|
|
