Robert Kudyba wrote: > I'd like to provide an update. I can get ssh -k to work but here's what > I had to do: > 1. I had to run ipa-client-install on another server/computer > 2. I ran kinit [email protected] <mailto:[email protected]> > 3. I could then run ssh -k [email protected] > <mailto:[email protected]> and automatically logged in without > needing to enter a password. > > My question is, how does this scale to users, i.e., in our case, > students, who are all over the world using their own laptops? Does every > user client, i.e., computer, need to run ipa-client-install? Am I > missing something?
It depends on what the expectations are for these user-owned machines. If you don't need IPA identities and IPA users won't log into them, then they only need a working krb5.conf and DNS configured on them. So your students would log into their own controlled machine using their own local account, kinit [email protected] and ssh using their credentials. The krb5.conf will tell the student machine how to contact the KDC. That's all that is necessary (beyond working DNS). rob > > On Thu, Mar 11, 2021 at 5:43 PM Robert Kudyba <[email protected] > <mailto:[email protected]>> wrote: > > Still seeing: > preauth (spake) verify failure: Preauthentication failed > > kvno ldap/ourdomain > kvno = 2 > kvno http/ourdomain > kvno = 1 > > klist -k > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 2 host/[email protected] > <mailto:[email protected]> > 2 host/[email protected] > <mailto:[email protected]> > 2 host/[email protected] > <mailto:[email protected]> > 2 host/[email protected] > <mailto:[email protected]> > 2 host/[email protected] > <mailto:[email protected]> > 2 host/[email protected] > <mailto:[email protected]> > 4 host/[email protected] > <mailto:[email protected]> > 4 host/[email protected] > <mailto:[email protected]> > 5 host/[email protected] > <mailto:[email protected]> > 5 host/[email protected] > <mailto:[email protected]> > 6 host/[email protected] > <mailto:[email protected]> > 6 host/[email protected] > <mailto:[email protected]> > 7 host/[email protected] > <mailto:[email protected]> > 7 host/[email protected] > <mailto:[email protected]> > > > On Thu, Mar 11, 2021 at 3:47 PM Robert Kudyba <[email protected] > <mailto:[email protected]>> wrote: > > > > Keytab successfully retrieved and stored in: > /tmp/client.keytab > > > > This is why SSSD isn't working. SSSD uses the host > keytab in > > /etc/krb5.keytab and you invalidated it with the above > command. > > > > > > OK what do I need to do to fix this? I got this > > > from > https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_en-2DUS_Fedora_18_html_FreeIPA-5FGuide_Installing-5Fthe-5FIPA-5FClient-5Fon-5FLinux.html&d=DwIDaQ&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=DPUtTQx5TfzHXpznmDzOwRF-DMQCNuyTEyFZjQRbf24&s=_71xAKn9TgPKxsbm1Ei0b4VaeazS0Ax__ECpurXTUd0&e= > > > (which I realize is old), > > Please do not use these documents. We'd remove them if it > were in our > control. > > > Understood. > > > You can re-run your getkeytab command using /etc/krb5.keytab > instead to > sync up the keys. > > > OK I ran: > > ipa-getkeytab -s ourdomain.edu <http://ourdomain.edu> -p > host/client.ourdomain.edu <http://client.ourdomain.edu> -k > /etc/krb5.keytab > Keytab successfully retrieved and stored in: /etc/krb5.keytab > > Then I scp the keytab to the client /etc directory. Now in the > krb5.log I see: > > Mar 11 15:39:29 ourdomain.edu <http://ourdomain.edu> > krb5kdc[369141](info): TGS_REQ (6 etypes > {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), > camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), > aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) > 150.108.64.55 <http://150.108.64.55>: LOOKING_UP_SERVER: > authtime 0, etypes {rep=UNSUPPORTED:(0)} > host/client.ourdomain [email protected] > <mailto:[email protected]> for > DNS/[email protected] > <mailto:[email protected]>, Server not > found in Kerberos database > Mar 11 15:39:29 ourdomain.edu <http://ourdomain.edu> > krb5kdc[369141](info): closing down fd 11 > > ssh logs: > Mar 11 15:39:27 ourdomain sshd[375517]: debug1: userauth-request > for user ouruser service ssh-connection method > keyboard-interactive [preauth] > Mar 11 15:39:27 ourdomain sshd[375517]: debug1: attempt 2 > failures 1 [preauth] > Mar 11 15:39:27 ourdomain sshd[375517]: debug1: > keyboard-interactive devs [preauth] > Mar 11 15:39:27 ourdomain sshd[375517]: debug1: auth2_challenge: > user=ouruser devs= [preauth] > Mar 11 15:39:27 ourdomain sshd[375517]: debug1: kbdint_alloc: > devices 'pam' [preauth] > Mar 11 15:39:27 ourdomain sshd[375517]: debug1: > auth2_challenge_start: trying authentication method 'pam' [preauth] > Mar 11 15:39:27 ourdomain sshd[375517]: Postponed > keyboard-interactive for ouruser from x.x.x.x port 44136 ssh2 > [preauth] > Mar 11 15:39:30 ourdomain sshd[375524]: pam_unix(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=x.x.x.x user=ouruser > Mar 11 15:39:30 ourdomain sshd[375524]: pam_sss(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=x.x.x.x user=ouruser > Mar 11 15:39:30 ourdomain sshd[375524]: pam_sss(sshd:auth): > received for user ouruser: 9 (Authentication service cannot > retrieve authentication info) > > > > Does this have to do with your comment above about SSSD > not working? > > Yes. A keytab is a password and this is effectively a "bad > password" error. > > > Do I have to restart any services? > _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
