Ssh tunnel : permission denied

Thanks, that seemed to work other than producing a few warning messages. There’s a lot of output now in ~/.leaf/wp76-legato_20.04.0-202004151904/build/wp76xx including a .update file but I’m not clear what the purpose of all these files is. I’m assuming to update Legato now we just install the .update file but just wanted to confirm that first, that it’s not the legato.cwe file or something else for example?

Also the OP said he “followed instruction to build legato and update my board” - I can’t find this documented anywhere other than in the KConfig section there’s something about configuring Legato but it doesn’t seem to describe the whole process. Is this documented somewhere else? To complete the Legato customizing process now do we just need to install the .update file produced by make wp76xx?

Thanks.

you should install the legato.cwe

in case you just need the application .update file, you don’t need to do “make wp76xx”, you can use VSCODE to build your application, the binary output will be .update file.

The solution that worked for Kumikomi doesn’t work for us for some reason. So we tried completely disabling SMACK using the menuConfig tool, and with it disabled we lose all internet connectivity. Even pinging doesn’t work. We can establish a cell connection (using cm data connect) so that’s not the issue. Any reason why disabling SMACK would have this effect?

How did you modify for Kumikomi’s solution?

how about adding the script in one of these admin application and rebuild the legato.cwe:

root@swi-mdm9x28-wp:~# grep “admin w” /legato/smack/load2
app.secStore admin w
app.powerMgr admin w
app.dataConnectionService admin w
app.avcService admin w

We modified the file leafWorkspace/leaf-data/current/wp76-legato/framework/daemons/linux/supervisor/app.c adding our application name to the frameworkAppList char* array, then added it as an additional if condition in the section immediately below along with the admin apps. Then rebuilt legato using “make clean” and “make clean wp76xx” from the leaf shell in the $LEGATO_ROOT directory. Then installed the resulting legato.cwe produced in the leafWorkspace/leaf-data/current/wp76-legato/build directory using fwupdate.

The update process seems to work because after this change had no effect, we tried the same process after disabling SMACK using menuConfig and there was indeed a LEGATO_DISABLED file produced in the /legato directory as there’s supposed to be.

Regarding adding a script, what we are trying to do is establish a reverse ssh tunnel directly from our c program using system() (which sounds like more or less the same thing the OP was trying to do, which they got to work apparently).

what did you see on this command after modifying the legato cwe?

root@swi-mdm9x28-wp:~# cat  /legato/smack/load | grep "admin w"
app.secStore admin w
app.powerMgr admin w
app.avcService admin w

After modifying legato.cwe our application is added successfully to the list, but we still can’t create the SSH tunnel from within it. I’m not sure if there’s something in the way we’re using the system function call which is the issue, but it’s just:

system(“ssh -p 12345 -R 23456:localhost:22 sshtest@oururl.com -i /home/root/.ssh/id_rsa”);

The same command works fine when issued manually from the Linux shell. And when we disable SMACK we lose all internet connectivity (though the USB connection still works), so that’s a dead end too and we’re still stumped.

So we’ve tried another route, which is to add the SSH command to a script that’s run from startlegato.sh. The script runs a loop that looks for the presence of a file in a specific directory which is written to by our application, if it finds the file it runs the same SSH command and then deletes the file. This doesn’t work either, the file is being removed so the script is running, but the SSH tunnel is still not created.

Any reason why this automated script method isn’t working? There’s nothing written to any log that I can find or useful information using dmesg. We’ve redirected the script output to a file and there’s no information there either.

Thanks

when you run the script in the startlegato.sh, did you see this?


/home/root/ssh: Warning: failed creating //.ssh: Read-only file system

Host '192.168.2.3' is not in the trusted hosts file.
(ecdsa-sha2-nistp256 fingerprint md5 a8:40:3b:63:0f:da:86:b0:c1:97:54:a3:48:02:88:fc)
Do you want to continue connecting? (y/n)
/home/root/ssh: Connection to owner@192.168.2.3:22 exited: Didn't validate host key

Here I have a script:


root@swi-mdm9x28-wp:~# cat test.sh
echo 123 > /tmp/123.txt
iptables -I INPUT -j ACCEPT
sleep 60
export DROPBEAR_PASSWORD="password"; /home/root/ssh -N -R 60000:localhost:22 owner@192.168.2.3

And in my startegato.sh, I add the following:

      echo "Legato start sequence"

        umount /legato 2>/dev/null
        mount -o bind $LEGATO_MNT /legato

        test -x $LEGATO_START && $LEGATO_START
/home/root/test.sh &

Just don’t know how to add the 192.168.2.3 to the trusted hosts file

When I run the ssh command manually in the shell it works without issue. It doesn’t work when I invoke the same command in our application via a system() call, or when I put it in a script and add the script to startlegato.sh.
The script just has a loop that looks for the presence of a file in /home/root and if it finds it deletes the file, then executes the ssh reverse tunnel command. The script is working because the file gets deleted, but the ssh connection doesn’t work for some reason.

There’s no information as to why using logread, or if I redirect the script output to a disk file. I don’t know where else to look so am completely in the dark, still. And this is the output when checking for “admin w” permissions (our app is called “AVLV1”), so the smack rule has definitely been added:

root@swi-mdm9x28-wp:~# cat /legato/smack/load | grep “admin w”
app.secStore admin w
app.powerMgr admin w
app.avcService admin w
app.AVLV1 admin w

I don’t know if your key has maybe expired or what the issue you’re having is but I don’t get the hosts file error:

root@swi-mdm9x28-wp:~# ssh -p 37424 -R 44304:localhost:22 sshtest@173.34.#.# -i /home/root/.ssh/id_rsa

Host ‘173.34.#.#’ is not in the trusted hosts file.
(ecdsa-sha2-nistp256 fingerprint md5 4e:09:3a:ca:fc:7b:62:c4:89:0e:fc:73:a1:98:11:18)
Do you want to continue connecting? (y/n) y

Microsoft Windows [Version 10.0.19041.1348]
(c) Microsoft Corporation. All rights reserved.

sshtest@OFFICE-HP C:\Users\sshtest>

I only see this “Host ‘192.168.2.3’ is not in the trusted hosts file” warning when I put the command in startlegato.sh, no problem is found when run in console manually.

Did you see the same?

I don’t know where to find error messages or output from startlegato.sh when it runs at startup. There’s nothing available through logread and I don’t know where else to look. Where would I find that?

If I run startlegato manually from the shell, execution hangs and the modem reboots. But if I put the same ssh command in a new script in the etc/init.d directory it works and the reverse tunnel is created.

If I put an ‘&’ at the end of the ssh command line in startlegato.sh so the script doesn’t hang up I get “failed to set raw TTY mode”. Maybe an ssh tunnel can’t normally be created unless an interactive terminal is associated with it? If so I guess there’s a way around that since the original poster had success (assuming they were doing the same thing…)

have you tried to put the system() call of the ssh in one of these admin right app?

root@swi-mdm9x28-wp:~# grep "admin w" /legato/smack/load2 
app.secStore admin w
app.powerMgr admin w
app.dataConnectionService admin w
app.avcService admin w

I’m not sure how/where to safely do that and am trying to solve this without going still further into the weeds :confused: . Also doubt whether there’s any issue with whether I’ve correctly followed Kumikomi’s instructions since our app is now showing with the correct privileges:

root@swi-mdm9x28-wp:~# grep “admin w” /legato/smack/load2
app.secStore admin w
app.powerMgr admin w
app.dataConnectionService admin w
app.avcService admin w
app.AVLV1 admin w

Maybe something is different in our system(ssh…) invocation like the ssh options we’re using, I need to look into that further.

We’ve done that:

root@swi-mdm9x28-wp:~# grep “admin w” /legato/smack/load2
app.secStore admin w
app.powerMgr admin w
app.dataConnectionService admin w
app.avcService admin w
app.AVLV1 admin w

Are you just using a system(ssh…) call from within your unsandboxed application or did you end up doing something else? Would you be able to show me the syntax of the ssh tunneling command you used? Also which version of Legato are you using? And is the only modification to your iptables the iptables -I INPUT -j ACCEPT addition (since setting xattr apparently didn’t work)

Thanks

We’ve done that:

root@swi-mdm9x28-wp:~# grep “admin w” /legato/smack/load2
app.secStore admin w
app.powerMgr admin w
app.dataConnectionService admin w
app.avcService admin w
app.AVLV1 admin w

Are you just using a system(ssh…) call from within your unsandboxed application or did you end up doing something else? Would you be able to show me the syntax of the ssh tunneling command you used? Also which version of Legato are you using? And is the only modification to your iptables the iptables -I INPUT -j ACCEPT addition (since setting xattr apparently didn’t work)

Thanks

Finally got the ssh tunnel working using this method. Turns out we needed to redirect the input ( we used < /dev/ptmx ) when invoking the ssh command through a system() call. However, Legato as we’ve (re)built it turns out to be unstable for some reason as the module is regularly rebooting. It’s not due to the actual change made to smack permissions because if we just rebuild and reinstall Legato using the unmodified source the same rebooting happens. I don’t know why at this point but a couple of things that seem odd are, for one, the legato.cwe produced in the build directory is actually a link to legato-squashfs.ubi.cwe. Also, the size of the legato image produced is much larger than in wp76-image/legato:

dave-k@davek-HP-ProBook-640-G1:~/leafDecember/leaf-data/current/wp76-image/legato$ ls -l legato.cwe
-rw-r–r-- 1 dave-k dave-k 6816544 Nov 15 2020 legato.cwe

dave-k@davek-HP-ProBook-640-G1:~/leafDecember/leaf-data/current/wp76-legato/build/wp76xx$ ls -l legato.cwe
lrwxrwxrwx 1 dave-k dave-k 23 Dec 16 11:20 legato.cwe → legato-squashfs.ubi.cwe
dave-k@davek-HP-ProBook-640-G1:~/leafDecember/leaf-data/current/wp76-legato/build/wp76xx$ ls -l legato-squashfs.ubi.cwe
-rw-rw-r-- 1 dave-k dave-k 8389408 Dec 16 11:20 legato-squashfs.ubi.cwe

There’s nothing obvious in the log that would explain the problem. I don’t know if there’s some additional step(s) needed that we’re missing like maybe including the legato image in an overall spk file containing a complete system, but we’re obviously missing something.

so you just modify framework/daemons/linux/supervisor/app.c to add your application to have admin right in order to call system() for the ssh tunnel?

Yes, we modified it in the two places indicated by Kumikomi, built and installed the modified copy of legato, then in our source code open a reverse SSH tunnel using:

system(“/usr/bin/ssh -p [port] -R 44304:localhost:22 sshtest@[url] -i /home/root/.ssh/id_rsa -I 60 < /dev/ptmx”);

with [port] and [url] replaced obviously by the actual values.

Then from the machine the reverse tunnel is opened on we can connect back to the modem (which has a private IP behind a firewall) using:

ssh root@localhost -p 44304 -i c:\users\sshtest.ssh\id_rsa_sshtest

Which is the scenario we need. However, the Legato produced turns out not to be stable. And as I mentioned, it isn’t the change to legato we made that’s causing the issue since if we build the source code without making any modifications the same thing happens. And strangely the size of the legato.cwe is not the same as what’s in the legato-image directory (i would have assumed it was produced by the same toolset compiled against the same source code).

We tried to isolate in our application what was triggering the rebooting and found that if we stopped using UART flow control it seemed to have an effect (no idea why there would be any dependency) and we thought that had fixed it but all it did is increase the time the units would run before rebooting. So this is obviously not a stable thing to be doing. Why this shouldn’t work (and why the compiled file size is different) I have no idea, don’t know if you have any ideas. I suspect Sierra could answer easily but unfortunately they don’t engage on this forum. And they don’t train their distributors near enough to be much help either, at least not in our experience

Maybe we’re doing something wrong with our UART programming:

uart0_fd = le_tty_Open("/dev/ttyHS0", O_RDWR | O_NOCTTY | O_NDELAY);
if (uart0_fd <0)
{
   LE_ERROR("uart not opened");
   return;
}

ttyInRatePtr = LE_TTY_SPEED_115200;
res = le_tty_SetBaudRate(uart0_fd, ttyInRatePtr);
if (res != LE_OK)
   LE_ERROR("can't set baud rate");

// *************** with SMACK switched off HW flow control causes resetting for some reason

res = le_tty_SetFlowControl(uart0_fd,LE_TTY_FLOW_CONTROL_HARDWARE ); 
if (res != LE_OK)
   LE_ERROR("can't set flow control %d",res);

res = le_tty_SetFraming(uart0_fd,'N',8,1 );
if (res != LE_OK)
   LE_ERROR("can't set framing %d",res);

res = le_tty_SetRaw(uart0_fd,1,1 );
if (res != LE_OK)
   LE_ERROR("can't set raw %d",res);

do you mean if this application without admin right but switching off the UART flow control, there is no reset?
If so, a workaround is that you can use IPC to communicate with the application having admin right and another application without admin right but switching off the UART flow control.

There is no reset in our application, with or without flow control, when using unmodified legato. This is the case with several versions of the wp76xx firmware we tried (including 3, 4 and 5 series). But when we rebuild Legato and use that version the module resets. Even if we just rebuild the source code as is, and don’t modify framework/daemons/linux/supervisor/app.c or anything else, it still resets. This was also consistent over a couple of versions of the wp76xx firmware.

Using the modifed Legato we tried to isolate the source of the resetting, and found it seemed to be associated somehow with code that switched flow control on (it reset soon after). So we tried switching flow control off as a test (even though we need it in our application) and the module still reset, although ran quite a bit longer before it did. We also tried moving the component that has the SSH command into a separate application but it made no difference. Just replacing the legato included in the wp76xx firmware with a modified (any modified) version causes issues. The bottom line is this is apparently not a stable thing to be doing. Maybe it will work for some applciations, but not reliably it seems. The fact that the size of the legato image is different when rebuilding the unmodified source suggests to me something is not right in the basic process, since I would have assumed (maybe incorrectly?) that it should produce exactly the same legato image as what’s in the wp76-image directory.

I suspect the only way to make this work would be to make changes using Yocto, but we’re reluctant to go that route since I think it might just take us further down a rabbit hole and eat up even more resources and time. You’re really on your own with this product, unless probably you’re a large enough customer that Sierra Wireless sells to directly in which case I’m sure they would very happily engage. Forcing customers to rely on distributors for support only works if you train your distributors. What a change vs their previous product Open AT, which we are trying to migrate from (bad mistake) and which was pretty well supported.