Hello,
I am tring to run the “.NET Core Development and Debugging on Torizon Using Visual Studio Code” example and everything seems to be OK except that the application seems stuck after deployment to the target.
I can see the container running in the portainer web interface but I can not reach the break point.
The Debug consol shows the messages below in Visual Studio code. I don’t know why port 32785 is used in the SSH command.
*Démarrage : "ssh" -T -p 32785 -i e:\Software\VisualStudioTorizon\TestApp1\appconfig_0\work\HellowWorld\appconfig_0\id_rsa -o StrictHostKeyChecking=no -o "UserKnownHostsFile /dev/null" torizon@192.168.1.41 "/vsdbg/vsdbg --interpreter=vscode"
Erreur du programme de canal 'ssh' : Warning: Permanently added '[192.168.1.41]:32785' (ECDSA) to the list of known hosts.*
Here is the Torizon Output consol from Visual Studio code
*[03-03 16:48:29.387] Initializing Torizon Extension
[03-03 16:48:41.327] Checking Moses ...
[03-03 16:48:41.327] Backend local instance running on port 5000
[03-03 16:48:48.516] Torizon Backend version 1.0 API version: 1.0
[03-03 16:48:48.516] Checking Docker ...
[03-03 16:48:48.542] Docker version 20.10.2 build 8891c58
[03-03 16:48:48.870] Trying connect to Toradex Apalis iMX6Q/D Module on Apalis Evaluation Board(10496690)
[03-03 16:48:49.357] ARM emulation enabled.
[03-03 16:48:49.774] Active configuration has been selected (2df8dd07-d1fb-4fe4-b2d1-ebc85511ed16), updating it.
[03-03 16:48:49.775] Initializing Torizon .NET application.
[03-03 16:48:51.827] Toradex Apalis iMX6Q/D Module on Apalis Evaluation Board(10496690) connected
[03-03 16:48:51.828] Torizon: all devices refreshed
[03-03 16:48:58.522] Preparing debug environment for .NET core application...
[03-03 16:48:58.523] No preLaunchTask configured.
[03-03 16:48:58.523] Publishing application...
[03-03 16:49:04.214] Selecting device...
[03-03 16:49:04.260] Device 10496690 selected.
[03-03 16:49:04.260] Updating app configuration...
[03-03 16:49:04.310] Deploying image to device (may take a few minutes)...
[03-03 16:49:04.460] Deploying application to device...
[03-03 16:49:04.730] Image on target is already up to date.
[03-03 16:49:06.020] sending incremental file list
[03-03 16:49:06.112] HellowWorld.deps.json
[03-03 16:49:06.115] HellowWorld.runtimeconfig.json
[03-03 16:49:06.138] sent 4,005 bytes received 462 bytes 2,978.00 bytes/sec
[03-03 16:49:06.138] total size is 78,701,193 speedup is 17,618.36
[03-03 16:49:06.249] Restarting application container...
[03-03 16:49:06.650] Stopping current instance...
[03-03 16:49:07.946] running startup script...
[03-03 16:49:07.947] Starting new instance...
[03-03 16:49:10.144] Retrieving container information...
[03-03 16:49:10.400] Ready to start debug session.*
Port number is automatically assigned by the system, usually it starts from 32768, so seems to be in that range.
I see you are using Apalis imx6, did you choose .NET Core 3.1 or 5.0 as platform (later is available only in early access release, if I recall correctly)?
The error adding the IP to list of known host is OK, we actually send those to /dev/null to avoid that two devices with same IP and different keys generate issues.
Which OS are you using for development? Windows or Linux?
Hello,
I have run the command in a command prompt and I got the following error:
ssh: connect to host 192.168.1.41 port 32785: Connection refused
If I replace -p 32785 by -p 22 it works.
Did you try that after you started the debugger? (port number may change).
Since you can connect on the standard SSH port, can you type:
docker ps
here and check the output?
That would help to understand the issue.
Thank you.
Indeed the behaviour is different when the debugger is started.
I get the following messages:
Warning: Permanently added ‘[192.168.1.41]:32769’ (ECDSA) to the list of known hosts.
torizon@192.168.1.41’s password:
Permission denied, please try again.
torizon@192.168.1.41’s password:
Permission denied, please try again.
torizon@192.168.1.41’s password:
torizon@192.168.1.41: Permission denied (publickey,password).
As you can see the password is not recognized. Using the same password with port 22 works.
Here is the output of the docker ps
*CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1f26893a6f97 f7a6089dc57d “/usr/sbin/sshd -D” 6 minutes ago Up 6 minutes 0.0.0.0:32769->2222/tcp hellowworld_arm32v7-dotnet-31_bullseye_debug_e1052a00-9a8d-4cf1-b9e5-70cc05a46692_latest_instance
d2a274ca4d40 torizon/kiosk-mode-browser “/usr/bin/start-brow…” 5 days ago Up 4 days torizon_kiosk_1
5adfdcf0a8a5 torizon/weston “/usr/bin/entry.sh” 5 days ago Up 4 days torizon_weston_1
1be3b5e91ccc portainer/portainer-ce “/portainer --templa…” 5 days ago Up 4 days 8000/tcp, 0.0.0.0:8840->9000/tcp torizon_portainer_1
*
password should not work, since we use the ssh key to authenticate connection with the container. but this seem to not work as expected.
Can you check if the file is there:
e:\Software\VisualStudioTorizon\TestApp1\appconfig_0\work\HellowWorld\appconfig_0\id_rsa
Yes the file is present.
But under the targe home/torizon/authorized_keys file the value are not the same as in the e:\Software\VisualStudioTorizon\TestApp1\appconfig_0\work\HellowWorld\appconfig_0\id_rsa.pub file.
I assume it should have been copies to the target?
I have also seen that the “Port 2222” and “PermitUserEnvironment yes” are not copies in the sshd_config file whereas the DockerFile.debug file should have done it.
Could it be something wrong with the DockerFile.debug?
Did you add the E: drive recently? I think that the ssh command uses WSL and we saw that new drives aren’t mapped automatically there.
Or is that a network drive?
It is not a network drive but a windows virtual drive.
I will try with a project on the C drive and I will let you know what happens.
Good idea!
Then we can try to understand how we can make it work with network drives.
Now I have got this error with the program from C drive:
Démarrage : "ssh" -T -p 32774 -i c:\Software\VisualStudioCode_project\HelloWorld2_dotnet\appconfig_0\id_rsa -o StrictHostKeyChecking=no -o "UserKnownHostsFile /dev/null" torizon@192.168.1.41 "/vsdbg/vsdbg --interpreter=vscode"
Erreur du programme de canal 'ssh' : Warning: Permanently added '[192.168.1.41]:32774' (ECDSA) to the list of known hosts.
Erreur du programme de canal 'ssh' : @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Erreur du programme de canal 'ssh' : @ WARNING: UNPROTECTED PRIVATE KEY FILE! @
Erreur du programme de canal 'ssh' : @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Erreur du programme de canal 'ssh' : Permissions for 'c:\\Software\\VisualStudioCode_project\\HelloWorld2_dotnet\\appconfig_0\\id_rsa' are too open.
Erreur du programme de canal 'ssh' : It is required that your private key files are NOT accessible by others.
Erreur du programme de canal 'ssh' : This private key will be ignored.
Erreur du programme de canal 'ssh' : Load key "c:\\Software\\VisualStudioCode_project\\HelloWorld2_dotnet\\appconfig_0\\id_rsa": bad permissions
Ok, now it seems that permissions for your ssh key aren’t good for the ssh client.
You can check this:
and try to set the file as accessible only by your user.
Which version of the extension are you using? Stable or early access?
Now it works with the correct user rights!
Thank you.
Hello,
I use .NET Core 3.1. May I try with 5.0?
My developement PC runs Windows 10.
I have installed Torizon 5.2.0 (kernel release: 5.4.77-5.2.0-devel+git.bb2267dff284) which is not a production release. DO you think it could be a problem?
I don’t think so, application deployment works.
The difference here is that up to that point the operations are managed by the IDE backend, then it’s handed back to the VSCode debugger, that uses ssh client.
Can you check that you have ssh.exe in your path and that there is no firewall/antivirus blocking that connection?
What happens if you open and command prompt and run:
"ssh" -T -p 32785 -i e:\Software\VisualStudioTorizon\TestApp1\appconfig_0\work\HellowWorld\appconfig_0\id_rsa -o StrictHostKeyChecking=no -o "UserKnownHostsFile /dev/null" torizon@192.168.1.41 "/vsdbg/vsdbg --interpreter=vscode"
Good to know that it’s now solved.
Thanks for the support, @valter.tx!
