Problem deploy container for debug

Hi all

I’m trying to run a simple Hello Word in .NET Core with VS Code to a Colibri imx6s with the latest Torizon.

I have attached the terminal output from the Colibri module.link text

With my own application

When I try to deploy the container (task deploydebugcontainer) VS Code stalls when I have entered the target password.
(See the attached picture)alt text

I have changed the targetSSHPort to 22. There are no SSH connection to the Colibri module on 8023 used as the default in the settings.json file in the guide.
It tried with Putty and SSH works on port 22, not on 8023. Or is the port 8023 required? (It may be blocked on the network)

Using the Serial sample application

When i try the same with the Serial sample I get a little bit different result.
I can build it, but when I deploy I get this:

*…

app/serial.runtimeconfig.json
sent 32,715,833 bytes received 3,687 bytes 2,256,518.62 bytes/sec
total size is 78,369,134 speedup is 2.40
Terminal will be reused by tasks, press any key to close it.

Executing task: ssh torizon@10.45.9.95 ‘docker stop serial-dbg ; docker run -d --rm --name serial-dbg -p 22:22 -v $(pwd)/app:/app dotnetcoredbg:latest’ <
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:Q2OHtIveJHPPqehXGdnjP4Vc/1se991WJvzAifPIGRQ.
Please contact your system administrator.
Add correct host key in C:\Users\dksgdtjo/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in C:\Users\dksgdtjo/.ssh/known_hosts:1
ECDSA host key for 10.45.9.95 has changed and you have requested strict checking.
Host key verification failed.
The terminal process terminated with exit code: 255*

Any idea what I did wrong?

Greetings @TJO,

I can’t quite recreate this on my side, but from your errors here it seems that the ssh connection is having an error due to the ssh configuration changing or something similar. I don’t believe port 8203 is a hard requirement but I’ll check on that internally.

Can you try wiping the entry for 10.45.9.95 from your know_hosts file and then retrying the ssh connection. As the last error suggest that the host key/identification has changed and doesn’t match the entry your PC has for this device. Wiping the entry manually should get rid of this error.

Best Regards,
Jeremias

Hi

I’m not that experienced with Linux yet, so how do I wipe the data in that file? Is it on the WSL image?

Thomas

Hi

I removed the know_hosts on the WSL Ubunto image
I than tried with the Serial sample again. I did come a bit further.

After the “task deploydebugcontainer” I got the docker image on the module:

*colibri-imx6-05127328:~$ hostname -i
10.45.9.95 172.17.0.1
colibri-imx6-05127328:~$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED                  SIZE
dotnetcoredbg       latest              e6bd0aeca7c6        Less than a second ago   338MB
colibri-imx6-05127328:~$*

But when I start the debugger i still get this: " The preLaunchTask ‘prepareuserkey’ terminated with exit code 127"

When I select ‘Debug Anyway’ I get this:

Starting: "ssh" -p 22 -i ../../containers/dotnetcoredbg/id_rsa -oStrictHostKeyChecking=no root@10.45.9.95 "/root/vsdbg/vsdbg --interpreter=vscode"
Error from pipe program 'ssh': @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Error from pipe program 'ssh': @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
Error from pipe program 'ssh': @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Error from pipe program 'ssh': IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Error from pipe program 'ssh': Someone could be eavesdropping on you right now (man-in-the-middle attack)!
Error from pipe program 'ssh': It is also possible that a host key has just been changed.
Error from pipe program 'ssh': The fingerprint for the ECDSA key sent by the remote host is
Error from pipe program 'ssh': SHA256:Q2OHtIveJHPPqehXGdnjP4Vc/1se991WJvzAifPIGRQ.
Error from pipe program 'ssh': Please contact your system administrator.
Error from pipe program 'ssh': Add correct host key in C:\\Users\\dksgdtjo/.ssh/known_hosts to get rid of this message.
Error from pipe program 'ssh': Offending ECDSA key in C:\\Users\\dksgdtjo/.ssh/known_hosts:1
Error from pipe program 'ssh': Password authentication is disabled to avoid man-in-the-middle attacks.
Error from pipe program 'ssh': Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Error from pipe program 'ssh': root@10.45.9.95: Permission denied (publickey,password).

Hi @TJO,

First of all, apologies I wasn’t clear I meant the known_hosts file on the Windows itself. On Windows this can usually be found under your user folder in the .ssh folder.

Next, I took a second look at your initial post and the contents of settings.json in the picture you shared isn’t the default for what gets setup by our extension. Where did you get these new contents? Also what documentation (if any) have you been referencing? It may be possible there is still some legacy documentation on our developer site that isn’t applicable to the current state of our extension.

Best Regards,
Jeremias

HI

I have been using this guide: https://developer.toradex.com/knowledge-base/net-core-development-and-debugging-on-torizon-using-visual-studio-code

As I can see, my settings.json matchs the one in the guide, except for me using port number 22 for SSH?

I have cleared the “known_hosts” file and tried again. I did get the container deployed but no debug

*colibri-imx6-05127328:~$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED                  SIZE
dotnetcoredbg       latest              e6bd0aeca7c6        Less than a second ago   338MB
colibri-imx6-05127328:~$ c*

Then I start the debugger and get this:

*Executing task: ssh torizon@10.45.9.103 'docker stop MyTestApp-dbg ; docker run -d --rm --name MyTestApp-dbg -p 22:22 -v $(pwd)/app:/app   dotnetcoredbg:latest' <

torizon@10.45.9.103's password:
sh: docker stop MyTestApp-dbg ; docker run -d --rm --name MyTestApp-dbg -p 22:22 -v $(pwd)/app:/app dotnetcoredbg:latest: No such file or directory
The terminal process terminated with exit code: 127

Terminal will be reused by tasks, press any key to close it.

Do you have a working sample? The Serial sample does the same.
I may need som basic understanding of the debug environment.

1: What is the WSL used for in the build/deploy/debug tasks?
2: The connection between VSCode and the device (Torizon.Deetct…) is for deploying only?
3: Is the settings.json just for debugging?

And i also get this from time to time in the terminal:

*Colibri-imx6-05127328 login: [  169.112723] Out of memory: Killed process 837 (docker) total-vm:897564kB, anon-rss:23196kB, file-rss:1464kB, shmem-rss:0kB, UID:1220 pgtables:78kB oom_score_adj:0

colibri-imx6-05127328 login:*

That document you’ve been referencing is outdated and was created in a time before we even had the current iteration of the Visual Studio Code extension.

Updated documentation is currently in the works and is being reviewed for publishing.

It seems the issues you’re experiencing are due to mixing the instructions in this outdated article with current extension. It’d probably be easier to start from scratch rather than trying to undo your changes.

For the time being I’d suggest loosely following the article here: https://developer.toradex.com/knowledge-base/python-development-and-debugging-on-torizon-using-visual-studio-code

It’s for Python but it still uses the same Visual Studio Code extension. The article will give you a rough idea of how the extension is supposed to be used as the workflow and commands are very similar for .Net Core.

I was told we’d soon have an updated .Net Core article, so I’ll make sure to let you know here when that gets published. Apologies for the inconvenience.

As for your other questions:

  • WSL is used to perform some utilities like SSH/rsync, which while possible on Windows is made easier with WSL especially when targeting a Linux platform like Torizon. For more info see here: https://developer.toradex.com/knowledge-base/visual-studio-code-development-extension-pythonnet-core#Install_the_Windows_Subsystem_for_Linux_WSL2

  • The device connection should be for anything where the extension needs to reach out/connect to the device. (i.e. debugging, deploying, etc.)

  • As I said above your settings.json is strange since you followed the outdated article. In the current iteration of the extension this file is no longer used for configuration and should really not be modified. As an example when I create a fresh .Net Core application using the extension the settings.json looks like this:

    {
    “torizon.appfolder”: “appconfig_0”
    }

Finally your memory issue is probably due to too many containers running on your module. You will need to clean the containers/container images up from time to time when developing. As a side note since you are using the iMX6S you’ll need to be conscious of your container size and usage as to not run into memory/storage issues down the road.

Best Regards,
Jeremias

Hi

I will try it asap and let you know how it goes.

Regarding WSL:

It is currently not possible for me to use WSL2. We do not have the needed update of WIndows10 to use it. We are under strict control by the IT department in Germany. Even the Micorsoft Store is closed for us and is not usable in Windows. I had to download the required Ubunto image for WSL manually at install it using power shell.

Is WSL 2 required for it to work or is WSL1 sufficient?

Thomas

I believe at the moment WSL should be sufficient. Currently I don’t believe we use any WSL2 exclusive features in our extension. WSL2 is nice for users who only have Windows Home edition as it lets them install Docker Desktop using the WSL2 backend.

However, I will double-check and comment here if I learn otherwise.

Best Regards,
Jeremias

Hi

I have used the Phyton guide to make a .NET Core project.
Everything seems ok until the debuuger is ready t start. The last entry is just “Ready to start debug session”

It do not hit my break point but the session seems to run.
See the attached image

This is from the Debug Console:

Starting: “ssh” -T -p 32768 -i c:\Work\NetCoreDev\MyHelloWorld\MyHalloWorld\appconfig_0\id_rsa -o StrictHostKeyChecking=no -o “UserKnownHostsFile /dev/null” torizon@colibri-imx6-05127328 “/vsdbg/vsdbg --interpreter=vscode”
Error from pipe program ‘ssh’: Warning: Permanently added ‘[colibri-imx6-05127328]:32768,[10.45.9.110]:32768’ (ECDSA) to the list of known hosts.
Error from pipe program ‘ssh’: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Error from pipe program ‘ssh’: @ WARNING: UNPROTECTED PRIVATE KEY FILE! @
Error from pipe program ‘ssh’: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Error from pipe program ‘ssh’: Permissions for ‘c:\Work\NetCoreDev\MyHelloWorld\MyHalloWorld\appconfig_0\id_rsa’ are too open.
Error from pipe program ‘ssh’: It is required that your private key files are NOT accessible by others.
Error from pipe program ‘ssh’: This private key will be ignored.
Error from pipe program ‘ssh’: Load key “c:\Work\NetCoreDev\MyHelloWorld\MyHalloWorld\appconfig_0\id_rsa”: bad permissions

I do not know if this means anything?

Deployed containers:

colibri-imx6-05127328:~$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
arm32v7-debian-dotnet_buster_49f3450c-0000-45b6-b7dc-8a35e8bda515_debug latest 1ae9bb62df97 Less than a second ago 326MB
dotnetcoredbg latest e6bd0aeca7c6 Less than a second ago 338MB
colibri-imx6-05127328:~$

Between this and the previous SSH related errors I’m starting to think that perhaps you have some kind of non-standard SSH permissions/configurations on this Windows machine.

I found a similar error here and a possible fix: https://superuser.com/questions/1296024/windows-ssh-permissions-for-private-key-are-too-open

In the meantime I’m trying to recreate this on my end with no success.

Best Regards,
Jeremias

Hi Jeremias,

Thanks, that did do it. I used the first solution by giving my user the ownership and removed every other user.

Maybe it would be a could idea to add this to any future guides. I’m probably not the last person getting these issues?

Thomas

Glad we were able to resolve this issue. I’ll make note of this for future reference.