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.
In what way? It is supported in RHEL 7.0 and after so I am not sure why
you treat it as adventurous.
It is pretty much same bits upstream and downstream
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-bounces(a)lists.fedorahosted.org [mailto:sssd-users-
> bounces(a)lists.fedorahosted.org] På vegne af Dmitri Pal
> Sendt: 30. juli 2015 16:07
> Til: sssd-users(a)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)A.C.REALM:
>> aes256-cts/0F5A [6404] 1438257362.977427: AP-REQ ticket:
>> LNX-LEIA$(a)A.C.REALM -> nfs/nfssrv.adm.c.sdu.dk(a)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)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-bounces(a)lists.fedorahosted.org [mailto:sssd-users-
>>> bounces(a)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)A.C.REALM: aes256-cts/2CCB [2863] 1436879405.741095: AP-REQ
>>> ticket: longina(a)N.C.REALM-> LX101$(a)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(a)N.C.REALM [2863]
>>> 1436879405.799504: Removing longina(a)N.C.REALM->
>>> krbtgt/N.C.REALM(a)N.C.REALM from MEMORY:pvs4jFN [2863]
>>> 1436879405.799514: Storing longina(a)N.C.REALM->
>>> krbtgt/N.C.REALM(a)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)A.C.REALM: aes256-cts/2CCB [3534] 1436884067.287447: AP-REQ
>>> ticket: longina(a)N.C.REALM -> lx101$(a)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(a)N.C.REALM [3534]
>>> 1436884067.359035: Removing longina(a)N.C.REALM ->
>>> krbtgt/N.C.REALM(a)N.C.REALM from MEMORY:pJb8FBS [3534]
>>> 1436884067.359045: Storing longina(a)N.C.REALM ->
>>> krbtgt/N.C.REALM(a)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(a)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-bounces(a)lists.fedorahosted.org [mailto:sssd-users-
>>>> bounces(a)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(a)N.C.REALM.
>>>>> Trying SSH - Service tickets nfs/fqdn(a)A.C.REALM and
>>>> host/fqdn(a)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-bounces(a)lists.fedorahosted.org
[mailto:sssd-users-
>>>>>> bounces(a)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)A.C.REALM [9537] 1436450526.621139:
ccselect
>>>>>>> can't find appropriate cache for server principal
>>>>>>> host/lnx.a.c.realm(a)A.C.REALM [9537] 1436450526.621254:
Getting
>>>>>>> credentials longina(a)N.C.REALM ->
host/lnx.a.c.realm(a)A.C.REALM
>>>>>>> using ccache FILE:/tmp/krb5cc_XXXXX_CN76dg [9537]
>>>> 1436450526.621355:
>>>>>>> Retrieving longina(a)N.C.REALM ->
host/lnx.a.c.realm(a)A.C.REALM
> from
>>>>>>> FILE:/tmp/krb5cc_XXXXX_CN76dg with result: 0/Success [9537]
>>>>>>> 1436450526.621490: Creating authenticator for
longina(a)N.C.REALM
>>>>>>> -> host/lnx.a.c.realm(a)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)A.C.REALM [9537] 1436450526.626601:
ccselect
>>>>>>> can't find appropriate cache for server principal
>>>>>>> host/lnx.a.c.realm(a)A.C.REALM [9537] 1436450526.626719:
Getting
>>>>>>> credentials longina(a)N.C.REALM ->
host/lnx.a.c.realm(a)A.C.REALM
>>>>>>> using ccache FILE:/tmp/krb5cc_XXXXX_CN76dg [9537]
>>>> 1436450526.626821:
>>>>>>> Retrieving longina(a)N.C.REALM ->
host/lnx.a.c.realm(a)A.C.REALM
> from
>>>>>>> FILE:/tmp/krb5cc_XXXXX_CN76dg with result: 0/Success [9537]
>>>>>>> 1436450526.626984: Getting credentials longina(a)N.C.REALM
->
>>>>>>> host/lnx.a.c.realm(a)A.C.REALM using ccache
>>>>>>> FILE:/tmp/krb5cc_XXXXX_CN76dg [9537] 1436450526.627067:
>>>>>>> Retrieving longina(a)N.C.REALM ->
host/lnx.a.c.realm(a)A.C.REALM
> from
>>>>>>> FILE:/tmp/krb5cc_XXXXX_CN76dg with result: 0/Success [9537]
>>>>>>> 1436450526.627162: Creating authenticator for
longina(a)N.C.REALM
>>>>>>> -> host/lnx.a.c.realm(a)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(a)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(a)lists.fedorahosted.org
>>>>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>>>> _______________________________________________
>>>> sssd-users mailing list
>>>> sssd-users(a)lists.fedorahosted.org
>>>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>>> _______________________________________________
>>> sssd-users mailing list
>>> sssd-users(a)lists.fedorahosted.org
>>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>> _______________________________________________
>> sssd-users mailing list
>> sssd-users(a)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(a)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.