tGecko
commented
6 months ago Hi, thanks for the very detailed bug report.
Have you tried connecting without specifying any extra params?
Just using ssh root@192.168.120.43 should work.
The key path is moved to /mnt/SDCARD/.tmp_update/etc/dropbear/ because we don't have write access on /etc/, which lives on spi flash. Does this directory exist on your device?
We use a modified version of dropbear 2022.83 with some changes made to fit the MMP:
Changes made:
- based on dropbear 2022.83
- every user logs in as root
- shell is started as interactive shell to avoid loading of /etc/profile
- for blank password, check the actual submitted password length instead of checking the password hash length
- don't chdir into home directory
- change LD_LIBRARY_PATH
- move ssh keys to /mnt/SDCARD/.tmp_update/etc/dropbear/
nevertheless I will have a look at why connecting with your specified arguments fails.
alexzeitgeist
Checklist
Onions OS Version
4.3.0
Miyoo Firmware Version
202306282128
Provide a clear and concise description of the issue
When attempting to establish an SSH connection, the process fails. The connection is terminated by the server immediately after the SSH2_MSG_KEXINIT exchange, without proceeding to the expected SSH2_MSG_KEX_ECDH_REPLY phase. This issue persists regardless of whether SSH authentication is enabled. Initial troubleshooting steps, including adjustments to the MTU settings on the client side, have not resolved the problem. Further investigation revealed a potential issue related to the creation of temporary host keys by Dropbear.
Steps to Reproduce
Enable SSH in OnionUI, testing both with and without authentication.
From the client side, attempt to connect to the server:
ssh -vvvvvv -oKexAlgorithms=diffie-hellman-group14-sha1 -oHostKeyAlgorithms=ssh-rsa,ssh-dss -p 22 root@192.168.120.43 -m hmac-sha1Observe that the connection is closed by the server right after the key exchange initialization, without proceeding to the key exchange reply phase:
Modify the MTU settings on the client side and attempt to reconnect, observing that the issue persists.
Provide any additional context or information that may help us investigate your issue
I compiled and ran a local instance of dropbear-2022.83 with logging enabled (dropbear -R -F) and attempted to connect again. Same issue as with dropbear in OnionUI. The debug log indicates a failure to create a new temporary file for the host key due to the absence of the /etc/dropbear directory. This results in the connection being terminated before authentication:
Creating the missing /etc/dropbear directory and restarting Dropbear resolves the issue, allowing for successful SSH login. This suggests that a similar directory creation or permissions issue might be present with Dropbear in OnionUI.