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 ouruser(a)OURDOMAIN.EDU <mailto:ouruser@OURDOMAIN.EDU>
3. I could then run ssh -k ouruser(a)ourdomain.edu
<mailto:ouruser@ourdomain.edu> 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 student123(a)univ.edu 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 <rkudyba(a)fordham.edu
<mailto:rkudyba@fordham.edu>> 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/ourdomain.edu(a)OURDOMAIN.EDU
<mailto:ourdomain.edu@OURDOMAIN.EDU>
2 host/ourdomain.edu(a)OURDOMAIN.EDU
<mailto:ourdomain.edu@OURDOMAIN.EDU>
2 host/ourdomain.edu(a)OURDOMAIN.EDU
<mailto:ourdomain.edu@OURDOMAIN.EDU>
2 host/ourdomain.edu(a)OURDOMAIN.EDU
<mailto:ourdomain.edu@OURDOMAIN.EDU>
2 host/ourdomain.edu(a)OURDOMAIN.EDU
<mailto:ourdomain.edu@OURDOMAIN.EDU>
2 host/ourdomain.edu(a)OURDOMAIN.EDU
<mailto:ourdomain.edu@OURDOMAIN.EDU>
4 host/ourclient.edu(a)OURCLIENT.EDU
<mailto:ourclient.edu@OURCLIENT.EDU>
4 host/ourclient.edu(a)OURCLIENT.EDU
<mailto:ourclient.edu@OURCLIENT.EDU>
5 host/ourclient.edu(a)OURCLIENT.EDU
<mailto:ourclient.edu@OURCLIENT.EDU>
5 host/ourclient.edu(a)OURCLIENT.EDU
<mailto:ourclient.edu@OURCLIENT.EDU>
6 host/ourclient.edu(a)OURCLIENT.EDU
<mailto:ourclient.edu@OURCLIENT.EDU>
6 host/ourclient.edu(a)OURCLIENT.EDU
<mailto:ourclient.edu@OURCLIENT.EDU>
7 host/ourclient.edu(a)OURCLIENT.EDU
<mailto:ourclient.edu@OURCLIENT.EDU>
7 host/ourclient.edu(a)OURCLIENT.EDU
<mailto:ourclient.edu@OURCLIENT.EDU>
On Thu, Mar 11, 2021 at 3:47 PM Robert Kudyba <rkudyba(a)fordham.edu
<mailto:rkudyba@fordham.edu>> 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.fedoraproj...
> (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 edu(a)OURDOMAIN.EDU
<mailto:edu@OURDOMAIN.EDU> for
DNS/ds-dc31.ds.ourdomain.edu(a)OURDOMAIN.EDU
<mailto:ds-dc31.ds.ourdomain.edu@OURDOMAIN.EDU>, 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?