Re: evaluate the best SSH client (was: Print in PuTTy)
From: Richard E. Silverman (res_at_qoxp.net)
Date: 09 Feb 2005 20:41:41 -0500
>>>>> "DM" == Dimitri Maziuk <firstname.lastname@example.org> 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 email@example.com