[vox-tech] sshd_config and PasswordAuthentication

[Karsten M. Self]

on Thu, Jul 07, 2005 at 07:43:52AM -0700, Henry House (hajhouse at houseag.com) wrote:
> P? 2005-07-07, skrev Jay Strauss:
> > Hi,
> > 
> > I have a sveasoft box, and in order to ssh from the sveasoft to a target 
> > box, the target box must have PasswordAuthentication yes in the 
> > /etc/ssh/sshd_config file.
> > 
> > I don't understand what that config option actually does.  The config 
> > file has:
> > 
> > # To disable tunneled clear text passwords, change to no here!
> > 
> > Does this mean you can send clear text passwords to login?
> > Does this mean that when you build a tunnel, passwords are sent clear 
> > text to the forwarded app?

The curious can read the SSH protocols here:

    http://www.snailbook.com/protocols.html

...which I've done.  I've been using SSH for years, but only understand
some parts of it vaguely.

 
> No, SSH never passes password across the net in cleartext. They are
> sent to the remote host when using this option, which means that
> unless you have a different password for each host, a malicious remote
> administrator could capture your password and then use if to
> compromise your other accounts.

In more detail:

  - When an SSH session is initiated, an encryption key is negotiated.
    This is _prior_ to authentication.

  - The client and server exchange lists of supported encryption
    ciphers, and decide on one to use.

  - A Diffie-Hellman Key Exchange is transacted.  From:

        http://www.snailbook.com/docs/transport.txt

        The Diffie-Hellman (DH) key exchange provides a shared secret
        that can not be determined by either party alone.  The key
        exchange is combined with a signature with the host key to
        provide host authentication.  This key exchange method provides
        explicit server authentication as is defined in Section 7.

        In the following description (C is the client, S is the server;
        p is a large safe prime, g is a generator for a subgroup of
        GF(p), and q is the order of the subgroup; V_S is S's version
        string; V_C is C's version string; K_S is S's public host key;
        I_C is C's KEXINIT message and I_S S's KEXINIT message which
        have been exchanged before this part begins):


        1.  C generates a random number x (1 < x < q) and computes e =
            g^x mod p.  C sends "e" to S.

        2.  S generates a random number y (0 < y < q) and computes f =
            g^y mod p.  S receives "e".  It computes K = e^y mod p, H =
            hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these
            elements are encoded according to their types; see below),
            and signature s on H with its private host key.  S sends
            "K_S || f || s" to C.  The signing operation may involve a
            second hashing operation.

        3.  C verifies that K_S really is the host key for S (e.g.,
            using certificates or a local database).  C is also allowed
            to accept the key without verification; however, doing so
            will render the protocol insecure against active attacks
            (but may be desirable for practical reasons in the short
            term in many environments).  C then computes K = f^x mod p,
            H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K),
            and verifies the signature s on H.

        <...>

        The hash H is computed as the HASH hash of the concatenation of the
        following:

          string    V_C, the client's version string (CR and NL excluded)
          string    V_S, the server's version string (CR and NL excluded)
          string    I_C, the payload of the client's SSH_MSG_KEXINIT
          string    I_S, the payload of the server's SSH_MSG_KEXINIT
          string    K_S, the host key
          mpint     e, exchange value sent by the client
          mpint     f, exchange value sent by the server
          mpint     K, the shared secret

        This value is called the exchange hash, and it is used to
        authenticate the key exchange.  The exchange hash SHOULD be kept
        secret.

        The signature algorithm MUST be applied over H, not the original
        data.  Most signature algorithms include hashing and additional
        padding - for example, "ssh-dss" specifies SHA-1 hashing.  In
        that case, the data is first hashed with HASH to compute H, and
        H is then hashed with SHA-1 as part of the signing operation.

  - Once the session key has been established, other data (including
    passwords) can be transferred across the now-secure channel.  If you
    are using password authentication, you are trusting the remote
    server (as Henry notes), but you are not susceptible to on-the-wire
    evesdropping.




> With PasswordAuthentication set to no, SSH-key authentication must be
> used instead of a password. This method uses public/private key pairs
> created by ssh-keygen(1) to authenticate. This is generally considered
> more secure than tunneled-password authencation for reasons than
> someone else can explaim better than I can.

I'll take a stab at it:

  - With SSH-key authentication, you're not sending a password to a
    host.  If you are the victim of a MitM (man in the middle) attack,
    you've just shipped a hash based on your private key (and verifiable
    with your public key), not a password.  Risk of password loss is
    reduced.

  - You allow access for a given SSH key with a list of authorized keys
    in ~/.ssh/authorized_keys .  You can disable access by a given key
    simply by deleting or commenting its line in this file.

  - Cracking SSH keys is markedly more difficult (and practically:
    computationally infeasible) than mounting a dictionary attack on a
    password file.  Given that on any given multiuser system, some users
    are likely to have weak passwords and/or passwords common to
    multiple systems (as a rule I try to avoid this), this is a benefit.

  - A a server administrator, by disabling password authentication and
    requiring SSH-key auth, you are eliminating the possibility that
    password disclosure itself will allow unauthorized access to your
    system.  Eve would have to gain _both_ the private key _and_ its
    passphrase to access the system.

  - Users can more feasibly create individual SSH keys from different
    clients they might connect to a server from, rather than using the
    same password.  If access from a given client is to be denied, the
    corresponding key can be deleted from that user's authorized_keys
    file on the server.

  - Users can generate new SSH keys and transfer them to the server as
    needed, and with considerably less cognitive overhead than trying to
    memorize a new password.

  - Use of SSH-key auth allows use of ssh-agent.  This allows a user to
    validate one or more public keys on a client, to be used
    automatically in connection(s) to one or more remote server(s).  The
    result is that passwordless access (once the agent has been loaded)
    is available.  It's possible to set various parameters, including
    timeouts on authentication (similar to sudo), read that fine manual
    for details.  ssh-agent is a slight trade-off of convenience for
    security, but if you're in the habit of locking your workstation
    (xscreesaver screen lock) when away from keyboard, it's a pretty
    safe compromise.



Peace.

-- 
Karsten M. Self <kmself at ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Obviously it's not going to be trivial to run GNOME apps outside
    of GNOME.
    - Adam Hooper, clarifying the topic of GNOME interoperability
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://ns1.livepenguin.com/pipermail/vox-tech/attachments/20050715/96fe8790/attachment-0001.pgp