Kerberos auth based on ticket

Mathew Rowley mathew_rowley at cable.comcast.com
Tue Dec 16 06:48:31 EST 2008


[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
> 





More information about the Kerberos mailing list