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

From: Richard E. Silverman (res_at_qoxp.net)
Date: 02/10/05

  • Next message: Richard E. Silverman: "Re: Where do the random numbers come from?" 
    Date: 09 Feb 2005 20:41:41 -0500

    >>>>> "DM" == Dimitri Maziuk <dima@127.0.0.1> writes:

        DM> My comment was that it *is* accurate to ascribe this behaviour to
        DM> ssh because its easy low-overhead secure connection scheme comes
        DM> with a side effect: it bypasses standard mechanisms for account
        DM> locking, environment setup, etfc.

    No, this is an implementation detail; it is not implied by the protocol in
    any way whatsover. And in fact, your claim is patently false in at least
    one implementation: OpenSSH. If UsePAM is set, then general
    administrative measures such as account locking, /etc/nologin, environment
    customization etc. will be applied to all logins, regardless of
    authentication method, according to the sysadmin's PAM configuration for
    the SSH service.

    The things you mention are authorization. Authentication is a separate
    issue; for that see below.

        DM> "Simplictic" or not, it *is* the default mechnism,

    False. "Default mechanism" means "the one which will be used if not
    otherwise specified." Which userauth methods are offered by the server,
    tried by the client, and in what order is a matter of implementation, and
    not fixed by the protocol at all.

        DM> and the only one guaranteed to be implemented -- *by the rfc*. In
        DM> my book that makes it a feature of ssh protocol.

    SSH-AUTH defines a client->server authentication protocol. In order to
    ensure interoperability, it requires the implementation of a particular
    authentication method. The required method must be self-contained; it
    cannot rely on substantial external baggage that may or may not be
    available on some particular host. If the protocol *required* the
    implementation of, say GSS -- to name one system which can delegate
    authentication to existing host infrastructure -- then SSH-AUTH would be
    *unimplementable* on a wide variety of hosts. And even then, the problem
    would still not be solved, because though you might be happy, the sysadmin
    of a FooOS box that uses FooAuth would be outraged, complaining that SSH
    "demands" broken implementation on *his* boxes. The most the protocol can
    do, is exactly what it does:

    1) Define a few simple, self-contained methods, and require a subset of
       them, to ensure the widest possible interoperability, and

    2) Make the protocol extensible, so that more specialized methods can be
       implemented at will and where needed.

    When you select an SSH implementation for you Unix box, if you have a
    requirement to use GSS or Kerberos or PAM or whatever, then select an
    implementation that has these features. If your policy dictates that
    publickey doesn't fit, then turn it off. 

    -- 
  Richard Silverman
  res@qoxp.net
  • Next message: Richard E. Silverman: "Re: Where do the random numbers come from?"

    Relevant Pages