And yes, i also need to include -s ipaserver in the get-ipakeytab command, otherwise it kept giving wrong usage error....
On Fri, Feb 26, 2016 at 10:29 PM, Teik Hooi Beh <[email protected]> wrote: > Thanks. It's working now using ipa-getkeytab. > > Correct me if I am wrong (as I am new to freeipa), using ktutil I could > add multiple user in a keytab file (correct???) but in this case using > ipa-getkeytab can I do the same? > > On Fri, Feb 26, 2016 at 9:15 PM, David Kupka <[email protected]> wrote: > >> On 26/02/16 08:56, David Kupka wrote: >> >>> On 26/02/16 02:22, Teik Hooi Beh wrote: >>> >>>> Hi, >>>> >>>> I have manged to deployed 1 ipa master and 1 ipa client with success on >>>> centos 7.2 with freeipa v4.2. I also managed to create user and set >>>> sshd-rules to for ttester user and also successfully get krb ticket >>>> using *kinit >>>> [email protected]*. I am trying to deploy password-less SSH login with >>>> kerberos using the following guide ( >>>> >>>> https://uz.sns.it/~enrico/wordpress/2014/03/password-less-ssh-login-with-kerberos/ >>>> ) >>>> >>>> - >>>> >>>> snippet - >>>> >>>> >>>> >>>> *$ ktutil ktutil: add_entry -password -p [email protected] -k 1 -e >>>> aes256-cts-hmac-sha1-96 ktutil: write_kt keytab* >>>> >>>> When I tried *kinit -kt keytab [email protected]*, I get *"**kinit: >>>> Password incorrect while getting initial credentials"* >>>> Doing a trace using KRB5_TRACE on both calls >>>> >>>> *1. KRB5_TRACE=/dev/stderr kinit [email protected]* >>>> 27242] 1456447025.219676: Getting initial credentials for >>>> [email protected] >>>> [27242] 1456447025.222070: Sending request (164 bytes) to EXAMPLE.MY >>>> [27242] 1456447025.222223: Resolving hostname node1.example.my >>>> [27242] 1456447035.238004: Initiating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27242] 1456447035.238675: Sending TCP request to stream >>>> 192.168.38.2:88 >>>> [27242] 1456447035.241248: Received answer (337 bytes) from stream >>>> 192.168.38.2:88 >>>> [27242] 1456447035.241257: Terminating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27242] 1456447035.241377: Response was from master KDC >>>> [27242] 1456447035.241437: Received error from KDC: >>>> -1765328359/Additional >>>> pre-authentication required >>>> [27242] 1456447035.241484: Processing preauth types: 136, 19, 2, 133 >>>> [27242] 1456447035.241499: Selected etype info: etype aes256-cts, salt >>>> "s`GD^,#=cA:Vr9hD", params "" >>>> [27242] 1456447035.241504: Received cookie: MIT >>>> Password for [email protected]: >>>> [27242] 1456447062.215750: AS key obtained for encrypted timestamp: >>>> aes256-cts/73C6 >>>> [27242] 1456447062.215815: Encrypted timestamp (for 1456447062.215315): >>>> plain 301AA011180F32303136303232363030333734325AA1050203034913, >>>> encrypted >>>> >>>> F9A2E97E916FC14D141690E151A25DCC00168361179C7F0ACDA94C7F58F3D50429780A5608A6B8623E355F2A5BD676F6FA5272D38FD05C8B >>>> >>>> [27242] 1456447062.215942: Preauth module encrypted_timestamp (2) (real) >>>> returned: 0/Success >>>> [27242] 1456447062.215948: Produced preauth for next request: 133, 2 >>>> [27242] 1456447062.215965: Sending request (257 bytes) to EXAMPLE.MY >>>> [27242] 1456447062.216010: Resolving hostname node1.example.my >>>> [27242] 1456447072.229254: Initiating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27242] 1456447072.229655: Sending TCP request to stream >>>> 192.168.38.2:88 >>>> [27242] 1456447072.236955: Received answer (722 bytes) from stream >>>> 192.168.38.2:88 >>>> [27242] 1456447072.236974: Terminating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27242] 1456447072.237080: Response was from master KDC >>>> [27242] 1456447072.237117: Processing preauth types: 19 >>>> [27242] 1456447072.237125: Selected etype info: etype aes256-cts, salt >>>> "s`GD^,#=cA:Vr9hD", params "" >>>> [27242] 1456447072.237131: Produced preauth for next request: (empty) >>>> [27242] 1456447072.237140: AS key determined by preauth: aes256-cts/73C6 >>>> [27242] 1456447072.237199: Decrypted AS reply; session key is: >>>> aes256-cts/2A71 >>>> [27242] 1456447072.237216: FAST negotiation: available >>>> [27242] 1456447072.237236: Initializing KEYRING:persistent:1000:1000 >>>> with >>>> default princ [email protected] >>>> [27242] 1456447072.237275: Storing [email protected] -> >>>> krbtgt/[email protected] in KEYRING:persistent:1000:1000 >>>> [27242] 1456447072.237330: Storing config in >>>> KEYRING:persistent:1000:1000 >>>> for krbtgt/[email protected]: fast_avail: yes >>>> [27242] 1456447072.237345: Storing [email protected] -> >>>> >>>> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY@X-CACHECONF >>>> : >>>> >>>> in KEYRING:persistent:1000:1000 >>>> [27242] 1456447072.237371: Storing config in >>>> KEYRING:persistent:1000:1000 >>>> for krbtgt/[email protected]: pa_type: 2 >>>> [27242] 1456447072.237380: Storing [email protected] -> >>>> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY@X-CACHECONF >>>> : >>>> in KEYRING:persistent:1000:1000 >>>> >>>> *2. KRB5_TRACE=/dev/stderr kinit -kt keytab [email protected]* >>>> [27248] 1456447236.144685: Getting initial credentials for >>>> [email protected] >>>> [27248] 1456447236.147107: Looked up etypes in keytab: aes256-cts >>>> [27248] 1456447236.147255: Sending request (164 bytes) to EXAMPLE.MY >>>> [27248] 1456447236.147381: Resolving hostname node1.example.my >>>> [27248] 1456447246.161528: Initiating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27248] 1456447246.161970: Sending TCP request to stream >>>> 192.168.38.2:88 >>>> [27248] 1456447246.164772: Received answer (337 bytes) from stream >>>> 192.168.38.2:88 >>>> [27248] 1456447246.164791: Terminating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27248] 1456447246.164904: Response was from master KDC >>>> [27248] 1456447246.164943: Received error from KDC: >>>> -1765328359/Additional >>>> pre-authentication required >>>> [27248] 1456447246.164987: Processing preauth types: 136, 19, 2, 133 >>>> [27248] 1456447246.164997: Selected etype info: etype aes256-cts, salt >>>> "s`GD^,#=cA:Vr9hD", params "" >>>> [27248] 1456447246.165001: Received cookie: MIT >>>> [27248] 1456447246.165142: Retrieving [email protected] from >>>> FILE:keytab >>>> (vno 0, enctype aes256-cts) with result: 0/Success >>>> [27248] 1456447246.165166: AS key obtained for encrypted timestamp: >>>> aes256-cts/0A17 >>>> [27248] 1456447246.165210: Encrypted timestamp (for 1456447246.164647): >>>> plain 301AA011180F32303136303232363030343034365AA1050203028327, >>>> encrypted >>>> >>>> C092E6C29FC1CD794625CF12162D18767A68D1728E6C2ADC1F50492D6605E039B664213C29767715E04B3CA8D97EBD691BBF40B76370C9FA >>>> >>>> [27248] 1456447246.165224: Preauth module encrypted_timestamp (2) (real) >>>> returned: 0/Success >>>> [27248] 1456447246.165228: Produced preauth for next request: 133, 2 >>>> [27248] 1456447246.165239: Sending request (257 bytes) to EXAMPLE.MY >>>> [27248] 1456447246.165253: Resolving hostname node1.example.my >>>> [27248] 1456447256.178637: Initiating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27248] 1456447256.179456: Sending TCP request to stream >>>> 192.168.38.2:88 >>>> [27248] 1456447256.184929: Received answer (167 bytes) from stream >>>> 192.168.38.2:88 >>>> [27248] 1456447256.184941: Terminating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27248] 1456447256.185043: Response was from master KDC >>>> [27248] 1456447256.185065: Received error from KDC: -1765328353/Decrypt >>>> integrity check failed >>>> kinit: Password incorrect while getting initial credentials >>>> >>>> From the 2 trace I notice the return bytes on return from calling using >>>>> >>>> keytab is only 167 bytes compare to 722 bytes. Does anybody know the >>>> reasons or could point me to where I could debug further? >>>> >>>> Thanks >>>> >>>> >>>> >>>> >>> Hello! >>> >>> I don't know why it does not work with ktutil but I've find other way >>> how to get keytab for a user: >>> >>> $ kinit ttester >>> $ ipa-getkeytab -p [email protected] -k ttester.keytab -e >>> aes256-cts-hmac-sha1-96 >>> $ kdestroy ttester >>> $ kinit [email protected] -kt ttester.keytab >>> >>> HTH, >>> >>> >> Oh, I forget to mention that this also sets random krbPrincipalKey for >> the user so you can kinit only with the keytab. ipa-getkeytab has also >> option -r (--retrive) that should not change krbPrincipalKey but for some >> reason user is not allowed to retrieve it. >> You can of course add ACI to allow that but I would not do it because >> there's probably good reason why it's forbidden by default. >> >> -- >> David Kupka >> > >
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
