peter @
baileynm .
com (Peter da Silva) writes:
> > > Also I suppose i should ask is does sslr* have an officially sanctioned
> > > port number? and ofcourse does it have an rfc?
>
> > 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.
Sorry, my fault --- I've misread Sameers question. Yes, ssh uses port
22. I don't know about sslr*.
> 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).
Of course, protocols as secure as ssh or sslr* can be trusted straight
through your firewall :-)
Sameer R Manek <manek @
challenger .
atc .
fhda .
edu> writes:
> SSHD does have to be root (unless every user is going to run
> their own personal sshd)
Correct, but I don't really see a way to help this.
> but we are talking setuid files.
> /usr/local/bin/ssh is setuid, but does work w/o the setuid bit.
This is necessary if you want to allow host-to-host authentication and
use the ssh equivalents of /etc/hosts.equiv and ~/.rhosts. If you
turn the setuid bit off you'll be limited to use user-to-user
authentication --- not a bad way to go, but one of the design goals of
ssh was to be a transparent replacement for rsh/rlogin/rcp.
> ssh falls back to
> rsh if the remote site doesn't support ssh.
Correct, if you configure it to do so --- which most people are
paranoid enough not to. After all, using insecure protocols as telnet
and r* should only be done on a trusted network. As long as this
trusted network is controlled by a somewhat central authority a
remote site that doesn't support ssh shouldn't exist.
Of course, if you want to use ssh for Internet-wide authentication it
is probably the wrong way to go. But so are ~/.rhosts files.
> Trying to explain to users that they can't connect to another machine
> in some other department/company/school because the other department
> supports a differnt encryption standard will cause people to shy away,
Let's all switch to Windows NT!
Sorry :-)
> and complain of difficultly. Ultimately these users may do something
> that is least desireable, such as a cleartext telnet.
Then don't allow telnet or plain rsh access. If you really have to
worry about this, run both sshd and sslrshd on your machines --- in
that case both will work. However, if there's some sort of central
authority this could (and should) pick one for use.
> I couldn't agree more, a strong encyption is needed, but multiple venders
> and groups issuing r* replacements that are incomplatible with
> each other does not seem to me the best solution. This idea of multiple
> replacements seems to against the system-admin ideal.
I think in this case it's rather the ``should I use the hammer or the
soldering iron?'' question. Both protocols have their advantage in
some areas, you just pick the one most appropriate for your needs.
> Professional
> system admins are always telling me a good admin is one who can run
> a machine securely as possible, and still be as transparent as possible.
> Incompatible and competeting standards seem to go directly against this
> ideal.
OTOH, if you stuff everything in one monolithic protocol you'll
eventually start writing application-level filters (see the recent
ActiveX thread). And a complex protocol requires complex programs.
Complex programs don't improve security.
Ben
--
Ben(edikt)? Stockebrand Runaway ping.de Admin---Never Ever Trust Old Friends
My name and email address are not to be added to any list used for advertising
purposes. Any sender of unsolicited advertisement e-mail to this address im-
plicitly agrees to pay a DM 500 fee to the recipient for proofreading services.
References:
|
|
