Quincey Koziol
2006-Dec-14 21:32 UTC
Problems using gssapi authentication from FreeBSD to Linux machines
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.
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 *
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
Here's the log of "ssh -v -v -v" connecting from the FreeBSD box
to
the Linux box: (you can see that the login succeeds because I typed
in my password)
OpenSSH_4.5p1 FreeBSD-20061110, OpenSSL 0.9.7e-p1 25 Oct 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to kagiso.hdfgroup.uiuc.edu [192.17.35.93] port 22.
debug1: Connection established.
debug1: identity file /home/koziol/.ssh/identity type -1
debug1: identity file /home/koziol/.ssh/id_rsa type -1
debug1: identity file /home/koziol/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-
sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-
sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss,ssh-rsa
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-
hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-
ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-
ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 135/256
debug2: bits set: 497/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/koziol/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug1: Host 'kagiso.hdfgroup.uiuc.edu' is known and matches the DSA
host key.
debug1: Found key in /home/koziol/.ssh/known_hosts:2
debug2: bits set: 526/1024
debug1: ssh_dss_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/koziol/.ssh/identity (0x0)
debug2: key: /home/koziol/.ssh/id_rsa (0x0)
debug2: key: /home/koziol/.ssh/id_dsa (0x0)
debug1: Authentications that can continue: gssapi-with-mic,password
debug3: start over, passed a different list gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-
interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
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: Authentications that can continue: gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,keyboard-interactive,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
debug3: packet_send2: adding 48 (len 62 padlen 18 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug2: fd 5 setting O_NONBLOCK
debug3: fd 6 is O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty_make_modes: ospeed 9600
debug3: tty_make_modes: ispeed 9600
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 8
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 255
debug3: tty_make_modes: 7 255
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 11 25
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 17 20
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 1
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 1
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 1
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 1
debug3: tty_make_modes: 61 1
debug3: tty_make_modes: 62 1
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
Last login: Thu Dec 14 22:54:25 2006 from duty.hdfgroup.uiuc.edu
**** Message of the Day ****
Kagiso has backup running on /, /home and /mnt/hdf. Email me restore
requests.
In your mail, specify the complete pathname of the files you need
recovery.
-AKC- 2006/07/17.
Kagiso /home is restored to as of November 16th, 2AM. Pleaes check your
area to see if you miss some files or detect some errors. Email
hdfadmin
if you have problem. -AKC- 2006/11/19.
(You can read this message again by "cat /etc/motd".)
[koziol@kagiso ~]$ exit
logout
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
debug3: channel 0: close_fds r -1 w -1 e 6 c -1
debug1: fd 1 clearing O_NONBLOCK
debug3: fd 2 is not O_NONBLOCK
Connection to kagiso.hdfgroup.uiuc.edu closed.
debug1: Transferred: stdin 0, stdout 0, stderr 48 bytes in 9.3 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 5.1
debug1: Exit status 0
And here's the log of another Linux box connecting to the Linux
machine: (which succeeds using the Kerberos ticket)
OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to kagiso [192.17.35.93] port 22.
debug1: Connection established.
debug1: identity file /home/koziol/.ssh/identity type -1
debug1: identity file /home/koziol/.ssh/id_rsa type -1
debug1: identity file /home/koziol/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-
hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-
hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-
ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-
ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 133/256
debug2: bits set: 522/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/koziol/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 3
debug3: check_host_in_hostfile: filename /home/koziol/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 3
debug1: Host 'kagiso' is known and matches the RSA host key.
debug1: Found key in /home/koziol/.ssh/known_hosts:3
debug2: bits set: 501/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/koziol/.ssh/identity ((nil))
debug2: key: /home/koziol/.ssh/id_rsa ((nil))
debug2: key: /home/koziol/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: gssapi-with-mic,password
debug3: start over, passed a different list gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-
interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
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).
debug2: fd 5 setting O_NONBLOCK
debug3: fd 6 is O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty_make_modes: ospeed 9600
debug3: tty_make_modes: ispeed 9600
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 8
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 0
debug3: tty_make_modes: 7 0
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 37 0
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 1
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 1
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 52 0
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 1
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 1
debug3: tty_make_modes: 61 1
debug3: tty_make_modes: 62 1
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 71 0
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
Last login: Thu Dec 14 23:12:03 2006 from duty.hdfgroup.uiuc.edu
**** Message of the Day ****
Kagiso has backup running on /, /home and /mnt/hdf. Email me restore
requests.
In your mail, specify the complete pathname of the files you need
recovery.
-AKC- 2006/07/17.
Kagiso /home is restored to as of November 16th, 2AM. Pleaes check your
area to see if you miss some files or detect some errors. Email
hdfadmin
if you have problem. -AKC- 2006/11/19.
(You can read this message again by "cat /etc/motd".)
[koziol@kagiso ~]$ exit
logout
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
debug3: channel 0: close_fds r -1 w -1 e 6 c -1
debug1: fd 1 clearing O_NONBLOCK
debug3: fd 2 is not O_NONBLOCK
Connection to kagiso closed.
debug1: Transferred: stdin 0, stdout 0, stderr 30 bytes in 4.9 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 6.2
debug1: Exit status 0
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"?
Thanks,
Quincey Koziol
koziol@hdfgroup.org
Boris Samorodov
2006-Dec-14 23:53 UTC
Problems using gssapi authentication from FreeBSD to Linux machines
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
Apparently Analagous Threads
- openssh 3.7.1p2 linux port problem
- ssh with iptables and equalize
- [Bug 387] New: command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only"
- [Bug 837] connection closed by remote host
- X11 connection rejected because of wrong authentication