[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Since Fedora is not aimed at enterpise/business ..



> > Kerberos provides those features with Kerberized
> > ftp, rcp, etc.
> 
> *sigh* another person who can't seem to distinguish
> between an a authentication mechanism and apps
> compiled with support for it. Why even your words
> above should tell you that: "kerberized ftp,rcp" the
> ftp or rcp, telnet apps are providing those
services,
> kerberos is providing the authentication.

Kerberos is providing the authentication.  Kerberos is
also providing the session-level encryption.  And, as
I pointed out in that very email, Kerberos /also/
provides telnet, rlogin, rcp, rsh, and ftp clients and
daemons (i.e., they are a part of MIT's and Heimdal's
Kerberos distributions).  (Just as SSH provides scp
and sftp client and daemons.)

> > > I'd argue that SSH would be a massive need in
> > > that environment.
> > 
> > Not really true.  With Kerberos: telnet, ftp, rsh,
> > rcp, etc., etc., automagically become secure.  Not
> > only in terms of authentication, but also in terms
> > of strong encryption of sessions.
> 
> Read the post again, with open eyes this time and
> see that the environment described uses a kerberized
> ssh to do all of those functions, and that therefore
> qualifies as a "kerberized environment" that relies
> heavily on SSH. You are blindly associating apps
> compiled with kerberos *support* with the Kerberos
> itself.

I read the post again, here's what I got:  You were
saying, "I would even suggest that SSH would be a
massive need in a Kerberized environment."  I was
saying, "No, SSH is a massive need in a non-Kerberized
environment.  It's not a massive need in Kerberized
environments, because, in Kerberized environments,
ftp, rcp, rlogin, and the other services that SSH
attempts to replace are no longer insecure. 
Therefore, the massiveness of the need for SSH is
lessened in comparison to non-Kerberized networks." 
That doesn't, however, mean that SSH isn't useful in a
Kerberized environment.  It certainly is /very/ useful
on Kerberized networks (and I use it more than rlogin,
rcp, etc.).  (Actually, I never use the r* commands.)

> One is a protocol, the other is not. Think of SSL
> and you may start to get the picture. SSL doesn't
> server web pages, or serve email. It provides an
> encryption layer. I can use SSL on Apache, Zope, or
> dozens of other servers. Yet you don't claim SSL
> provides http service. Kerberos, like SSL is a
> supporting library/protocol for something else;
> it does *nothing* on it's own. SSH is it's own
> app/server. Apples and Oranges.

Last I checked SSH was a protocol defined the IETF
SECSH working group.  You're saying SSH is not a
protocol?

As I see it:  SSH is a protocol; Kerberos is a
protocol.  There are software distributions of SSH
which provide clients and servers for remote & secure
login and file transfer; there are software
distributions of Kerberos which provide clients and
servers for remote & secure login, file transfer, and
much more.

In other words, Kerberos software distributions
provide clients & servers just as SSH software
distributions provide clients & servers.  KTH-KRB
provides rsh, rlogin, rcp, telnet, ftp, pop, kx,
kauth.  Heimdal provides telnet, rsh, pop, ftp.  MIT
provides telnet, rlogin, ftp, rsh, rcp, ksu.

Seems more like Apples vs. Apple Pie, Apple Juice,
Apple Sauce, Apple Cider, etc.  *grin*  Or something.

> No, K requires additional apps to achieve some of
> the functionality of SSH. Period.

Just as SSH needs apps to achieve the functionality of
SSH?  Or just as Kerberos needs apps to achieve the
functionality of Kerberos?  Or just as anything needs
an app to achieve the functionality that that app
attempts to achieve?  *smile*

...  Actually, in the end, I get your point (and I
hope you get mine [if I even have one, that is]). 
We're gettin' nowhere fast with this thread (other
than I'm havin' a lot o' fun with all the word games).

Long live Kerberized SSH!

Derek




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]