James Ralston
2009-Apr-07 21:09 UTC
passing X11 authentication and authenticated home directories
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?
Daniel Kahn Gillmor
2009-Apr-07 23:25 UTC
passing X11 authentication and authenticated home directories
On 04/07/2009 05:09 PM, James Ralston wrote:> 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.You might be interested in the commentary and patches associated with bug 983, tracking the idea of required authentication steps: https://bugzilla.mindrot.org/show_bug.cgi?id=983 Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090407/af606144/attachment.bin
Seemingly Similar Threads
- intermittent problems obtaining shell with gssapi-with-mic
- treat output of sshrc as environment assignment lines?
- [Bug 3203] New: Could default_ccache_name from krb5.conf be used for GSSAPI connections?
- kerberos default_ccache_name with sssd
- [Bug 983] Required authentication