Recently I decided to buy a NanoPi R5S to use as a router, and, instead of using their default build which is based off OpenWRT called FriendlyWRT, I opted to use the regular OpenWRT.
However, since there's no mainline support for it yet, I opted to go with this fork, which does seem to work without problems for the most part.
Did my own build, managed to boot it, toyed around a bit and finally decided to replace the default dropbear SSH server with OpenSSH to have more features. As soon as I tried to connect with a password, I got a funky error on the client side. The relevant log lines from the client-side with -vvv are shown below:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
Authenticated to 192.168.2.1 ([192.168.2.1]:22) using "password".
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: filesystem
debug3: send packet: type 1
client_loop: send disconnect: Broken pipe
And here is the logs from the server-side:
Sat Aug 5 23:29:07 2017 auth.info sshd[6449]: Server listening on 0.0.0.0 port 22.
Sat Aug 5 23:29:07 2017 auth.info sshd[6449]: Server listening on :: port 22.
Sat Aug 5 23:29:16 2017 auth.info sshd[6483]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Sat Aug 5 23:29:16 2017 auth.info sshd[6483]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Sat Aug 5 23:29:16 2017 auth.info sshd[6483]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
Sat Aug 5 23:29:17 2017 auth.info sshd[6483]: Accepted password for root from 192.168.2.10 port 40942 ssh2
Sat Aug 5 23:29:17 2017 auth.crit sshd[6483]: fatal: ssh_sandbox_violation: unexpected system call (arch:0xc00000b7,syscall:66 @ 0xffff894f2370) [preauth]
Sat Aug 5 23:29:17 2017 auth.crit sshd[6483]: fatal: privsep_preauth: preauth child exited with status 1
I'm not really sure if this is a problem with OpenSSH itself, with the linux build I did, or something else, so any ideas are more than welcome so I could at least post this in the appropriate project's issue tracker.
So far I tried different kernel versions (6.0, 6.1 and the current RC for 6.2) to no avail.
I looked into OpenSSH source, and it seems that this error steams from this function, which led me to trying to disable seccomp and selinux in my build. Any combination of those being enabled/disabled didn't work.
I found other two issues (this and this) that may be somewhat related, which were solved by changing the UsePrivilegeSeparation sshd config parameter, however this parameter has been deprecated now, so it doesn't work either.
For the sake of it, I tried disabling and enabling random SSL/TLS related stuff in my build, however it didn't change anything either.
A possible solution would be to try to do a different build of OpenSSH, however this would imply in me either setting up a cross-compiling toolchain on my desktop and build a static binary in my desktop (which would require more time than I have available) or setting up a toolchain in the device itself, which I believe would be unbearably slow and also require some effort that I'm not sure if it's worth it since the problem may lie elsewhere.
CodePudding user response：
The OpenWrt os/environment is pretty customized and makes a lot of assumptions in order to be a usable embedded router like people expect while staying within limited file/memory/cpu requirements. I'd highly recommend using Dropbear if at all possible.
Otherwise, this guide talks about replacing dropbear with a stock openssh package available without recompilation.
Finally, I'd avoid trying to compile binaries on your system and copy-pasting them into OpenWRT; the standard build environment for OpenWRT is highly advanced and always looks like cross-compiling even though it may be the same architecture as your computer: the specific libraries used, patches applied (like the patch you're thinking about needing to add!), and expected environment are all unique to OpenWRT. The environment isn't super hard to set up, so I highly recommend using it whenever possible.
You'll likely get better support on the OpenWRT discussion boards or IRC rooms, questions like this are asked all the time and I've found them pretty helpful. Cheers!
CodePudding user response：
It looks like the issue might be with the OpenSSH version you are using on the server. It appears that the server is experiencing a "ssh_sandbox_violation" error after the client successfully authenticates using the password. This error message is typically caused by a problem with the OpenSSH sandbox, which is a security feature that runs untrusted code in a restricted environment to protect the system. It is possible that the version of OpenSSH you are using is not compatible with the NanoPi R5S or has a bug that is causing the sandbox violation.
I would recommend trying a different version of OpenSSH or reverting back to the default dropbear SSH server to see if that resolves the issue. You could also try checking for any available updates or patches for the version of OpenSSH you are using.