> > Authentication is pointless without a means of ensuring the integrity of
> > the channel and encryption gives you that as a side effect.
> >
> My understanding is that authentication can be just as difficult
> for SSH as it is for telnet. Do do you believe this
> to be the case?

Unless you are talking about a non-standard telnet, that supports one
of the interesting authentication options, then there's little
comparison.  Strong authentication is not trivial to achieve. That's
true for SSH and any authenticating telnet - or login.

SSH does a reasonable job, it supports RSA, and TIS, and even passwd.
The other forms don't interest me.

> > So, with encryption as a given, why SSH and not say stelnet?
> > 
> > Standardization.  I'm speaking as one who over the years added encryption
> > to telnet in a couple of different ways - settling on SSL in the form
> > of stelnet.  Due to the (until very recent) export restrictions of the U.S.
> > everyone who wanted an encrypting telnet had to invent their own.
> > 
> Is there a reason that "invent(ing) thier own" is not good?
> It would seem to be a secure method.

Sorry, but is that a serious question?  Is this a homework assignment
we are working on?  Ok, think about this.

1. Ok, I've implemented stelnet, its nice and secure, I get strong
authentication and encryption - provided that the target host has the
appropriate server installed.

2. I have to interwork with a bunch of different sites, they've all
invented their own "*telnet".  So I have N different clients and
servers to install and maintain if I want to have secure
communications outside of my own net.

3. Wow!  A security advisory comes out, bug in telnet.  Doh!  I have N
different versions of it to rush out and fix before I can sleep
tonight.  And what about all the admins at all those other sites? have
they fixed it two in their N versions?  Am I still safe?  I don't
know...

Now that the U.S. has relaxed export restrictions somewhat, there may
well emerge a "standard" telnet which is secure, but frankly I think
its too late.  The world has standardized on SSH.

> I see your point on flexible key management, but wouldn't a centralized
> key system have the following points against it:
> 1) central point of failure

I'm talking about certs as used in SSL, there need be no single point
of failure.  I don't like the cert based authentication schemes that
rely on a directory server to hold all the public keys - they are
generally designed by people who sell directory server's.  The only
advantage they can offer is semi-real time checking if a cert has been
revoked.   Publishing CRL's is after all the big headache faced by
most PKI solutions.

> 2) implied user laziness, because only one password is need over
>    many systems.
> In point #2, wouldn't many password be more secure?

No definitely not.  In the case of PKI we are dealing with a pass
phrase which can be substantially longer than say an 8 char password. 
The more passwords you force people to use, the more trivial they will
be and the more likely they will be on post-it notes stuck to their
monitor. 

Note, I also don't think much of forcing people to change their
passwords every month - for the same reasons.

> > But guess what - I use SSH as much or more than the above.  
> > Why? Because everyone else does.  Because its "good enough"[TM] 
> > and offers features that *telnet and SSLrsh don't which I and most 
> > other users fine very handy.  I make use of its tunneling, compression
> > and single signon support (no I don't forward the authentication agent to 
> > sites I don't trust).
> > 
> So you say your willing to sacrifice some security for some
> features in SSH. Is that correct?

Yep.  Because like I said, SSH is "good enough", especially when I've
setup both client and server and avoided all the things I don't like.

> > gets the job done so that's what we all use.  SSHv2 probably would have 
> > taken over - but for the license.
> > 
> You're suggesting some issue with SSHv2. Could you elaborate on that?

The one I mentioned.  When SSHv2 first appeared it required a license
fee for use in commercial environments, so guess what, everyone still
uses SSHv1 or versions derrived from it which have no such
restrictions.  There are now SSHv2 implementations which are free -
I'm told, but they are relatively new, we'll have SSHv1 around for a
while yet.

--sjg