New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#3816 - 21.02-SNAPSHOT - Building with LXC-Support breaks passwd (and something else?) #8881
Comments
thiscantbeserious: Tried the following workarounds - did nothing: https://forum.openwrt.org/t/unable-to-logon-via-luci-able-via-ssh/25408/9 Everything seems correct. Setting password again - keeping logged in going to LuCi webinterface: Wed May 19 13:00:01 2021 authpriv.info dropbear[4810]: Child connection from 192.168.1.177:1254 |
thiscantbeserious: Going further trying to do ssh -vvvv root@192.168.1.1 debug2: we sent a publickey packet, wait for reply |
thiscantbeserious: root@OpenWrt: root@OpenWrt: and root@OpenWrt:~# ls -la /etc/shadow |
thiscantbeserious: Maybe its related to docker? Will have to try ... |
thiscantbeserious: Will try a fresh config with the following manually set in .config: https://forum.openwrt.org/t/request-for-lxc-support-in-mvebu/58767/18 |
jow-:
This is a bcrypt hash which is not supported by musl libc unless you disable the crpyt size hack option during build. Normally, the builtin busybox You can likely solve the issue by rebuilding with the following option enabled in menuconfig: [] Advanced configuration options (for developers) |
thiscantbeserious: Many thanks for the explanation! Already guessed something was wrong in regards to encryption ... will try your tip. I certainly didn't enable the full shadow suite build myself. Maybe some of the utility settings for lxc, docker, dockerd or docker compose enables it? At least I'm now confident starting from scratch for any board for the basic build ... Edit: → [*] Include crypt() support for SHA256, SHA512 and Blowfish ciphers Sadly doesn't seem to fix the issue from a first try :/ Edit 2: Went ahead manually enabling full shadow suite, then enabling all the above in the kernel_menuconfig ... I guess it's something else. |
thiscantbeserious: Minimal case to reproduce this on mvebu on 21.02:
1. git checkout -b openwrt-21.02 --depth 1 https://github.com/openwrt/openwrt.git
2. ./scripts/fetch update -a
3. ./scripts/fetch install -a
4. make menuconfig
5. Target System: Marvell EBU Armada
6. Subtarget: Marvell Armada 3700LP (ARM64)
7. Target Profile: Marvell ESPRESSObin Non-eMMC
8. Utilities -> lxc -> Configuration:
Result: passwd cant be changed via LuCI, if you change it via SSH it will save something (?) and you can't login afterwards
BusyBox v1.33.1 () built-in shell (ash)
Even enabling most encryption options for the Kernel itself and the above Advanced Setting for sha256, sha516 and bcrypt support for crypt() does not fix it. It's also not related to the ssh-client (tried two different machines/clients). I'm as clueless as I was before. Will try the same on master next. |
rchmsr: I observe the same issue on x86-64, build for APU device. Any ideas how I can help tracking the issue down? |
bjonglez: It does not look like the regular busybox passwd, please provide the output of: # passwd --help ls -lh /bin/passwdls -lh $(which passwd)I would suspect this option is responsible, try without it: [*] "Enable busybox support for lxc-create tool" |
thiscantbeserious:
Device: EspressoBin v5 Non-EMMC
Version: OpenWrt 21.02-SNAPSHOT, r0-bbbc01e
Nailed it down by starting from a fresh config a few times and cleaning up the build-chain.
As soon as I include LXC-Support from make menuconfig -> utilities -> LXC passwd seems broken (encryption?).
LuCi reports that it isn't able to change the password - if I ssh into the box, use passwd it seemingly succeeds (it does set something) but afterwards login fails both via SSH and passwd.
Even if I build without LuCi the same is happening. dmesg shows nothing ... out of the ordinary - despite the Kernel being build with debug-flags.
Any clue how to debug that further? I'm pretty new to building OpenWRT myself.
The text was updated successfully, but these errors were encountered: