Description of problem: When having a Kerberos Authentication sshd setup, if you connect to a F22 system running sshd it fails "Read from socket failed: Connection reset by peer" on the client, if " GSSAPIKeyExchange yes" is in sshd_config. Version-Release number of selected component (if applicable): openssh-server-6.8p1-6.fc22.x86_64 How reproducible: Every time Steps to Reproduce: 1. Setup sshd_config for GSSAPI Authentication i.e. # GSSAPI options GSSAPIAuthentication yes GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes GSSAPIKeyExchange yes #GSSAPIEnablek5users no GSSAPIStoreCredentialsOnRekey yes 2.Run a test sshd daemon e.g. /usr/sbin/sshd -ddde -p 23 3.Attempt to login to this machine from another system. 4. Setting "GSSAPIKeyExchange no" in sshd_config restores a working GSSAPI and plain password authentication. Actual results: On the client: % ssh -p 23 testfed Read from socket failed: Connection reset by peer On the server: Connection from 10.12.10.15 port 33532 on 10.12.10.27 port 23 debug1: Client protocol version 2.0; client software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.8 debug2: fd 3 setting O_NONBLOCK debug3: ssh_sandbox_init: preparing seccomp filter sandbox debug2: Network child is on pid 4575 debug3: preauth child monitor started debug1: SELinux support disabled [preauth] debug3: privsep user:group 74:74 [preauth] debug1: permanently_set_uid: 74/74 [preauth] debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth] debug3: ssh_sandbox_child: attaching seccomp filter program [preauth] debug1: list_hostkey_types: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] debug1: monitor_read_log: child log fd closed debug3: mm_request_receive entering mm_request_receive: socket closed debug1: do_cleanup debug3: PAM: sshpam_thread_cleanup entering debug1: Killing privsep child 4575 This fails whether attempting to connect GSSAPI or just without and using password auth. Expected results: A logged in session Additional info:
Hi, thank you for a report. It looks like sandbox issue for me. Can you give it a try without seccomp filter on server? Just try to set up "UsePrivilegeSeparation yes" instead of sandbox. If this would make the change, can you have a look into audit log and search for SECCOMP messages -- maybe gssapi is issuing some syscall that I missed and it is getting killed by kernel.
Setting, UsePrivilegeSeparation yes Instead of sandbox does indeed allow this to work again.
And do you have some messages related to sshd and seccomp in your audit log from the previous tries with sandbox? I currently don't have GSSAPI infrastructure with F22 set up so providing some more details would help me investigating this issue.
Ok. Here we go. I found regression based on bz1195065. Maybe stat syscall is legacy, but it is still called from gssapi (legacy library Marcin?) For further reference, here is backtrace: #0 0x00007ffff526dc65 in __GI___xstat (vers=vers@entry=1, name=name@entry=0x709490 "/usr/lib64/gssproxy/proxymech.so", buf=buf@entry=0x7fffffffdae0) at ../sysdeps/unix/sysv/linux/wordsize-64/xstat.c:35 #1 0x00007ffff364c56b in stat (__statbuf=0x7fffffffdae0, __path=<optimized out>) at /usr/include/sys/stat.h:454 #2 krb5int_open_plugin (filepath=0x709490 "/usr/lib64/gssproxy/proxymech.so", h=h@entry=0x7fffffffdbf8, ep=ep@entry=0x7fffffffdc10) at plugins.c:183 #3 0x00007ffff5c716c7 in loadInterMech (minfo=0x707910) at g_initialize.c:872 #4 updateMechList () at g_initialize.c:476 #5 0x00007ffff5c71b3a in build_mechSet () at g_initialize.c:284 #6 gss_indicate_mechs (minorStatus=0x7fffffffdd04, mechSet_out=0x7fffffffdd10) at g_initialize.c:238 #7 0x00000000004395ae in ssh_gssapi_supported_oids (oidset=0x7fffffffdd30) at ../openssh-6.8p1/gss-serv.c:180 #8 0x000000000043948f in ssh_gssapi_server_mechanisms () at ../openssh-6.8p1/gss-serv.c:151 #9 0x000000000040f5cc in do_ssh2_kex () at ../openssh-6.8p1/sshd.c:2736 #10 0x000000000040e636 in main (ac=5, av=0x705d00) at ../openssh-6.8p1/sshd.c:2313 and error produced by sshd: ssh_sandbox_violation: unexpected system call (arch:0xc000003e,syscall:4 @ 0x7ffff526dc65) [preauth] I am returning stat back to syscall filter to avoid this problem.
openssh-6.8p1-8.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/openssh-6.8p1-8.fc22
Package openssh-6.8p1-8.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing openssh-6.8p1-8.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-9685/openssh-6.8p1-8.fc22 then log in and leave karma (feedback).
openssh-6.8p1-8.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.