[30550] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Kerberos auth based on ticket

daemon@ATHENA.MIT.EDU (Chris Hoy Poy)
Tue Dec 16 11:16:55 2008

Date: Tue, 16 Dec 2008 20:19:41 +0800 (GMT+08:00)
From: Chris Hoy Poy <kryanth@gopc.net>
To: Mathew Rowley <mathew_rowley@cable.comcast.com>
Message-ID: <30645135.191521229429981561.JavaMail.root@mailstore01.gopc.net>
In-Reply-To: <15958590.191501229429525723.JavaMail.root@mailstore01.gopc.net>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit

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 PoySenior Infrastructure EngineerGoPC Pty Ltdhttp://www.gopc.net
----- Original Message -----From: "Mathew Rowley" <mathew_rowley@cable.comcast.com>To: "Chris Hoy Poy" <kryanth@gopc.net>Cc: kerberos@mit.eduSent: Tuesday, 16 December, 2008 8:48:31 PM GMT +08:00 PerthSubject: Re: Kerberos auth based on ticket
[mrowley@ipa01 ~]$ ssh -v mrowley@`hostname`OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006debug1: Reading configuration data /etc/ssh/ssh_configdebug1: Applying options for *debug1: Connecting to ipa01.security.lab.comcast.com [10.252.152.73] port22.debug1: Connection established.debug1: identity file /home/mrowley/.ssh/identity type -1debug1: identity file /home/mrowley/.ssh/id_rsa type -1debug1: identity file /home/mrowley/.ssh/id_dsa type -1debug1: loaded 3 keysdebug1: Remote protocol version 2.0, remote software version OpenSSH_4.3debug1: match: OpenSSH_4.3 pat OpenSSH*debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_4.3debug1: SSH2_MSG_KEXINIT sentdebug1: SSH2_MSG_KEXINIT receiveddebug1: kex: server->client aes128-cbc hmac-md5 nonedebug1: kex: client->server aes128-cbc hmac-md5 nonedebug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_GROUPdebug1: SSH2_MSG_KEX_DH_GEX_INIT sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_REPLYdebug1: Host 'ipa01.security.lab.comcast.com' is known and matches the RSAhost key.debug1: Found key in /home/mrowley/.ssh/known_hosts:1debug1: ssh_rsa_verify: signature correctdebug1: SSH2_MSG_NEWKEYS sentdebug1: expecting SSH2_MSG_NEWKEYSdebug1: SSH2_MSG_NEWKEYS receiveddebug1: SSH2_MSG_SERVICE_REQUEST sentdebug1: SSH2_MSG_SERVICE_ACCEPT receiveddebug1: Authentications that can continue:publickey,gssapi-with-mic,passworddebug1: Next authentication method: gssapi-with-micdebug1: Unspecified GSS failure.  Minor code may provide more informationServer not found in Kerberos database
debug1: Unspecified GSS failure.  Minor code may provide more informationServer not found in Kerberos database
debug1: Unspecified GSS failure.  Minor code may provide more informationServer not found in Kerberos database
debug1: Next authentication method: publickeydebug1: Trying private key: /home/mrowley/.ssh/identitydebug1: Trying private key: /home/mrowley/.ssh/id_rsadebug1: Trying private key: /home/mrowley/.ssh/id_dsadebug1: Next authentication method: passwordmrowley@ipa01.security.lab.comcast.com's password:

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

________________________________________________Kerberos mailing list           Kerberos@mit.eduhttps://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________Kerberos mailing list           Kerberos@mit.eduhttps://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post