still have password authentication with ssh

Mon Jul 23 11:11:36 EDT 2007

So here the log of sshd with DEBUG-Level 2:

Jul 23 15:01:30 kerb-server sshd[3200]: Connection from ::ffff:10.0.0.90
port 53793
Jul 23 15:01:30 kerb-server sshd[3185]: debug1: Forked child 3200.
Jul 23 15:01:30 kerb-server sshd[3200]: debug1: Client protocol version
2.0; client software version OpenSSH_3.8.1p1  Debian-krb5 3.8.1p1-10
Jul 23 15:01:30 kerb-server sshd[3200]: debug1: match: OpenSSH_3.8.1p1 
Debian-krb5 3.8.1p1-10 pat OpenSSH*
Jul 23 15:01:30 kerb-server sshd[3200]: debug1: Enabling compatibility
mode for protocol 2.0
Jul 23 15:01:30 kerb-server sshd[3200]: debug1: Local version string
SSH-2.0-OpenSSH_3.8.1p1  Debian-krb5 3.8.1p1-10
Jul 23 15:01:30 kerb-server sshd[3200]: debug2: Network child is on pid 3201
Jul 23 15:01:30 kerb-server sshd[3200]: debug1: Miscellaneous failure No
principal in keytab matches desired name
Jul 23 15:01:30 kerb-server sshd[3200]: debug1: Miscellaneous failure No
principal in keytab matches desired name
Jul 23 15:01:30 kerb-server sshd[3200]: debug2: monitor_read: 0 used
once, disabling now
Jul 23 15:01:30 kerb-server sshd[3200]: debug2: monitor_read: 4 used
once, disabling now
Jul 23 15:01:30 kerb-server sshd[3200]: debug2: monitor_read: 6 used
once, disabling now
Jul 23 15:01:30 kerb-server sshd[3200]: debug1: PAM: initializing for "nils"
Jul 23 15:01:30 kerb-server sshd[3200]: debug1: PAM: setting PAM_RHOST
to "kerb-client"
Jul 23 15:01:30 kerb-server sshd[3200]: debug1: PAM: setting PAM_TTY to
"ssh"
Jul 23 15:01:30 kerb-server sshd[3200]: debug2: monitor_read: 51 used
once, disabling now
Jul 23 15:01:30 kerb-server sshd[3200]: debug2: monitor_read: 3 used
once, disabling now
Jul 23 15:01:30 kerb-server sshd[3200]: Failed none for nils from
::ffff:10.0.0.90 port 53793 ssh2
Jul 23 15:01:30 kerb-server sshd[3200]: debug1: Miscellaneous failure No
principal in keytab matches desired name

The message "Miscellaneous failure No principal in keytab matches
desired name" apparently seems to contain the problem.
So here's the output of klist -k on the client (named kerb-client):

Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
----
--------------------------------------------------------------------------
   3 host/kerb-client.fra.loc at BFK.LOC
   3 host/kerb-client.fra.loc at BFK.LOC

and here's this of the ssh-server:

Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
----
--------------------------------------------------------------------------
   3 host/kerb-server.fra.loc at BFK.LOC
   3 host/kerb-server.fra.loc at BFK.LOC

Did I miss something here? Apparently yes, but what?

Douglas E. Engert schrieb:
>
>
> Nils Achtergarde wrote:
>> Douglas E. Engert schrieb:
>>> The more interesting log would have been from sshd.
>> Can't find a sshd-logfile.
>> I tried to run the ssh-krb5 with -d switch for debugging, but this
>> doesn't seem to work for the kerberized ssh-daemon.
>> How do I get any debug messages?
>
> You should beable to starta sshd deamin with debugging on a seperate
> port,
>
> something like:
>
>  /usr/sbin/sshd -d -d -d -p 2222
>
> then have the client connect to this port.
>
>  ssh -p 2222 ...
>
>>>
>>> Doc_symbiosis wrote:
>>>> Hi,
>>>>
>>>> I'm just testing Kerberos and wonder, why ssh still wants a
>>>> password. On
>>>> both PCs ( server with Ubuntu feisty client with Ubuntu Dapper ), the
>>>> user
>>>> has the krbTGT and after running the ssh-command on the client, I
>>>> also have
>>>> a host ticket of the server on it.
>>> Do the user names and the principal name in the ticket match?
>> The username and the principal's name in the ticket match.
>>> It could be you need to have a ~/.k5login file in the home directory
>>> of the user on the server side.
>>>
>>> It could also be the service principal name used by the server does
>>> not agree with what sshd thinks it should be, and so sshd can not
>>> find the service principal in the kerberos keytab file on the server.
>>>
>> What principal does the sshd expect? I searched a long time, didn't get
>> any information and ao I added ssh/myserver.mydom.loc as service
>> pricipal.
>
> No it is expecting host/myserver.mydom.loc at realm
>
> All the "login" type daemons (krlogin, ksh, telnet, pam_krb5) use the
> "host"
> service name, as they all in effect login the user.
>
>
>> But I thought, that i can spare this with kerberized ssh.
> You mght, if the sshd_config
>>> The syslog and/or the debug output of the sshd should show the above.
>>>
>>>> Here's the output of ssh -v user at server
>>>> <code>
>>>> OpenSSH_3.8.1p1  Debian-krb5 3.8.1p1-10, OpenSSL 0.9.7g 11 Apr 2005
>>>> debug1: Reading configuration data /etc/ssh/ssh_config
>>>> debug1: Connecting to nils.bfk.loc [192.168.1.210] port 22.
>>>> debug1: Connection established.
>>>> debug1: identity file /root/.ssh/identity type -1
>>>> debug1: identity file /root/.ssh/id_rsa type -1
>>>> debug1: identity file /root/.ssh/id_dsa type -1
>>>> debug1: Remote protocol version 2.0, remote software version
>>>> OpenSSH_4.3p2
>>>> Debian-8ubuntu1
>>>> debug1: match: OpenSSH_4.3p2 Debian-8ubuntu1 pat OpenSSH*
>>>> debug1: Enabling compatibility mode for protocol 2.0
>>>> debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1  Debian-krb5
>>>> 3.8.1p1-10
>>>> debug1: Mechanism encoded as toWM5Slw5Ew8Mqkay+al2g==
>>>> debug1: Mechanism encoded as A/vxljAEU54gt9a48EiANQ==
>>>> 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 'nils.bfk.loc' is known and matches the RSA host key.
>>>> debug1: Found key in /root/.ssh/known_hosts:2
>>>> 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-keyex,gssapi-with-mic,password
>>>> debug1: Next authentication method: gssapi-with-mic
>>>> debug1: Authentications that can continue:
>>>> publickey,gssapi-keyex,gssapi-with-mic,password
>>>> debug1: Authentications that can continue:
>>>> publickey,gssapi-keyex,gssapi-with-mic,password
>>>> debug1: Next authentication method: publickey
>>>> debug1: Trying private key: /root/.ssh/identity
>>>> debug1: Trying private key: /root/.ssh/id_rsa
>>>> debug1: Trying private key: /root/.ssh/id_dsa
>>>> debug1: Next authentication method: password
>>>> </code>
>>>>
>>>> I have installed ssh-krb5 on both PCs and set   
>>>> GSSAPIAuthentication yes
>>>>     GSSAPIDelegateCredentials yes
>>>> in the ssh_config and in sshd_config I have set
>>>>      GSSAPIAuthentication yes
>>>>      GSSAPICleanupCredentials yes
>>>>
>>>> Anyone got an idea, what's wrong?
>>>> I followed two instructions command by command, but both end in the
>>>> same
>>>> result.
>>>> Thanks in advance
>>>>
>>>>
>> So, my main problem is to get any debug report from ssh-krb5.
>>
>

-- 
My public PGP-key: http://www.num.math.uni-goettingen.de/~nachterg/n.achtergarde_media-net.de_pub.asc