Seems to work on x86_64. Could you attach output of 'ssh -vvv ...' and server log with 'LogLevel DEBUG3'?

Don't work on i686 rawhide.

Feb 21 18:02:02 localhost kernel: audit: type=2404 audit(1424534522.864:96): pid=535 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:... direction=? spid=535 suid=0  exe="/usr/sbin/sshd" hostname=? addr=192.168.0.1 terminal=? res=success'

OpenSSH_6.6.1, OpenSSL 1.0.1k-fips 8 Jan 2015
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 74: Applying options for vmware
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/tmp/ssh_mux_192.168.0.2_22_root" does not exist
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.2 [192.168.0.2] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/user/.ssh/id_rsa.pub" as a RSA1 public key
debug1: identity file /home/user/.ssh/id_rsa.pub type 1
debug1: identity file /home/user/.ssh/id_rsa.pub-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7
debug1: match: OpenSSH_6.7 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.0.2" from file "/home/user/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/user/.ssh/known_hosts:55
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01,ssh-rsa-cert-v00,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01,ssh-rsa-cert-v00,ssh-rsa,ecdsa-sha2-nistp256-cert-v01,ecdsa-sha2-nistp384-cert-v01,ecdsa-sha2-nistp521-cert-v01,ssh-ed25519-cert-v01,ssh-dss-cert-v01,ssh-dss-cert-v00,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm,aes256-gcm,chacha20-poly1305,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm,aes256-gcm,chacha20-poly1305,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc.se
debug2: kex_parse_kexinit: hmac-md5-etm,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib,zlib
debug2: kex_parse_kexinit: none,zlib,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: curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes256-gcm,chacha20-poly1305
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes256-gcm,chacha20-poly1305
debug2: kex_parse_kexinit: umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-sha1-etm,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-sha1-etm,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-sha1
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_setup: setup hmac-sha1-etm
debug1: kex: server->client aes128-ctr hmac-sha1-etm none
debug2: mac_setup: setup hmac-sha1-etm
debug1: kex: client->server aes128-ctr hmac-sha1-etm none
debug1: kex: curve25519-sha256 need=20 dh_need=20
debug1: kex: curve25519-sha256 need=20 dh_need=20
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Read from socket failed: Connection reset by peer

Older build openssh-6.7p1-2.fc22 works.

There were changes on server side more then on client side so server logs with 'LogLevel DEBUG3' or -ddd option would be more useful.

I can only guess that there is a problem with introduced seccomp filter. To make sure, can you retest it also with server option 'UsePrivilegeSeparation yes'?


I can retest it only with x86_64 and it works fine for me.

From provided informations I can only guess that there can be some problem around kexc25519_server in kexc25519s.c, but I don't see there any system call that could be problematic (at least on x86_64).

I've hit the same issue:

openssh-6.7p1-2.fc22.armv7hl is working fine.

openssh-6.7p1-3.fc22.armv7hl is failing as described earlier with default config.  Testing with "UsePrivilegeSeparation yes" (instead of sandbox) in 
sshd_config works again.

running "sshd -ddd" (with default config) is a bit silent:

[...]
debug2: kex_parse_kexinit: none,zlib,zlib [preauth]
debug2: kex_parse_kexinit: none,zlib,zlib [preauth]
debug2: kex_parse_kexinit:  [preauth]
debug2: kex_parse_kexinit:  [preauth]
debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
debug2: kex_parse_kexinit: reserved 0  [preauth]
debug1: kex: client->server chacha20-poly1305 <implicit> none [preauth]
debug1: kex: server->client chacha20-poly1305 <implicit> none [preauth]
debug1: kex: curve25519-sha256 need=64 dh_need=64 [preauth]
debug1: monitor_read_log: child log fd closed
debug3: mm_request_receive entering
debug1: do_cleanup
debug3: PAM: sshpam_thread_cleanup entering
debug1: Killing privsep child 7250


Running sshd in gdb with "gdb --args /usr/sbin/sshd -ddd" and adding a breakpoint on "_exit" breaks here:

#0  0xb6a2cc38 in _exit () from /lib/libc.so.6
#1  0x2a00d128 in cleanup_exit (i=i@entry=255) at sshd.c:2735
#2  0x2a02a890 in mm_request_receive (sock=5, m=m@entry=0xbeffead4) at monitor_wrap.c:155
#3  0x2a028ebc in monitor_read (pmonitor=pmonitor@entry=0x2a0d10b0, ent=0x2a0c2208 <mon_dispatch_proto20>, 
    pent=pent@entry=0xbeffeb50) at monitor.c:641
#4  0x2a029e78 in monitor_child_preauth (_authctxt=<optimized out>, pmonitor=0x2a0d10b0) at monitor.c:435
#5  0x2a00b000 in privsep_preauth (authctxt=0x2a0cfe10) at sshd.c:738
#6  main (ac=<optimized out>, av=<optimized out>) at sshd.c:2227


The cleanup_exit(255) is silently called in mm_request_receive() at monitor_wrap.c:155:

153 if (atomicio(read, sock, buf, sizeof(buf)) != sizeof(buf)) {
154   if (errno == EPIPE)
155     cleanup_exit(255);
156   fatal("%s: read: %s", __func__, strerror(errno));
157 }

I hope this info could help.

This is failing on i686. And openssh-6.7p1-4 still has the problem.

Debugging on i686 showed me that the failure is again on system call getuid() in audit.c:143. This is the same issue I had on x86_64, but it was solved by whitelist.
After some digging I found that glibc is using getuid32 on ix86, which makes the difference. Adding this to whitelist helped me.

About ARM, it looks like the same issue. I would be glad if you can report back if current (openssh-6.7p1-7.fc22) version solved the issue.

I confirm that openssh-6.7p1-7.fc22.armv7hl fixes the issue (with default sshd_config "UsePrivilegeSeparation sandbox") for me.

Thanks.

Thanks for the testing. Closing as resolved.

openssh-server-6.7p1-7.fc23.i686 is working for me.