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
-----Oprindelig meddelelse----- Fra: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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
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-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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
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@lists.fedorahosted.org [mailto:sssd-users- bounces@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-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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
On Thu, Jul 30, 2015 at 02:38:11PM +0000, Longina Przybyszewska wrote:
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
Both are pretty stable, but out of these two I would recommend 1.12.5
Actually I really don't know what is getting wrong.
best Longina
Our users would have following features with the SSSD setup (moving from NIS to AD-integrated desktops with sssd): -homedir kerberized NFS4 share -passwdless ssh between ad-integrated machines On the AD side we got POSIX attributes for users and several POSIX groups ; we use GC .
I am not sure if my assumption is right that localauth plugin=sssd_krb5_localauth_plugin.so in krb5.conf triggers krb nfs-mount problem.
WE would like to login as AD principals =sSAMAccount names - also, short names system wide (we can do because all name are unique across trusty cross realm); May be our setup is very specific, as we started to build it with much earlier versions of sssd,, and does not play well into 1.12.5 version?
In our case UPN names name@realm are different from name@fqdn; Is there simple way to get authentication via 'name' in 1.12.5? (our names (=sSAMAccount name) are unique across multi domain realm. Should we stick to UPN names to avoid troubles?
UPN longina@realm I am member of N.C.REALM domain - my Kerberos principal ticket is for longina@N.C.REALM I would like to login as 'longina' ; eventually as 'longina@realm'
Best, Longina
-----Oprindelig meddelelse----- Fra: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@lists.fedorahosted.org] På vegne af Jakub Hrozek Sendt: 30. juli 2015 16:44 Til: sssd-users@lists.fedorahosted.org Emne: Re: [SSSD-users] ssh passwordless with sssd-1.12.5 problem!!
On Thu, Jul 30, 2015 at 02:38:11PM +0000, Longina Przybyszewska wrote:
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
Both are pretty stable, but out of these two I would recommend 1.12.5
Actually I really don't know what is getting wrong.
best Longina
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 07/30/2015 10:38 AM, Longina Przybyszewska wrote:
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@lists.fedorahosted.org [mailto:sssd-users- bounces@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-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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-bounces@lists.fedorahosted.org [mailto:sssd-users- > bounces@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@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Longina Przybyszewska