Libopenssl-devcrypto crashes OpenSSH on x86/64 22.03.2

Installing and Using OpenWrt
1

Hi,

I tried to look for this in the Github issue tracker, but could not find anything.

I'm using 22.03.2 on x86/64 and switched from Dropbear to OpenSSH some time ago, for I had problems with Dropbear not handling SFTP/SCP correctly. OpenSSH has been working fine until today, when I installed libopenssl-devcrypto out of sheer curiosity (to see what openssl engine ... says about the available crypto support).

I logged out, then wanted to log back in a couple of hours later. I could not and had to use the serial console as a last resort. I saw this in the logs:

Thu Dec 15 18:17:41 2022 auth.info sshd[22821]: Accepted publickey for root from CLIENTIP port 51676 ssh2: ED25519 SHA256:HASH_HERE
Thu Dec 15 18:17:41 2022 auth.crit sshd[22821]: fatal: privsep_preauth: preauth child terminated by signal 31
Thu Dec 15 18:17:56 2022 auth.info sshd[23161]: Accepted password for root from CLIENTIP port 51677 ssh2
Thu Dec 15 18:17:56 2022 auth.crit sshd[23161]: fatal: privsep_preauth: preauth child terminated by signal 31

As you can see, both key-based and password-based login would work, but sshd's child process crashes with SIGSYS.

Then it dawned on me: the only change I did was installing the package before. I removed it, restarted OpenSSH and now it works again correctly.

It looks like a bug, but I'm not quite sure.

2

Does the machine actually have a hardware crypto engine?

That's your answer

SIGSYS
"Signal system call"
The SIGSYS signal is sent to a process when it passes a bad argument to a system call. In practice, this kind of signal is rarely encountered since applications rely on libraries (e.g. libc) to make the call for them. SIGSYS can be received by applications violating the Linux Seccomp security rules configured to restrict them. SIGSYS can also be used to emulate foreign system calls, e.g. emulate Windows system calls on Linux.[19]

From: https://en.wikipedia.org/wiki/Signal_(IPC)#POSIX_signals

3

Have you disabled digests?

1 Like
4

The CPU is a Celeron J6413, it has AES-NI, hence I wrote I'm not even sure if this is a bug.

But nonetheless I think it's not an ideal behaviour: OpenSSL should just probably fall back to some reasonable default when a module does not work.

5

Not explicitly, I used the default configuration that comes with the package.

6

then you should disable the devcrypto digests and retest