Invoking KOReader's Dropbear SSH server from NickelMenu

[elinkser]

Here's something weird:


If I run the Dropbear SSH server from inside KOReader, then exit KOReader, I can connect with an SSH client by password authorization (whether the client is laptop or phone).

But if I run the exact same command to invoke Dropbear as KOReader uses, except from NickelMenu, then I can't connect.

This is my NickelMenu entry for Dropbear, copied from the Telnet entry except using the Dropbear command used by KOReader (according to ps ax):



menu_item :main : Dropbear (toggle) :cmd_output :500:quiet :/usr/bin/pkill -f "dropbear"
chain_success:skip:5
chain_failure :cmd_spawn :quiet :/bin/mount -t devpts | /bin/grep -q /dev/pts || { /bin/mkdir -p /dev/pts && /bin/mount -t devpts devpts /dev/pts; }
chain_success :cmd_spawn :quiet :exec /mnt/onboard/.adds/koreader/dropbear -E -R -p2222 -P /tmp/dropbear_koreader.pid
chain_success :dbg_toast :Started Dropbear server on port 2222
chain_failure :dbg_toast :Error starting Dropbear server on port 2222
chain_always:skip:-1
chain_success :dbg_toast :Stopped Dropbox server on port 2222

[NiLuJe]

Originally Posted by elinkser

the exact same command

No it isn't .

----

Important sidenote: that plugin will not see further work. If you want to run a dropbear version that isn't horribly outdated, use this instead. (It also happens to start the SSHD at boot so you don't have to fiddle with anything, at all).

[elinkser]

Originally Posted by NiLuJe

No it isn't .

Technically I can't argue with that, but it's still weird that from a telnet session command line this works, unlike the NickelMenu invocation:
Start the dropbear server on the Kobo:

#/mnt/onboard/.adds/koreader/dropbear -E -R -p2222 -P /tmp/dropbear_koreader.pid

That said, I can take a hint and move on ,lol. Thanks for the suggestion.

[NiLuJe]

I may have entirely misread your original post and thought that you meant you *could* connect, but it required a password (which would make sense ;p), not that the whole thing just plain didn't work ^^.

The latter would just imply you're doing something wrong in the NM chain.
My usual answer for that is: just write a wrapper shell script and launch that, that'll be quicker than trying to debug a typo/thinko .

[elinkser]

OK that went better.

Running telnet session to Kobo:

# cd /mnt/onboard/.adds/koreader/scripts/

Run "vi mydropbear.sh" to create wrapper script:

#!/bin/sh
export PATH=$PATH:/mnt/onboard/.adds/koreader/scripts
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/mnt/onboard/.adds/koreader/libs
export HOME=/mnt/onboard/.adds/koreader/
cd $HOME
dropbear -E -R -p2222 -P /tmp/dropbear_koreader.pid


* Edit: The PATH's should have custom part at start - see following posts.
However dropbear only needs HOME - see:

https://www.mobileread.com/forums/sh...d.php?t=353810


Re-edit above NickelMenu entry with "vi /mnt/onboard/.adds/nm/config.txt"

menu_item :main : Dropbear (toggle) :cmd_output :500:quiet :/usr/bin/pkill -f "dropbear"
chain_success:skip:5
chain_failure :cmd_spawn :quiet :/bin/mount -t devpts | /bin/grep -q /dev/pts || { /bin/mkdir -p /dev/pts && /bin/mount -t devpts devpts /dev/pts; }
chain_success :cmd_spawn :quiet :sh /mnt/onboard/.adds/koreader/scripts/mydropbear.sh
chain_success :dbg_toast :Started Dropbear server on port 2222
chain_failure :dbg_toast :Error starting Dropbear server on port 2222
chain_always:skip:-1
chain_success :dbg_toast :Stopped Dropbox server on port 2222


Run NickelMenu and select "Dropbear (toggle)"


# ps ax | grep dropbear
1543 root 0:00 dropbear -E -R -p2222 -P /tmp/dropbear_koreader.pid
1554 root 0:00 grep dropbear


On a second terminal on the PC run:

$ ssh root@192.168.2.2 -p 2222
root@192.168.2.2's password:
[root@kobo ~]#
(And we're in!)
[root@kobo ~]# exit
Connection to 192.168.2.2 closed.
$

Run NickelMenu and select "Dropbear (toggle)"


# ps ax | grep dropbear
1558 root 0:00 grep dropbear

[NiLuJe]

Nitpicks:

* You could have shoved the devpts stuff in the script, too .
* The usual idea with the env shenanigans is usually to put custom stuff *first*, not *last*. Right now, it'll load system libs first, which may not be entirely safe.

(This may be a moot point for dropbear as it shouldn't really have a whole lot of things flagged DT_NEEDED, I'm not even sure there's zlib in there ;o)).

[elinkser]

"echo $PATH" in KOReader terminal shows the custom stuff at the end though, so I'm guessing users have to choose between sane conventions and "compatibility mode"?


Fortunately dropbear doesn't seem to care as you point out.
In fact, I commented out both path variables (and prepending the full path to the exec statement) and it still worked.(The reason is left as an exercise for bored users.)

[NiLuJe]

I'm not in a position to check what's doing the PATH shenanigans right now, but, there are valid reasonings to push custom stuff as a *fallback* (i.e., the end) instead of an overload (i.e., *start*).

LD_LIBRARY_PATH though, not so much ;o).

[elinkser]

I think I found it:


[root@kobo koreader]# cat /mnt/onboard/.adds/koreader/plugins/terminal.koplugin/main.lua | grep ENV
C.setenv("ENV", "./plugins/terminal.koplugin/profile", 1)
C.setenv("BASH_ENV", "./plugins/terminal.koplugin/profile", 1)


[root@kobo koreader]# cat /mnt/onboard/.adds/koreader/plugins/terminal.koplugin/profile | grep PATH
PATH="${PATH}:${TERMINAL_DATA}/scripts:${TERMINAL_HOME}/plugins/terminal.koplugin/"
export PATH



Man it is really great how readable KOReader code is.
I already appreciated how it ran on all my different architectures and platforms.
And ran well, and without issues, for me anyway.
Sometimes on slow or quirky platforms.
So many features but without the despised bloat of modern software.
Under free and open license.
Now I look at the code and it is so clean and well commented.

My country and planet are on the road to hell, but KOReader almost brings a tear to my eye!