still have password authentication with ssh

Mon Jul 23 11:40:45 EDT 2007

Nils Achtergarde wrote:
> 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?
> 

Yes. The server principal should be  host/<hostname>@<realm>

Based on the previous client trace, the server's hostname is nils.bfk.loc
but the server's keytab has host/kerb-server.fra.loc at BFK.LOC
it should have host/nils.bfk.loc at BFK.LOC

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

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444