My question was more - if you have PAM and GSSAPI both enables, will the ssh client still go through the PAM stack (for authorization purposes).
MAT MAT ----- Original Message ----- From: Chris Hoy Poy <[email protected]> To: Rowley, Mathew Cc: [email protected] <[email protected]> Sent: Tue Dec 16 08:57:48 2008 Subject: Re: Kerberos auth based on ticket PAM doesnt come into a GSSAPI passthru, so you just turn on the GSSAPI options in OpenSSH to let them happen. Turn off the openSSH kerberos options (if you want PAM to do the Kerberos ticket requesting) - but turn on the GSSAPI options as OpenSSH needs to handle them if you want to allow forwarded tickets / kerberos-authenticated connections). This (I think) means you can have a box that is only accessible if you've already got a ticket? Never tried it. :P //Chris Hoy Poy Senior Infrastructure Engineer GoPC Pty Ltd http://www.gopc.net ----- Original Message ----- From: "Mathew Rowley" <[email protected]> To: [email protected] Cc: [email protected] Sent: Tuesday, 16 December, 2008 10:37:29 PM GMT +08:00 Perth Subject: Re: Kerberos auth based on ticket If you have a kerberos ticket, and ssh to a box that has GSSAPI enabled, will that pass through/disregard the PAM stack? MAT MAT ----- Original Message ----- From: Chris Hoy Poy <[email protected]> To: Rowley, Mathew Cc: [email protected] <[email protected]> Sent: Tue Dec 16 07:19:41 2008 Subject: Re: Kerberos auth based on ticket Hi Matt, ( FYI I used the O'Reilly Kerberos book by Jason Garmon to get my head straight. Lots of little issues like this until you've done it a few times.. ) yes, you need to: If you are using DNS for resolution, make sure your forward and reverse names match as well. -> add a host principle for the server (to the KDC) ( process differs slightly for heimdal and MIT) ( host/`hostname` ) (use a "host/" prefix to define it as a host - not sure if that is just a practice or if thats important. Good practice at the very least I think?) -> export the keytab for the server (to go into /etc/krb5.keytab on the OpenSSH box) (thats got the password to let the SSH server authenticate itself, and perform ticket checks - with Kerberos, the server/service has to participate with the KDC to see if you are really are who you say you are). Again, process differs slightly for MIT vs. Heimdal. I had some issues with some encryptions not being supported by some SSH/GSSAPI clients. you might need to "trim" some of the available keys if it doesn't work. YMMV. //Chris Hoy Poy Senior Infrastructure Engineer GoPC Pty Ltd http://www.gopc.net ----- Original Message ----- From: "Mathew Rowley" <[email protected]> To: "Chris Hoy Poy" <[email protected]> Cc: [email protected] Sent: Tuesday, 16 December, 2008 8:48:31 PM GMT +08:00 Perth Subject: Re: Kerberos auth based on ticket [mrow...@ipa01 ~]$ ssh -v mrow...@`hostname` OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to ipa01.security.lab.comcast.com [10.252.152.73] port 22. debug1: Connection established. debug1: identity file /home/mrowley/.ssh/identity type -1 debug1: identity file /home/mrowley/.ssh/id_rsa type -1 debug1: identity file /home/mrowley/.ssh/id_dsa type -1 debug1: loaded 3 keys debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'ipa01.security.lab.comcast.com' is known and matches the RSA host key. debug1: Found key in /home/mrowley/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Server not found in Kerberos database debug1: Unspecified GSS failure. Minor code may provide more information Server not found in Kerberos database debug1: Unspecified GSS failure. Minor code may provide more information Server not found in Kerberos database debug1: Next authentication method: publickey debug1: Trying private key: /home/mrowley/.ssh/identity debug1: Trying private key: /home/mrowley/.ssh/id_rsa debug1: Trying private key: /home/mrowley/.ssh/id_dsa debug1: Next authentication method: password [email protected]'s password: Looks like my problem is ‘Server not found in Kerberos database’. So I am assuming that I need the server in the kerberos database as well as the user... Is that done just like adding a principal? Sorry, very new to this. MAT On 12/15/08 6:09 PM, "Chris Hoy Poy" <[email protected]> wrote: > What does "ssh -v usern...@`hostname`"provide? and is hostname the same as the > host principle you set up? SSH -v will tell which ones its trying at least. > > //chris > > ----- Original Message ----- > From: "Mathew Rowley" <[email protected]> > To: "Russ Allbery" <[email protected]> > Cc: [email protected] > Sent: Tuesday, 16 December, 2008 9:55:51 AM GMT +08:00 Beijing / Chongqing / > Hong Kong / Urumqi > Subject: Re: Kerberos auth based on ticket > > Ok, using the correct hostname, the same thing happens: > > [r...@ipa01 ~]# ssh mrow...@`hostname` > [email protected]'s password: > Last login: Mon Dec 15 18:42:09 2008 from localhost.localdomain > > **Trying to log in with a valid ticket, but asks for password > [mrow...@ipa01 ~]$ ssh mrow...@`hostname` > [email protected]'s password: > > **Shows that there is a ticket > [mrow...@ipa01 ~]$ klist > Ticket cache: FILE:/tmp/krb5cc_502_WaiNgJ > Default principal: [email protected] > > Valid starting Expires Service principal > 12/15/08 19:52:10 12/16/08 05:52:10 krbtgt/[email protected] > renew until 12/15/08 19:52:10 > > > Kerberos 4 ticket cache: /tmp/tkt502 > klist: You have no tickets cached > > **Showing the kerberos realm is the same as the ssh¹ed hostname > [mrow...@ipa01 ~]$ cat /etc/krb5.conf > ... > [realms] > IPA.COMCAST.COM = { > kdc = ipa01.security.lab.comcast.com:88 > admin_server = ipa01.security.lab.comcast.com:749 > default_domain = security.lab.comcast.com > database_module = openldap_ldapconf > } > ... > > > MAT > > > > On 12/15/08 5:01 PM, "Russ Allbery" <[email protected]> wrote: > >> > Mathew Rowley <[email protected]> writes: >> > >>>> >> > Well, that would make sense... Looking at the sshd and ssh >>>> configurations, >>>> >> > it seems to be enabled on both. Is there some configuration I am >>>> missing? >>>> >> > >>>> >> > [r...@ipa01 ~]# grep -i GSSAPI /etc/ssh/ssh_config >>>> >> > GSSAPIAuthentication yes >>>> >> > [r...@ipa01 ~]# grep -i GSSAPI /etc/ssh/sshd_config >>>> >> > # GSSAPI options >>>> >> > GSSAPIAuthentication yes >>>> >> > GSSAPICleanupCredentials yes >> > >> > Your original pasted example showed you ssh'ing to u...@localhost. Unless >> > you have a key for localhost in your keytab, that probably isn't going to >> > work. ssh authenticates to the hostname that you type on the command >> > line. >> > >> > -- >> > Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> >> > > > -- > MAT > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
