On Thu, 14 Dec 2006 23:34:17 -0600 Quincey Koziol wrote:

> Hi all,
>       I'm really struggling with getting Kerberos authentication to
> work  between a FreeBSD host and a Linux host.  I'm using the latest
> 6- 
> STABLE code on the FreeBSD box, I've got forwardable Kerberos tokens
> (verified with "klist -f") and Kerberos and ssh are working fine in
> all other ways, but I can't get the Linux box to accept the Kerberos
> ticket as authentication from the FreeBSD machine.  The Linux box
> accepts Kerberos credentials from other Linux machines and I can use
> ssh on the FreeBSD machine to connect to itself with Kerberos
> credentials (i.e. not required to type my password).  This leads me
> to believe that either the protocol for forwarding the Kerberos
> credentials is different between the two machines or there's another
> minor tweak I need to make to the ssh_config file on the FreeBSD
> machine.  One other difference is that the Linux box is running
> OpenSSH 3.9p1 and the FreeBSD box is running OpenSSH 4.5p1.

This difference should not be a problem.

>       Here's my ssh_config from the FreeBSD machine:

> #     $OpenBSD: ssh_config,v 1.22 2006/05/29 12:56:33 dtucker Exp $
> #     $FreeBSD: src/crypto/openssh/ssh_config,v 1.27.2.4 2006/11/11
> 00:51:28 des Exp $

> # This is the ssh client system-wide configuration file.  See
> # ssh_config(5) for more information.  This file provides defaults for
> # users, and the values can be changed in per-user configuration files
> # or on the command line.

> # Configuration data is parsed as follows:
> #  1. command line options
> #  2. user-specific file
> #  3. system-wide file
> # Any configuration value is only changed the first time it is set.
> # Thus, host-specific definitions should be at the beginning of the
> # configuration file, and defaults at the end.

> # Site-wide defaults for some commonly used options.  For a
> comprehensive
> # list of available options, their meanings and defaults, please see the
> # ssh_config(5) man page.

> # Host *
> #   ForwardAgent no
> #   ForwardX11 no
> #   RhostsRSAAuthentication no
> #   RSAAuthentication yes
> #   PasswordAuthentication yes
> #   HostbasedAuthentication no
> #   GSSAPIAuthentication no
> #   GSSAPIDelegateCredentials no
> #   BatchMode no
> #   CheckHostIP no
> #   AddressFamily any
> #   ConnectTimeout 0
> #   StrictHostKeyChecking ask
> #   IdentityFile ~/.ssh/identity
> #   IdentityFile ~/.ssh/id_rsa
> #   IdentityFile ~/.ssh/id_dsa
> #   Port 22
> #   Protocol 2,1
> #   Cipher 3des
> #   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128- 
> cbc,arcfour,aes192-cbc,aes256-cbc
> #   EscapeChar ~
> #   Tunnel no
> #   TunnelDevice any:any
> #   PermitLocalCommand no
> #   VersionAddendum FreeBSD-20061110

> # Add kerberos ticket forwarding
> # QAK - 12/13/06
> Host *

May be it's paranoid but I prefer to use more strict values here,
i.e. *.my.domain. This may prevent sending my credentials to hosts if
I incidentally misspell a command.

>     GSSAPIAuthentication yes
>     GSSAPIDelegateCredentials yes
> # If this option is set to yes then the remote X11 clients will have
> full access
> # to the local X11 display. As virtually no X11 client supports the
> untrusted
> # mode correctly we set this to yes.
>     ForwardX11Trusted yes

[logs skipped]

>       The main difference I can see is that the FreeBSD log has this:

> debug2: we sent a gssapi-with-mic packet, wait for reply
> debug1: Delegating credentials
> debug1: Delegating credentials
> debug1: Authentications that can continue: gssapi-with-mic,password
> debug2: we did not send a packet, disable method
> debug3: authmethod_lookup password

>       And the Linux log has this:

> debug1: Next authentication method: gssapi-with-mic
> debug2: we sent a gssapi-with-mic packet, wait for reply
> debug1: Delegating credentials
> debug1: Delegating credentials
> debug1: Authentication succeeded (gssapi-with-mic).

>       Any ideas what could be causing the ssh on FreeBSD to "not
> send a  packet"?

Seems that the Linux host doesn't accept credentials. Do you have an
access to this box? If yes, run sshd with verbose debug ("ddd") at
different port (say, "-p 1000") and then try to connect to this host
via ssh from FreeBSD host. Look at debugging log for the connection
details. HTH


WBR
-- 
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to