Problems using gssapi authentication from FreeBSD to Linux
machines
Boris Samorodov
bsam at ipt.ru
Thu Dec 14 23:51:49 PST 2006
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
More information about the freebsd-security
mailing list