Remote SSH: Support Linux aarch64

[CedricMi]

Inthe Remote SSH documentation, one can read:
Note: The remote host must be running a 64-bit Linux-based OS.

So I'm trying to connect to an Nvidia Jetson Nano, which comes with Ubuntu 18.04, indeed as 64 bit (aarch64).
After connecting, I get the following error:

 > Server did not start successfully. Full server log:
> 
> /home/cedric/.vscode-remote/bin/473af338e1bd9ad4d9853933da1cd9d5d9e07dc9/server.sh: 12: /home/cedric/.vscode-remote/bin/473af338e1bd9
> ad4d9853933da1cd9d5d9e07dc9/server.sh: /home/cedric/.vscode-remote/bin/473af338e1bd9ad4d9853933da1cd9d5d9e07dc9/node: Exec format err
> or
> 52c7ccec-bc02-4d62-8283-78a5ff0d27a0====
> 
"install" terminal command done
Received install output: 52c7ccec-bc02-4d62-8283-78a5ff0d27a0====
Failed to parse remote port from server output: 52c7ccec-bc02-4d62-8283-78a5ff0d27a0====

Is it because the Jetson Nano isn't x64 or why does it fail?

[kieferrm]

I'd think so. Can you pls post the full server log. Thanks!

[CedricMi]

Didn't know where to find the full log.
I tried again, this time with an SSH configuration file, and get the notification:
Can't connect to cedric-jetson1: unreachable or not Linux x86_64 (Linux aarch64)

So I guess Remote SSH only works with x86_64 ;-)

[wzssyqa]

It's interesting that why there is such limitation.
I met the similar problem with mips64, the OS is Debian.

The log in auth.log is:

May 4 21:50:24 hostname sshd[23763]: Accepted publickey for username from client_ip port 52687 ssh2: RSA SHA256:xxxxxxxxxxxxxxxxxxxx
May 4 21:50:24 hostname sshd[23763]: pam_unix(sshd:session): session opened for user username by (uid=0)
May 4 21:50:24 hostname systemd-logind[379]: New session c15 of user username.
May 4 21:50:24 hostname sshd[23769]: Received disconnect from client_ip port 52687:11: disconnected by user
May 4 21:50:24 hostname sshd[23769]: Disconnected from client_ip port 52687
May 4 21:50:24 hostname sshd[23763]: pam_unix(sshd:session): session closed for user username
May 4 21:50:24 hostname systemd-logind[379]: Removed session c15.

[CedricMi]

OK, then I'll try again.
@Tyriar have you tried with the Jetson Nano ?

[audstanley]

I assume it's not going to work on a Jetson Nano/TX1/TX2 (arm64, i believe, not amd64), or any raspberry pi (arm6, or arm7 depending on the pi). I love where this extra feature is going though. I've got pylint installed on a pi zero, and crossing my fingers for more supported processors. I've got my Jetson Nano on it's way from nvidia, so this is going to make tensorflow SO much easier to work with without needing to bog down my laptop with dependencies.

So far, linting works absolutely amazing on a remote server, without needing to install local dependencies as long as that remote server is x86, or x64.

Suggestion:
A yaml variable would be awesome to support other processors with some basic functionality. I don't feel fully safe using the pony-ssh extension long term, as an update from the open source developer could make the extension HIGHLY unsafe. I prefer depending on MS for ssh key safety. 😊

[blitzvb]

Same here. To connect to a Jetson tx1

[itrishansh]

I am willing to work on this, but not able to find Remote-SSH repo. Is Remote-SSH plugin opensource?

[shawnl]

WHERE IS THE CODE?

[Wunkolo]

Same use case here. Would really like this to work on non-x86 systems. Don't really understand the limitations or bottle necks for this to be so arch-specific. Probably the vscode-server stuff that has to run on the server's end is arch-locked or something.

[shawnl]

@Wunkolo you can do this (and with software libre) by using gvfs-sftp or sshfs, it is just not as fast as it could be because there are multiple round trips. Ibelieve this code does it as a single round trip, which explains why they never got around to implementing it for other arches (although it wouldn't be difficult to just implement it in an interpreter language to avoid that problem.

Anyways this project is non free and this a waste of everyone's rime

[Wunkolo]

I've been using the ssh+sshfs route for quite a while but really appreciated the way this extension did it and allowed me to reach out to all my platforms(development on my beefy servers with i9s and GPUs and xeons, from the comfort of my laptop, with the server doing all the actual intellisense and building and stuff, complete with remote debugging and git and the ability to apply the vscode UX anywhere).

Now realizing that the code itself isn't open to make it happen with little friction is quite a buzzkill now that we're all at the mercy of the priorities of a few select developers and not the community. The people in this thread could have probably implemented it themselves back in May if the source code was open.

[DJMeng]

I also have this problem. I want to connect to jetson tx2 server. but it always is wrong. pls help!

this is my output:

[email protected]
win32 x64
SSH Resolver called for "ssh-remote+7b22686f73744e616d65223a2233375f547832227d", attempt 1
SSH Resolver called for host: 37_Tx2
Setting up SSH remote "37_Tx2"
Using commit id "0f3794b38477eea13fb47fbe15a42798e6129338" and quality "stable" for server
Testing ssh with ssh -V
ssh exited with code: 0
Got stderr from ssh: OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
Install and start server if needed

Unsupported architecture: aarch64
fc99fa04-e4d3-4a4b-942d-ce4c4a7caf65##27##

"install" terminal command done
Received install output: fc99fa04-e4d3-4a4b-942d-ce4c4a7caf65##27##
Unsupported architecture
The remote server architecture is not supported

[Smiling-Robotics]

This seems like a huge issue given the popularity of aarch64 boards with use cases that would benefit from remote ssh, does anyone have any updates on where this issue sits?

[Wunkolo]

Not a lot of communication saying what is being worked on but there are a lot of similar tickets on the very same "non-x86 support" issue. It brings lot of attention on the fact that since this project is closed source we pretty much have to beg for it, when we could have probably done it ourselves and contributed.
The nightly/insider builds seems to have stuff going on but I haven't been able to get any of it working. It does seem to be getting a bit of attention though.
https://twitter.com/joaomoreno/status/1138379435839754240

With the newest line of ARM products that have been coming, the demand is gonna get greater for remote ARM development support.

[suchb]

Same here. To connect to a Jetson tx1

Same here. To connect to a Jetson tx2

[constant5]

Same would love to connect to my TX2 as well. There is ARMv7l Raspbian 8+ (32-bit) support in the experimental release so how hard is an AArch64 build?

[adumont]

+1, having the same issue, Jetson Nano aarm64 :)

[derekwilling]

+1 tried to connect to ubuntu server on rasp pi 3 and got err message
Unsupported architecture: (aarch64)

[voldmr]

+1, same issue when trying to connect to Xilinx Zynq Ultrascale+ (aarch64)

[magic-k]

I asked the developer why armhf and not arm64 and he replied he had no arm64 hardware to test it. I guess he could blindly copy the armhf stuff and rename it to aarch64.

[Wunkolo]

I asked the developer why armhf and not arm64 and he replied he had no arm64 hardware to test it. I guess he could blindly copy the armhf stuff and rename it to aarch64.

Kind of proves that if this was open source we could have done it ourselves months ago.

[adumont]

Shouldn't this be open source? Doesn't make much sense not to be open source honestly... Unless we want to stay behind. And why is this hosted under microsoft/ account here then, if the Dev isn't Microsoft's? El sáb., 10 ago. 2019 19:02, Wunkolo <[email protected]> escribió:

…

I asked the developer why armhf and not arm64 and he replied he had no arm64 hardware to test it. I guess he could blindly copy the armhf stuff and rename it to aarch64. Kind of proves that if this was open source we could have done it ourselves months ago. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#60?email_source=notifications&email_token=AACRLWRAN734CRBDUWNEQCLQD3YA3A5CNFSM4HKTEKJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ARKPY#issuecomment-520164671>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACRLWXSYH2AHDCDM2KDJATQD3YA3ANCNFSM4HKTEKJA> .

[Hades32]

I asked the developer why armhf and not arm64 and he replied he had no arm64 hardware to test it. I guess he could blindly copy the armhf stuff and rename it to aarch64.

No that wouldn't necessarily work because the default libraries that this might have dependencies on have different names between armhf and aarch64.

If someone needs to test aarch64 I guess the easiest thing to do would be to get a VM from scaleway.com where you can rent for a few cents per minute ARM machines (32 and 64 bit)

[magic-k]

arm64 support is on the august milestone

[withforesight000]

arm64 support is on the august milestone

#1135

[mosilver]

how about this issue, the august is ending ...

[suchb]

How is it going? Does remote-ssh support linux arm64 now?

[magic-k]

See #69

[roblourens]

This will be "experimentally" supported, only in Insiders. See #69