passing X11 authentication and authenticated home directories

[James Ralston]

There are situations in which access to one's home directory depends
on prior authentication.  Here are several:

  - AFS (requires Kerberos-based tokens)
  - NFSv4+GSSAPI (requires a Kerberos TGT)
  - encrypted home directories (requires a token/password to decrypt)

As it stands right now, OpenSSH X11 authentication forwarding breaks
in these scenarios.  This is because unlike the approach OpenSSH takes
with GSSAPI credential delegation (creating a temporary file and
setting environment variables to point to it), OpenSSH attempts to
store the forwarded X11 authentication credentials into ~/.Xauthority.

Obviously, attempting to store the credentials in this manner will
fail if the user authenticates via a mechanism that neither acquired
nor passed credentials (e.g., public-key authentication).

For (e.g.) NFSv4+GSSAPI, one can attempt to work around this with
~/.ssh/rc, as follows:

    #! /bin/sh
    exec 1>&2
    if [ "x${KRB5CCNAME}" = x ]; then
      echo "No Kerberos credentials found; please authenticate."
      export KRB5CCNAME=`mktemp /ccache/krb5cc_${UID}_XXXXXX`
      /usr/kerberos/bin/kinit
    fi
    # call xauth here

However, the problem is that ~/.ssh/rc has no way to pass the
KRB5CCNAME value to the user's shell.  So, the user's shell must
acquire credentials (that is, prompt the user to run kinit) *again*.
This is highly undesirable.

One way to avoid the issues with public key authentication is to
disable it entirely, and permit only gssapi-with-mic and
password/keyboard-interactive authentication.  But not all clients can
perform gssapi-with-mic authentication, and password/k-i
authentication permits dictionary attacks (in contrast to public key
auth, which does not).

An intermediate-term fix would be to have OpenSSH handle forwarded X11
authentication information the same it handles forwarded GSSAPI
credentials: create a new Xauthority file in a temporary directory,
write the credentials to that file, and then set XAUTHORITY to point
to the file.  (This is actually the way OpenSSH handled forwarded X11
credentials years ago.)

Longer-term, though, a better solution would be provide more
flexibility in how authentication mechanisms are required/specified.
For example, I would like to be able to say:

    gssapi-with-mic || ( publickey && (keyboard-interactive || password))

In English: to authenticate, gssapi-with-mic auth is sufficient.
Otherwise, publickey auth *AND* one of either (keyboard-interactive,
password) auth is sufficient.

I am not certain whether the SSH v2 protocol can support such
flexibility, however.  :(

If OpenSSH publickey authentication could be put into a PAM module,
since PAM allows modules to be stacked arbitrarily, one could create
PAM rules to implement the above authentication conditions.  Again,
though, I don't know if it's possible to do that with the SSH v2
protocol.

But at any rate, right now, I'm thinking the simplest short-term thing
to do is to write a patch to make OpenSSH create temporary Xauthority
files instead of writing them into ~/.Xauthority.  However, I'm
reluctant to do that if the OpenSSH developers are completely opposed
to that idea and/or have a better suggestion.

Thoughts?