Print in PuTTy - Page 2

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: evaluate the best SSH client (was: Print in PuTTy)

    DM> Richard E Silverman sez:
    DM> SSH protocol requires all implementation to support PK auth.  Some
    DM> systems do not support PK auth as a standard userauth method.
    DM> Ergo protocol requires that on some systems SSH introduce (in
    DM> order to support) a non-standard userauth method.

    >>  But it does not require you to use it, so I fail to see why you
    >> think it's a problem at all, much less a failing of the protocol.

    DM> It's a feature of the protocol -- specific vendor's
    DM> implementations with value-added bells and whistles deployed on
    DM> real-life networks with their own security policies and access
    DM> control mechanisms -- aside.

You keep changing your claim.  First you said, "A properly designed
protocol would have left authentication to PAM."  You made it clear that
you thought this was a failing of the protocol, per se.  I pointed out
that simply doesn't doesn't make sense, for several reasons; SSH-AUTH
could not in any reasonable way "leave authentication to PAM."  Then you
said that the "SSH protocol requires all implementations to support PK
auth.. Ergo protocol requires that on some systems SSH introduce...  a
non-standard userauth method."  This is *false*.  Having the capability
buried somewhere in the software does not "introduce" another userauth
method, because the sysadmin selects which methods to actually enable.
Hence, it is a not a problem.  Now you call it a "feature of the
protocol," and write as if you were entirely neutral on the question of
whether it were a problem or failing of the protocol:

    DM> Whether it's a problem or a blessing is another question.

... even though your original claim was precisely that the protocol was
flawed because of this requirement.  You appear to change your mind about
what you're claiming whenever you're faced with contrary evidence.  I
cannot follow your argument or make sense of it, sorry.

    DM> It can be a blessing when it comes to setting it up and a failing
    DM> when you get to revoke user's access rights.

Once again, you are confusing authentication with authorization, and
ignoring the capabilities of existing software.  With OpenSSH (and many
other servers), you can easily revoke access to an account in a manner
which is independent of userauth method, e.g. with PAM, or bsdauth, or

I'm going to drop this now, since we don't really seem to be getting

  Richard Silverman

Re: evaluate the best SSH client (was: Print in PuTTy)

Richard E. Silverman <res(*)> wrote:
| Most EULA's on commercial software say essentially the same
| thing--disclaiming all warranties except replacing defective media.
| Support is certainly a valuable service, but let's not pretend that
| commercial software vendors provide warranties as to the correct
| functioning of their software.  Overwhelmingly, they do not.

Perhaps I let poetic metaphor obscure the point.  With a commercial
product, when something goes wrong, you can generally get somebody
on the telephone to help you.  The "something" need not be a defect
in the program: there are many possible modes of failure.  Figuring
out the source of a problem often requires technically informed
diagnostic troubleshooting, and it is unwise to expect that a naive
user can perform such troubleshooting unassisted.

Support for free software is typically obtained from volunteers, who
frequent Usenet and certain web sites in their spare time and answer
questions out of a spirit of helpfulness.  But it is very difficult
for such a volunteer to direct a troubleshooting procedure while
communicating through casual Internet means.  For some problems,
you've got to talk interactively to solve them.

(It is possible that some third-party person or company will sell
the service of providing telephone support for a free software
product, but such support is not always available.)

If an organization's users are able to get by with volunteer support,
or if the organization contains experts who can help out when one
session's output mysteriously freezes (when somebody typed Control-S
by accident!), then there is more leeway to adopt free software.

| It is not accurate to ascribe this behavior to "SSH," as if it were
| a limitation of the protocol.  Rather, it is true if you use the
| default, simplistic key-management/authorization mechanisms
| (known_hosts, authorized_keys, etc.).  The main SSH implementations,
| both free and commercial, now support Kerberos and PKI (and they
| interoperate to boot).

I'll guess that 99 and 44/100th percent of people who are connecting
via SSH are using known_hosts and authorized_keys (or equivalents).
However, if you've got a list of implementations that can use Kerberos
and PKI, please post it, and the rest of us can be better informed.


Juvenile-deliquent heifers and steers commit vandalism.

Re: evaluate the best SSH client (was: Print in PuTTy)

    RSS> However, if you've got a list of implementations that can use
    RSS> Kerberos and PKI, please post it, and the rest of us can be
    RSS> better informed.

OpenSSH and VShell/SecureCRT (VanDyke) support Kerberos via GSSAPI; Tectia
( supports both Kerberos and X.509 certificates.

  co-author: SSH, The Secure Shell (The Definitive Guide)

Re: evaluate the best SSH client (was: Print in PuTTy)

Richard S. Shuford wrote:

Quoted text here. Click to load it

Kermit 95 supports SRP, GSS-Kerberos 5, in addition to the traditional
shared keys and password based authentication methods.

Jeffrey Altman

Site Timeline