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-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