[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#858874: openssh-server: gssapi-keyex userauth fails with privsep and AuthenticationMethods both configured



Package: openssh-server
Version: 1:6.7p1-5+deb8u3
Severity: normal

I have a server running openssh-server at the 'edge' of my kerberos realm. From here I can jump into the rest of the network. When I try to connect to it from within the realm, however, the connection fails because it attempts to remove 'gssapi-with-mic' from the auth methods list instead of 'gssapi-keyex'.

The important lines in the configuration file are as follows:

# Technically, privsep can be set to anything but no
UsePrivilegeSeparation sandbox
GSSAPIKeyExchange yes
AuthenticationMethods publickey,keyboard-interactive:pam gssapi-keyex

>From the debug log on the server side:

debug1: userauth-request for user eashwar service ssh-connection method gssapi-keyex [preauth]
debug1: attempt 1 failures 0 [preauth]
debug2: input_userauth_request: try method gssapi-keyex [preauth]
debug3: mm_request_send entering: type 48 [preauth]
debug3: mm_request_receive_expect entering: type 49 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 4
debug3: mm_answer_authserv: service=ssh-connection, style=, role=
debug2: monitor_read: 4 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 48
debug3: mm_request_send entering: type 49
debug3: mm_request_send entering: type 46 [preauth]
debug3: mm_request_receive_expect entering: type 47 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 46
Authorized to eashwar, krb5 principal eashwar@EXAMPLE.COM (krb5_kuserok)
debug3: mm_answer_gss_userok: sending result 1
debug3: mm_request_send entering: type 47
debug3: auth2_update_methods_lists: updating methods list after "gssapi-with-mic"
auth2_update_methods_lists: method not in AuthenticationMethods
debug1: do_cleanup
debug1: PAM: cleanup
debug3: PAM: sshpam_thread_cleanup entering
debug1: Killing privsep child 5349

>From what I traced through the source code, it seems like 'mm_answer_gss_userok' in monitor.c is invoked for gssapi-with-mic and gssapi-keyex via the 'PRIVSEP(ssh_gssapi_userok(...))' calls, but always sets 'auth_method' to gssapi-with-mic.

I am working on a patch to address this by passing the auth method name to mm_answer_gss_userok through the buffer that it receives, but perhaps you have a better idea?

Regards,
Eashwar Ranganathan

-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openssh-server depends on:
ii  adduser                3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg                   1.17.27
ii  init-system-helpers    1.22
ii  libc6                  2.19-18+deb8u7
ii  libcomerr2             1.42.12-2+b1
ii  libgssapi-krb5-2       1.12.1+dfsg-19+deb8u2
ii  libkrb5-3              1.12.1+dfsg-19+deb8u2
ii  libpam-modules         1.1.8-3.1+deb8u2
ii  libpam-runtime         1.1.8-3.1+deb8u2
ii  libpam0g               1.1.8-3.1+deb8u2
ii  libselinux1            2.3-2
ii  libssl1.0.0            1.0.1t-1+deb8u6
ii  libwrap0               7.6.q-25
ii  lsb-base               4.1+Debian13+nmu1
ii  openssh-client         1:6.7p1-5+deb8u3
ii  openssh-sftp-server    1:6.7p1-5+deb8u3
ii  procps                 2:3.3.9-9
ii  zlib1g                 1:1.2.8.dfsg-2+b1

Versions of packages openssh-server recommends:
ii  ncurses-term  5.9+20140913-1
ii  xauth         1:1.0.9-1

Versions of packages openssh-server suggests:
pn  molly-guard   <none>
pn  monkeysphere  <none>
pn  rssh          <none>
pn  ssh-askpass   <none>
pn  ufw           <none>

-- debconf information excluded


Reply to: