Looks like we can use pykerberos, if only there were better examples.
Added dumb implementation in r18693 using pykerberos.
Going forward, we should use the tokens rather than the password, and maybe even use python-gssapi for encryption?
Based on centos 6: configuring a kerberos 5 server, and made harder by the fact that my LAN doesn't have a domain or DNS server...
hostname localdomain
/usr/sbin/kdb5_util create -s
cat > /etc/krb5.conf << EOF includedir /etc/krb5.conf.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] dns_lookup_realm = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false default_ccache_name = KEYRING:persistent:%{uid} default_realm = LOCALDOMAIN [realms] LOCALDOMAIN = { kdc = localhost admin_server = localhost } [domain_realm] localdomain = LOCALDOMAIN EOF
echo "*/admin@LOCALDOMAIN *" > /var/kerberos/krb5kdc/kadm5.acl
kadmind krb5kdc
kadmin.local -q "addprinc test/admin"
kinit admin kadmin -q "addprinc xpra"
The https://pythongssapi.github.io/python-gssapi/latest/gssapi.html.
For win32, we could use pykerberos.
client:
$ python import gssapi service_name = gssapi.Name("xpra") ctx = gssapi.SecurityContext(name=service_name, usage="initiate") k = ctx.step()
server:
from gssapi import creds as gsscreds from gssapi import sec_contexts as gssctx server_creds = gsscreds.Credentials(usage='accept') server_ctx = gssctx.SecurityContext(creds=server_creds) server_ctx.step(k) print(server_ctx.complete)
client:
v,c = kerberos.authGSSClientInit("xpra") assert v==1 kerberos.authGSSClientStep(c, "") k = kerberos.authGSSClientResponse(c)
server:
v,c = kerberos.authGSSServerInit("xpra") assert v==1 r = kerberos.authGSSServerStep(c, k) assert r==1
Things to think about:
The overloading of the "digest" list to add and detect support for "kerberos" and "gss" options is a bit ugly, but it is the most backwards compatible way. Older clients will just state that they don't support "kerberos" (or "gss") rather than failing in more obscure ways.
Examples:
xpra start --start-child="xterm" --bind-tcp=0.0.0.0:10000 --tcp-auth=kerberos-token,service=xpra
xpra start --start-child="xterm" --bind-tcp=0.0.0.0:10000 --tcp-auth=gss,service=xpra
TODO:
patch for building with mingw
On win32, building https://github.com/mongodb-labs/winkerberos/issues/21.
Installing winkerberos from the modified source requires one more hack to prevent cx_freeze from messing up the packaging, as per stopping setup.py from installing as egg, we have to use pip to ensure it does not get installed as an egg:
pushd winkerberos-0.7.0 python2 setup.py sdist popd pip2 install ./winkerberos-0.7.0/dist/winkerberos-0.7.0.tar.gz pip3 install ./winkerberos-0.7.0/dist/winkerberos-0.7.0.tar.gz
First, install gss support: r18758, ie on x86_64:
pacman -S mingw-w64-x86_64-gss
Building python-gssapi:
gss.h
with MSYS2 and not gssapi/gssapi.h
:
sed -i -e 's+gssapi/gssapi.h+gss.h+g' gssapi/raw/python_gssapi.h sed -i -e 's+gssapi/gssapi.h+gss.h+g' gssapi/raw/python_gssapi_ext.h sed -i -e 's+gssapi/gssapi_krb5.h+gss.h+g' gssapi/raw/python_gssapi_krb5.h
gss_mech_krb5
in gssapi/raw/mech_krb5.pyx
:
cdef extern from "python_gssapi_krb5.h": pass def make_OID(s): import struct v = struct.pack("@Is", len(s), s) return v pkrb5 = make_OID(b"\x2A\x86\x48\x86\xF7\x12\x01\x02\x02") cdef char *gss_mech_krb5_str = pkrb5 pprincipal = make_OID(b"\x2A\x86\x48\x86\xF7\x12\x01\x02\x02"); cdef char *GSS_KRB5_NT_PRINCIPAL_NAME_str = pprincipal cdef gss_OID gss_mech_krb5 = <gss_OID> gss_mech_krb5_str cdef gss_OID GSS_KRB5_NT_PRINCIPAL_NAME = <gss_OID> GSS_KRB5_NT_PRINCIPAL_NAME_str
(and if I got this wrong, gss won't work...)
GSSAPI_MAIN_LIB=$MSYSTEM_PREFIX/bin/libgss-3.dll \ GSSAPI_LINKER_ARGS="-lgss" \ GSSAPI_COMPILER_ARGS="-fPIC" \ python2 ./setup.py install
(clean and repeat with python3)
setup.py
:
try: prefix = get_output('krb5-config gssapi --prefix') except: prefix = ""
Changes submitted upstream: support building against mingw headers.
Lots of improvements in r18780 (see commit message).
Examples (add -d auth
for debug):
XPRA_KERBEROS_SERVICES="xpra" xpra attach tcp://localhost:10000/ --challenge-handlers=kerberos
xpra attach tcp://username:unusedpassword@localhost:10000/ --challenge-handlers=prompt
XPRA_PASSWORD
environment variable for the first challenge, then the URI one for the second (when using multiple tcp-auth
arguments when starting the server):
XPRA_PASSWORD=password1 xpra attach tcp://username:passwordno2@localhost:10000/ --challenge-handlers=env,uri
Updates:
Ready for testing. There are packages for most platforms.
@maxmylyn: apart from testing the obvious command lines (ie: comment:8), the difficult thing is testing single-sign-on with gss / kerberos because this requires a Authentication : kerberos Please keep this ticket tidy as this will be the reference until the details are wiki-ized.
The changes have been merged upstream, we should package this in mingw: #2170
See also: #1796
MSYS2 packaging for these modules: #2170.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1691