https://bugzilla.mindrot.org/show_bug.cgi?id=3702
--- Comment #2 from Nikola <[email protected]> --- Yes, here are the results from what I understand. sshd logs: debug1: inetd sockets after dupping: 4, 4 debug3: process_channel_timeouts: setting 0 timeouts debug3: channel_clear_timeouts: clearing Connection from ::1 port 46784 on ::1 port 222 rdomain "" debug1: Local version string SSH-2.0-OpenSSH_9.7 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 Raspbian-2+deb12u2 debug1: compat_banner: match: OpenSSH_9.2p1 Raspbian-2+deb12u2 pat OpenSSH* compat 0x04000000 debug2: fd 4 setting O_NONBLOCK debug3: ssh_sandbox_init: preparing seccomp filter sandbox debug2: Network child is on pid 13980 debug3: preauth child monitor started debug3: privsep user:group 103:65534 [preauth] debug1: permanently_set_uid: 103/65534 [preauth] debug3: ssh_sandbox_child_debugging: installing SIGSYS handler [preauth] debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth] debug3: ssh_sandbox_child: attaching seccomp filter program [preauth] debug1: monitor_read_log: child log fd closed debug3: mm_request_receive: entering debug1: do_cleanup debug1: Killing privsep child 13980 debug3: oom_adjust_setup debug1: Set /proc/self/oom_score_adj from 0 to -1000 debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 222 on 0.0.0.0. Server listening on 0.0.0.0 port 222. debug2: fd 5 setting O_NONBLOCK debug3: sock_set_v6only: set socket 5 IPV6_V6ONLY debug1: Bind to port 222 on ::. Server listening on :: port 222. debug3: fd 6 is not O_NONBLOCK debug1: Forked child 13999. debug3: send_rexec_state: entering fd = 9 config len 3153 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug3: oom_adjust_restore debug1: Set /proc/self/oom_score_adj to 0 debug1: rexec start in 6 out 6 newsock 6 pipe 8 sock 9 debug1: inetd sockets after dupping: 4, 4 debug3: process_channel_timeouts: setting 0 timeouts debug3: channel_clear_timeouts: clearing Connection from ::1 port 37764 on ::1 port 222 rdomain "" debug1: Local version string SSH-2.0-OpenSSH_9.7 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 Raspbian-2+deb12u2 debug1: compat_banner: match: OpenSSH_9.2p1 Raspbian-2+deb12u2 pat OpenSSH* compat 0x04000000 debug2: fd 4 setting O_NONBLOCK debug3: ssh_sandbox_init: preparing seccomp filter sandbox debug2: Network child is on pid 14000 debug3: preauth child monitor started debug3: privsep user:group 103:65534 [preauth] debug1: permanently_set_uid: 103/65534 [preauth] debug3: ssh_sandbox_child_debugging: installing SIGSYS handler [preauth] debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth] debug3: ssh_sandbox_child: attaching seccomp filter program [preauth] debug1: monitor_read_log: child log fd closed debug3: mm_request_receive: entering debug1: do_cleanup debug1: Killing privsep child 14000 After more careful inspection, the kernel log seems to sometimes indicate syscall "384" and at other times "20" when initiating an ssh connection: [ 5106.975827] audit: type=1326 audit(1718651226.051:2): auid=1000 uid=103 gid=65534 ses=8 pid=8620 comm="sshd" exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=384 compat=1 ip=0xf7a4d330 code=0x0 [ 5159.653285] audit: type=1326 audit(1718651278.730:3): auid=1000 uid=103 gid=65534 ses=8 pid=8651 comm="sshd" exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=384 compat=1 ip=0xf74bd330 code=0x0 [ 5332.463045] audit: type=1326 audit(1718651451.531:4): auid=1000 uid=103 gid=65534 ses=8 pid=8711 comm="sshd" exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=384 compat=1 ip=0xf744d330 code=0x0 [ 5435.206654] audit: type=1326 audit(1718651554.277:5): auid=1000 uid=103 gid=65534 ses=8 pid=8746 comm="sshd" exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=20 compat=1 ip=0xf779252c code=0x0 [ 5483.156487] audit: type=1326 audit(1718651602.225:6): auid=1000 uid=103 gid=65534 ses=8 pid=8780 comm="sshd" exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=20 compat=1 ip=0xf7b0252c code=0x0 [ 5930.773091] audit: type=1326 audit(1718652049.838:7): auid=1000 uid=103 gid=65534 ses=8 pid=8842 comm="sshd" exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=384 compat=1 ip=0xf749d330 code=0x0 [ 6229.482998] audit: type=1326 audit(1718652348.541:8): auid=1000 uid=103 gid=65534 ses=8 pid=8934 comm="sshd" exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=20 compat=1 ip=0xf743252c code=0x0 [ 6585.188845] audit: type=1326 audit(1718652704.242:9): auid=1000 uid=103 gid=65534 ses=8 pid=16018 comm="sshd" exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=20 compat=1 ip=0xf7a0252c code=0x0 [ 6796.206919] audit: type=1326 audit(1718652915.250:10): auid=1000 uid=103 gid=65534 ses=8 pid=23058 comm="sshd" exe="/home/pi/openssh-9.7p1/sshd" sig=31 arch=40000028 syscall=20 compat=1 ip=0xf7a8252c code=0x0 Although I'm not sure whether to trust that either. Another thing I've noticed is that procfs shows processes performing a syscall that is not implemented according to the header file and multiple other sources I found online. $ sudo cat /proc/1/syscall 252 0x4 0x18f69a8 0x8e 0xffffffff 0xffffffff 0x8e 0xffcce428 0xf75e7158 $ $ grep 252 /usr/include/asm-generic/unistd.h $ $ sudo cat /proc/13994/syscall 336 0x2425a08 0x2 0x0 0xffa76818 0x8 0x2 0xffa76528 0xf742297c $ $ grep 336 /usr/include/asm-generic/unistd.h $ I don't know if this is due to some sort of incorrect mapping, I will investigate further and see what I find. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
