small glitch with sshd_config slackware 14.1 RC1 RC2
 

I have been recompiling openssh to allow Active Directory/kerberos based logins. This depends on having kerberos installed. This is not a standard Slackware setup, so take this for what it is worth.

I have been preparing a baseline setup to test Slackware 14.1. I ran into a an issue that was preventing an Active Directory user from logging in, but not a local user with either a key or a password.

The solution appears to involve toggling a sshd_config parameter to use a non-default value:

UsePrivilegeSeparation yes

The default using "sandbox" fails the login for some reason. For comparison the default configuration works on a similar Slackware 14.0 box. This works fine there:

UsePrivilegeSeparation sandbox

The difference in packages are summarized below.

Slackware Version openssh priv sep krb5 from MIT
14.0 6.1p1 sandbox 1.9.5
14.1 RC2 6.3p1 yes 1.10.6

You have too many variables right now.

I suggest you compile 6.1p1 and 1.9.5 on 14RC2 and test the 3 remaining combos:

(a) 6.3p1 & 1.9.5
(b) 6.1p1 & 1.10.6
(c) 6.1p1 & 1.9.5

If the problem remains in (c) then it's something other than OpenSSH/Kerberos. If only one of (a) or (b) solves then the one you downgraded
would appear to be the culprit. If either (a) or (b) solve then it's an interaction between 6.3p1 and 1.10.6 that is the problem.

Also, I'd shut down the server "/etc/rc.d/rc.sshd stop" and restart in a terminal in debug mode with "/usr/sbin/sshd -d".

Watch that terminal for clues while the client tries to connect.

--mancha

More Tests
 

test openssh krb5 UsePrivilegeSeparation Result of Test
1 6.1p1 1.10.6 sandbox fail
2 6.1p1 1.10.6 yes success
3 6.1p1 1.9.5 sandbox fail
4 6.1p1 1.9.5 yes success
5 6.3p1 1.9.5 sandbox fail
6 6.3p1 1.9.5 yes success
7 6.3p1 1.10.6 sandbox fail
8 6.3p1 1.10.6 yes success

result of tests running sshd from command line

Your test #3 is what I referred to as (c) in my post and shows your issue is not related to the OpenSSH upgrades from 14.0 to RC1/2.

Some GSSAPI component is invoking a seccomp-disallowed syscall. Until Kerberos and OpenSSH figure this out it appears you won't be able to use seccomp to sandbox the pre-authentication unprivileged process when using Kerberos. So, either relax pre-authentication sandboxing with "UsePrivilegeSeparation yes" as you've done or try building OpenSSH with the rlimit pseudo-sandbox instead (though this results in a larger attack surface).

Why does 6.1p1+1.9.5 work with pre-authentication sandboxing on your 14.0 machine? Is OpenSSH not using seccomp in that case? I'd be curious to see a similar server log for the successful connection on 14.0.

--mancha