I have Ubuntu -LTS with kernel 3.13.0-61 Sssd 1.12.5 I am preparing production setup based on Ubuntu; gss-proxy looks a bit adventures for production. What sssd vwrsion do you recommend for profuction? In Ubuntu repositories are 2 choices:
1.11.7 1.12.5 Actually I really don't know what is getting wrong. best Longina > -----Oprindelig meddelelse----- > Fra: sssd-users-boun...@lists.fedorahosted.org [mailto:sssd-users- > boun...@lists.fedorahosted.org] På vegne af Dmitri Pal > Sendt: 30. juli 2015 16:07 > Til: sssd-users@lists.fedorahosted.org > Emne: Re: [SSSD-users] ssh passwordless with sssd-1.12.5 problem!! > > On 07/30/2015 08:58 AM, Longina Przybyszewska wrote: > > Hi again, > > After implementing the recommended change my setup seemed to work > fine with passwordless SSH and kerberized NFS4. > > > > Unexpectedly, after credentials expired (I got the message "key expired" > !), I can't mount home directory at all, not only in ssh session, but also > login > locally to the client workstation. > > After client reboot, access to users NFS homedir is lost as well. > > > > Does the [plugin] change in krb5.conf could have impact on nfs service > too? > > > > [plugins] > > > > localauth = { > > module=sssd:/usr/lib/x86_64-linux- > gnu/sssd/modules/sssd_krb5_localauth_plugin.so > > enable_only = sssd > > } > > > > I noticed that SSH session uses in-MEMORY cache ; NFS server is setup > > with ccache in /tmp If I compare ssh<->nfs sessions it seems that user's > principal credentials never get through to the server. > > (successful ssh session in the previous mail). > > What is wrong? > > > > ------nfs session (rpc.svcgssd) on server------- entering poll leaving > > poll handling null request > > svcgssd_limit_krb5_enctypes: Calling gss_set_allowable_enctypes with 7 > > enctypes from the kernel [6404] 1438257362.977400: Decrypted AP-REQ > > with server principal nfs/nfssrv.adm.c.sdu.dk@A.C.REALM: > > aes256-cts/0F5A [6404] 1438257362.977427: AP-REQ ticket: > > LNX-LEIA$@A.C.REALM -> nfs/nfssrv.adm.c.sdu.dk@A.C.REALM, session > key > > aes256-cts/DD8F [6404] 1438257362.978032: Negotiated enctype based on > > authenticator: aes256-cts [6404] 1438257362.978057: Authenticator > > contains subkey: aes256-cts/0652 [6404] 1438257362.978106: Creating > > AP-REP, time 1438257362.982778, subkey aes256-cts/41C3, seqnum > > 738956702 sname = LNX-LEIA$@A.C.REALM > > > > DEBUG: serialize_krb5_ctx: lucid version! > > prepare_krb5_rfc4121_buffer: protocol 1 > > prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size > > 32 doing downcall > > mech: krb5, hndl len: 4, ctx len 52, timeout: 1438293240 (35878 from now), > clnt: <null>, uid: -1, gid: -1, num aux grps: 0: > > sending null reply > > > > best > > Longina > > With ticket renewal (if this is the case) the right approach is to take > advantage of gss-proxy. > https://fedorahosted.org/gss-proxy/wiki/NFS > > > > >> -----Oprindelig meddelelse----- > >> Fra: sssd-users-boun...@lists.fedorahosted.org [mailto:sssd-users- > >> boun...@lists.fedorahosted.org] På vegne af Longina Przybyszewska > >> Sendt: 14. juli 2015 17:08 > >> Til: 'End-user discussions about the System Security Services Daemon' > >> Emne: Re: [SSSD-users] ssh passwordless with sssd-1.12.5 > >> > >> Hi again, > >> Thanks - it seems to work! > >> I am not sure if k5login directory and .k5login play any role in > >> success - I need to check it out. > >> > >> First, I put k5login entries into krb5.conf on both, client and > >> server, and tried ssh - It didn't work, I was asked for password. > >> > >> [krb5.conf] on both. > >> ... > >> k5login_directory = /usr/share/ssh/%u k5login_authoritative = true > >> ignore_acceptor_hostname = true ... > >> ..... > >> > >> > >> [Kerberos part of output from " KRB5_TRACE=/tmp/1.txt /usr/sbin/sshd > >> -D - d -d -d "] > >> > >> less 1.txt > >> > >> > >> [2863] 1436879405.741004: Decrypted AP-REQ with server principal > >> LX101$@A.C.REALM: aes256-cts/2CCB [2863] 1436879405.741095: AP-REQ > >> ticket: longina@N.C.REALM-> LX101$@A.C.REALM, session key aes256- > >> cts/2E16 [2863] 1436879405.799281: Negotiated enctype based on > >> authenticator: aes256-cts [2863] 1436879405.799314: Authenticator > >> contains > >> subkey: aes256-cts/1399 [2863] 1436879405.799475: Resolving unique > >> ccache of type MEMORY [2863] 1436879405.799493: Initializing > >> MEMORY:pvs4jFN with default princ longina@N.C.REALM [2863] > >> 1436879405.799504: Removing longina@N.C.REALM-> > >> krbtgt/N.C.REALM@N.C.REALM from MEMORY:pvs4jFN [2863] > >> 1436879405.799514: Storing longina@N.C.REALM-> > >> krbtgt/N.C.REALM@N.C.REALM in MEMORY:pvs4jFN [2863] > >> 1436879405.799566: Creating AP-REP, time 1436879405.736646, subkey > >> aes256-cts/7528, seqnum 774738294 > >> > >> [2863] 1436879405.804209: Destroying ccache MEMORY:pvs4jFN > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > >> After adding to krb5.conf on server [plugins] as you suggested - I > >> could login without passwd . > >> The difference is in the last line of KRB -part of output: > >> > >> [plugins] > >> > >> localauth = { > >> module=sssd:/usr/lib/x86_64-linux- > >> gnu/sssd/modules/sssd_krb5_localauth_plugin.so > >> enable_only = sssd > >> } > >> > >> ..... > >> [3534] 1436884067.287402: Decrypted AP-REQ with server principal > >> lx101$@A.C.REALM: aes256-cts/2CCB [3534] 1436884067.287447: AP-REQ > >> ticket: longina@N.C.REALM -> lx101$@A.C.REALM, session key aes256- > >> cts/2E16 [3534] 1436884067.358812: Negotiated enctype based on > >> authenticator: aes256-cts [3534] 1436884067.358841: Authenticator > >> contains > >> subkey: aes256-cts/3DE0 [3534] 1436884067.359004: Resolving unique > >> ccache of type MEMORY [3534] 1436884067.359023: Initializing > >> MEMORY:pJb8FBS with default princ longina@N.C.REALM [3534] > >> 1436884067.359035: Removing longina@N.C.REALM -> > >> krbtgt/N.C.REALM@N.C.REALM from MEMORY:pJb8FBS [3534] > >> 1436884067.359045: Storing longina@N.C.REALM -> > >> krbtgt/N.C.REALM@N.C.REALM in MEMORY:pJb8FBS [3534] > >> 1436884067.359101: Creating AP-REP, time 1436884067.280266, subkey > >> aes256-cts/4AD9, seqnum 458315653 > >> > >> [3534] 1436884067.630732: Initializing > >> FILE:/tmp/krb5cc_10002_4NMbBVHudH with default princ > >> longina@N.C.REALM > >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > >> I must say, that "localauth" is not mentioned in manual for > >> krb5.conf, but works! Impossible to figure out by myself! > >> > >> Thank you very much for help. > >> > >> Mvh > >> Longina > >> > >> > >>> -----Oprindelig meddelelse----- > >>> Fra: sssd-users-boun...@lists.fedorahosted.org [mailto:sssd-users- > >>> boun...@lists.fedorahosted.org] På vegne af Sumit Bose > >>> Sendt: 13. juli 2015 09:57 > >>> Til: End-user discussions about the System Security Services Daemon > >>> Emne: Re: [SSSD-users] ssh passwordless with sssd-1.12.5 > >>> > >>> On Fri, Jul 10, 2015 at 04:50:39PM +0000, Longina Przybyszewska wrote: > >>>> Hi, > >>>> .k5login doesn't help . Homedir is mounted with sec=krb5 and not > >>>> accessible on ssh server side Until get validated krb principal > >>>> credentials - > >>> which seems to be my problem. > >>> > >>> You can use k5login_directory in krb5.conf to use a different > >>> directory for testing. > >>> > >>>> I have noticed , I have no libpam-krb5 module in PAM I have > >>>> libpam-sss module, which seems to be enough to deal with krb > >>>> principals for NFS-mounts and GUI logins and ssh logins with passwd. > >>>> > >>>> With SSSD I can login as 'longina' to machine from @A.C.REALM > >>>> domain and > >>> get my Kerberos TGT for principal longina@N.C.REALM. > >>>> Trying SSH - Service tickets nfs/fqdn@A.C.REALM and > >>> host/fqdn@A.C.REALM seem to be ok but user not accepted without > >>> passwd. > >>>> SSH should talk to SSSD through PAM , well? > >>> In general yes, but for GSSAPI authentication sshd has to do the > >>> Kerberos ticket validation on it's own. With recent versions of MIT > >>> Kerberos SSSD can help with the principal to username mapping. If > >>> your krb5.conf man page says anything about a localauth plugin you > >>> can try to add something like > >>> > >>> [plugins] > >>> localauth = { > >>> module = sssd:/usr/lib/sssd/modules/sssd_krb5_localauth_plugin.so > >>> enable_only = sssd > >>> > >>> to your krb5.conf. Please note that you have to say 'enable_only = > >>> sssd, k5login' is you want to use .k5login files as well. > >>> > >>> If authentication and user mapping is done and was successful sshd > >>> will do the PAM based access control with the help of SSSD. > >>> > >>> bye, > >>> Sumit > >>> > >>>> Best, > >>>> Longina > >>>> > >>>>> -----Oprindelig meddelelse----- > >>>>> Fra: sssd-users-boun...@lists.fedorahosted.org [mailto:sssd-users- > >>>>> boun...@lists.fedorahosted.org] På vegne af Sumit Bose > >>>>> Sendt: 10. juli 2015 10:22 > >>>>> Til: End-user discussions about the System Security Services > >>>>> Daemon > >>>>> Emne: Re: [SSSD-users] ssh passwordless with sssd-1.12.5 > >>>>> > >>>>> On Thu, Jul 09, 2015 at 04:06:05PM +0000, Longina Przybyszewska > >> wrote: > >>>>>> Hi, > >>>>>> I have SSSD setup with AD as auth/id provider in multi domain > >>>>>> trust realm, > >>>>> and POSIX attributes in AD for users. > >>>>>> With this setup users can use short names (short names match > >>>>> sSAMaccount name in AD user object)) for login and get access to > >>>>>> their homedir ,NFS mounted with Kerberos security. > >>>>>> The "short user names" are unique across domains in realm. > >>>>>> > >>>>>> Setup works fine, even after recently made possible sssd upgrade > >>>>>> to 1.12.5 > >>>>> (all Linux clients run Ubuntu LTS). > >>>>>> We would like to establish passwordless ssh between all > >>>>>> AD-integrated > >>>>> clients - and have problems. > >>>>>> The important detail is, that all machines are in one domain, > >>>>>> while > >>> users > >>>>> can be from other domains inclusive, machine's domain . > >>>>>> Until now, passwordless ssh is possible when user and machine are > >>>>>> from > >>>>> the same domain . > >>>>>> Users from domains other than machines's own domain , are asked > >>>>>> for > >>>>> passwd. > >>>>>> All tickets for host and nfs service in user's cache seems to be ok. > >>>>>> > >>>>>> After debugging ssh/sshd session it seems that connection ssh< - > >>>>>> -> sshd > >>>>> fails on user authorization. > >>>>>> Any ideas? > >>>>>> > >>>>>> > >>>>>> Ssh client side debug: > >>>>>> ---------------------------------- > >>>>>> [9537] 1436450526.619393: Got service principal > >>>>>> host/lnx.a.c.realm@A.C.REALM [9537] 1436450526.621139: ccselect > >>>>>> can't find appropriate cache for server principal > >>>>>> host/lnx.a.c.realm@A.C.REALM [9537] 1436450526.621254: Getting > >>>>>> credentials longina@N.C.REALM -> host/lnx.a.c.realm@A.C.REALM > >>>>>> using ccache FILE:/tmp/krb5cc_XXXXX_CN76dg [9537] > >>> 1436450526.621355: > >>>>>> Retrieving longina@N.C.REALM -> host/lnx.a.c.realm@A.C.REALM > from > >>>>>> FILE:/tmp/krb5cc_XXXXX_CN76dg with result: 0/Success [9537] > >>>>>> 1436450526.621490: Creating authenticator for longina@N.C.REALM > >>>>>> -> host/lnx.a.c.realm@A.C.REALM, seqnum 1059254370, subkey > >>>>>> aes256-cts/4255, session key aes256-cts/2F16 > >>>>>> debug2: we sent a gssapi-with-mic packet, wait for reply > >>>>>> debug1: Authentications that can continue: > >>>>>> publickey,gssapi-keyex,gssapi-with-mic,password > >>>>>> [9537] 1436450526.623050: Convert service host (service with host > >>>>>> as > >>>>>> instance) on host lnx.a.c.realmto principal [9537] 1436450526.624716: > >>>>>> Remote host after forward canonicalization: lnx.a.c.realm [9537] > >>>>>> 1436450526.624760: Remote host after reverse DNS processing: > >>>>>> lnx.a.c.realm [9537] 1436450526.624793: Got service principal > >>>>>> host/lnx.a.c.realm@A.C.REALM [9537] 1436450526.626601: ccselect > >>>>>> can't find appropriate cache for server principal > >>>>>> host/lnx.a.c.realm@A.C.REALM [9537] 1436450526.626719: Getting > >>>>>> credentials longina@N.C.REALM -> host/lnx.a.c.realm@A.C.REALM > >>>>>> using ccache FILE:/tmp/krb5cc_XXXXX_CN76dg [9537] > >>> 1436450526.626821: > >>>>>> Retrieving longina@N.C.REALM -> host/lnx.a.c.realm@A.C.REALM > from > >>>>>> FILE:/tmp/krb5cc_XXXXX_CN76dg with result: 0/Success [9537] > >>>>>> 1436450526.626984: Getting credentials longina@N.C.REALM -> > >>>>>> host/lnx.a.c.realm@A.C.REALM using ccache > >>>>>> FILE:/tmp/krb5cc_XXXXX_CN76dg [9537] 1436450526.627067: > >>>>>> Retrieving longina@N.C.REALM -> host/lnx.a.c.realm@A.C.REALM > from > >>>>>> FILE:/tmp/krb5cc_XXXXX_CN76dg with result: 0/Success [9537] > >>>>>> 1436450526.627162: Creating authenticator for longina@N.C.REALM > >>>>>> -> host/lnx.a.c.realm@A.C.REALM, seqnum 778106202, subkey > >>>>>> aes256-cts/CBE6, session key aes256-cts/2F16 > >>>>>> debug2: we sent a gssapi-with-mic packet, wait for reply > >>>>>> debug1: Authentications that can continue: > >>>>>> publickey,gssapi-keyex,gssapi-with-mic,password > >>>>>> debug2: we did not send a packet, disable method > >>>>>> debug3: authmethod_lookup publickey > >>>>>> > >>>>>> > >>>>>> sshd server side debug: > >>>>>> ------------------------------------ > >>>>>> .... > >>>>>> debug2: input_userauth_request: setting up authctxt for longina > >>>>>> [preauth] > >>>>>> debug3: mm_start_pam entering [preauth] > >>>>>> debug3: mm_request_send entering: type 100 [preauth] > >>>>>> debug3: mm_inform_authserv entering [preauth] > >>>>>> debug3: mm_request_send entering: type 4 [preauth] > >>>>>> debug2: input_userauth_request: try method none [preauth] > >>>>>> debug3: userauth_finish: failure partial=0 next > >>>>>> methods="publickey,gssapi-keyex,gssapi-with-mic,password" > >>>>>> [preauth] > >>>>>> debug3: mm_request_receive entering > >>>>>> debug3: monitor_read: checking request 100 > >>>>>> debug1: PAM: initializing for "longina" > >>>>>> debug1: PAM: setting PAM_RHOST to "10.80.8.108" > >>>>>> debug1: PAM: setting PAM_TTY to "ssh" > >>>>>> debug2: monitor_read: 100 used once, disabling now > >>>>>> debug3: mm_request_receive entering > >>>>>> debug3: monitor_read: checking request 4 > >>>>>> debug3: mm_answer_authserv: service=ssh-connection, style=, > role= > >>>>>> debug2: monitor_read: 4 used once, disabling now > >>>>>> debug1: userauth-request for user longina service ssh-connection > >>>>>> method gssapi-with-mic [preauth] > >>>>>> debug1: attempt 1 failures 0 [preauth] > >>>>>> debug2: input_userauth_request: try method gssapi-with-mic > >>>>>> [preauth] > >>>>>> debug3: mm_request_send entering: type 42 [preauth] > >>>>>> debug3: mm_request_receive_expect entering: type 43 [preauth] > >>>>>> debug3: mm_request_receive entering [preauth] > >>>>>> debug3: mm_request_receive entering > >>>>>> debug3: monitor_read: checking request 42 > >>>>>> debug3: mm_request_send entering: type 43 Postponed > >>>>>> gssapi-with-mic for longina from 10.80.8.108 port 53479 ssh2 > >>>>>> [preauth] > >>>>>> debug3: mm_request_send entering: type 44 [preauth] > >>>>>> debug3: mm_request_receive_expect entering: type 45 [preauth] > >>>>>> debug3: mm_request_send entering: type 47 Failed gssapi-with-mic > >>>>>> for longina from 10.80.8.108 port 53479 ssh2 > >>>>>> debug3: mm_ssh_gssapi_userok: user not authenticated [preauth] > >>>>> Chances are that mapping the Kerberos principal to the local user > >>>>> name > >>> fails. > >>>>> Since the Kerberos ticket only contains the Kerberos principal and > >>>>> it is not desirable that any user with a valid Kerberos ticket can > >>>>> log in as any local user the Kerberos client library has to do > >>>>> some mapping between the Kerberos principal and the local user > >> name. > >>>>> There are various mapping schemes available. For testing > >>>>> (especially since I'm not too familiar with Kerberos on Ubuntu) I > >>>>> would recommend to create a .k5login file in the home directory of > >>>>> the user you want to log in as. The .k5login file should contain > >>>>> the Kerberos principal which should be allowed to log in as this > >>>>> user, e.g. longina@N.C.REALM in your case (please note that > >>>>> Kerberos is case-sensitive). Please check permissions on .k5login > >>>>> as well, only the > >>> user itself should be able to access it. > >>>>> If this works but you don't want to add a .k5login file for every > >>>>> user please tell me which Kerberos version is used on your Ubuntu > >>>>> system to see which other schemes are available. > >>>>> > >>>>> HTH > >>>>> > >>>>> bye, > >>>>> Sumit > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> sssd-users mailing list > >>>> sssd-users@lists.fedorahosted.org > >>>> https://lists.fedorahosted.org/mailman/listinfo/sssd-users > >>> _______________________________________________ > >>> sssd-users mailing list > >>> sssd-users@lists.fedorahosted.org > >>> https://lists.fedorahosted.org/mailman/listinfo/sssd-users > >> _______________________________________________ > >> sssd-users mailing list > >> sssd-users@lists.fedorahosted.org > >> https://lists.fedorahosted.org/mailman/listinfo/sssd-users > > _______________________________________________ > > sssd-users mailing list > > sssd-users@lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/sssd-users > > > -- > Thank you, > Dmitri Pal > > Engineering Director, Identity Management and Platform Security Red Hat, > Inc. > > _______________________________________________ > sssd-users mailing list > sssd-users@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
