Kerberos auth based on ticket

Chris Hoy Poy kryanth at gopc.net
Tue Dec 16 08:57:48 EST 2008


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" <Mathew_Rowley at cable.comcast.com>
To: kryanth at gopc.net
Cc: kerberos at mit.edu
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 <kryanth at gopc.net>
To: Rowley, Mathew
Cc: kerberos at mit.edu <kerberos at mit.edu>
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" <mathew_rowley at cable.comcast.com>
To: "Chris Hoy Poy" <kryanth at gopc.net>
Cc: kerberos at mit.edu
Sent: Tuesday, 16 December, 2008 8:48:31 PM GMT +08:00 Perth
Subject: Re: Kerberos auth based on ticket

[mrowley at ipa01 ~]$ ssh -v mrowley@`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
mrowley at ipa01.security.lab.comcast.com'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" <kryanth at gopc.net> wrote:

> What does "ssh -v username@`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" <mathew_rowley at cable.comcast.com>
> To: "Russ Allbery" <rra at stanford.edu>
> Cc: kerberos at mit.edu
> 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:
> 
> [root at ipa01 ~]# ssh mrowley@`hostname`
> mrowley at ipa01.security.lab.comcast.com'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
> [mrowley at ipa01 ~]$ ssh mrowley@`hostname`
> mrowley at ipa01.security.lab.comcast.com's password:
> 
> **Shows that there is a ticket
> [mrowley at ipa01 ~]$ klist
> Ticket cache: FILE:/tmp/krb5cc_502_WaiNgJ
> Default principal: mrowley at IPA.COMCAST.COM
> 
> Valid starting     Expires            Service principal
> 12/15/08 19:52:10  12/16/08 05:52:10  krbtgt/IPA.COMCAST.COM at IPA.COMCAST.COM
>         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
> [mrowley at 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" <rra at stanford.edu> wrote:
> 
>> > Mathew Rowley <mathew_rowley at cable.comcast.com> 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?
>>>> >> >
>>>> >> > [root at ipa01 ~]# grep -i GSSAPI  /etc/ssh/ssh_config
>>>> >> >         GSSAPIAuthentication yes
>>>> >> > [root at ipa01 ~]# grep -i GSSAPI  /etc/ssh/sshd_config
>>>> >> > # GSSAPI options
>>>> >> > GSSAPIAuthentication yes
>>>> >> > GSSAPICleanupCredentials yes
>> >
>> > Your original pasted example showed you ssh'ing to user at 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 (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>
>> >
> 
> --
> MAT
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 


________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos




More information about the Kerberos mailing list