Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please support macOS SSH host #24

Closed
jamiewest opened this issue May 2, 2019 · 50 comments
Closed

Please support macOS SSH host #24

jamiewest opened this issue May 2, 2019 · 50 comments
Assignees
Labels
feature-request Request for new features or functionality mac Issue on mac on-testplan ssh Issue in vscode-remote SSH
Milestone

Comments

@jamiewest
Copy link

There are many scenarios where the development stack lives on macos but we have the need to develop locally on windows or linux. Specifically I am thinking of flutter. cc @DanTup

@sharumpe
Copy link

Or: all of my development is done from a Mac, unless I'm working remotely in which case I'm on Windows 10. Thank you for the hope of being able to use VSCode remotely.

@brysgo
Copy link

brysgo commented May 29, 2019

Anyone who is developing a cross platform mobile app needs to test iOS eventually, for anyone who isn't already on a Mac, that means using a mac to get iOS working. Seems like an excellent use case for vscode remote.

@tru
Copy link

tru commented Jun 7, 2019

Is this something that has to be done by the VSCode team itself or what could the open source community help out with?

@DanTup
Copy link

DanTup commented Jun 7, 2019

It doesn't seem like the extensions are open source (see https://code.visualstudio.com/docs/remote/faq#_license-and-privacy), so that might limit what the community can do.

It's not clear to me what the limitation is though.. currently connecting to macOS reports it's "not Linux x86_64" so it seems like a deliberate check, but I'm not sure what the significant difference is that prevents it from working (as I understand it, a lot of the code that runs the extension host already runs on Mac in a non-remote session).

@lwshang
Copy link

lwshang commented Jun 10, 2019

I have an iMac for work in office and a MacBook for personal use in home. It'll be great to use vscode to edit files on the other mac remotely. Just another use case for your interests.

@yuhr
Copy link

yuhr commented Jun 11, 2019

This is must be

@jpike88
Copy link

jpike88 commented Jun 19, 2019

@roblourens could you provide an explanation as to why this issue isn't getting a clear response?

As far as I can tell, osx support shouldn't be difficult. What kind of blockers would make this not just something that was done alongside Linux?

@JtMotoX
Copy link

JtMotoX commented Jun 19, 2019

@roblourens could you provide an explanation as to why this issue isn't getting a clear response?

As far as I can tell, osx support shouldn't be difficult. What kind of blockers would make this not just something that was done alongside Linux?

This Remote Development feature runs client-side AND server-side processes. There is client-side support for Windows, Mac, and Linux. The server-side code (link below) is only compatible with Linux. I'm sure once they have worked out all the bugs then they will also offer a Mac and Windows version of vscode-server, which I hope is soon, but it's not as simple as removing a "blocker" that they put in there just to annoy us.

https://update.code.visualstudio.com/commit:553cfb2c2205db5f15f3ee8395bbd5cf066d357d/server-linux-x64/stable

@cuibonobo
Copy link

As an update to this issue, I recently tried to connect to a remote Mac and the installer seemed to make an attempt, but ultimately failed because the sed command works differently on Macs.

Here's my log output:

[18:27:34.931] remote-ssh@0.45.5
[18:27:34.931] win32 x64
[18:27:34.932] SSH Resolver called for "ssh-remote+mac", attempt 1
[18:27:34.932] SSH Resolver called for host: mac
[18:27:34.932] Setting up SSH remote "mac"
[18:27:34.945] Using commit id "036a6b1d3ac84e5ca96a17a44e63a87971f8fcc8" and quality "stable" for server
[18:27:34.948] Testing ssh with ssh -V
[18:27:34.983] ssh exited with code: 0
[18:27:34.983] Got stderr from ssh: OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.4
[18:27:34.983] Running script with connection command: ssh -o ClearAllForwardings=true mac bash
[18:27:34.984] Install and start server if needed
[18:27:35.110] > 
[18:27:35.110] Got some output, clearing connection timeout
[18:27:35.322] > Running remote connection script
> sed: 1: "s/^linux //gi": bad flag in substitute command: 'i'
> Unsupported architecture:
> 0d6e33fa-7e6c-40cb-8985-9877bb252cd5##27##
> 
[18:27:35.323] Received install output: 0d6e33fa-7e6c-40cb-8985-9877bb252cd5##27##
[18:27:35.323] Unsupported architecture
[18:27:35.323] The remote server architecture is not supported
[18:27:35.323] TELEMETRY: {"eventName":"resolver","properties":{"outcome":"failure","reason":"ExitCode"},"measures":{"resolveAttempts":1,"exitCode":27,"retries":1}}
[18:27:35.323] ------




[18:27:35.589] "install" terminal command done
[18:27:35.589] Install terminal quit with output: 

@Hultner
Copy link

Hultner commented Aug 14, 2019 via email

@JtMotoX
Copy link

JtMotoX commented Aug 15, 2019

Hmm interesting, you can install the GNU (Linux) version of sed and other core-utilities via homebrew and add them as the highest prioritised binary in your path, have you tried this?

@Hultner I just tried this and it was able to get past that sed error but still getting errors. See outputs below.

Windows Client:

Gets a "bash) was unexpected at this time" which is a windows error so I am guessing my windows client is trying to execute bash which doesn't work (even though I have WSL installed). This is the same output mentioned in #1137

Mac Client:

Does not get the bash error above because bash does exist on mac, although I get a "Unsupported architecture: Darwin x86_64". Even if windows did not have the bash error it would throw this Darwin not supported error as well.

[01:38:48.909] remote-ssh@0.45.5
[01:38:48.909] darwin x64
[01:38:48.909] SSH Resolver called for "ssh-remote+macbook_local", attempt 1
[01:38:48.909] SSH Resolver called for host: macbook_local
[01:38:48.909] Setting up SSH remote "macbook_local"
[01:38:48.912] Using commit id "036a6b1d3ac84e5ca96a17a44e63a87971f8fcc8" and quality "stable" for server
[01:38:48.914] Testing ssh with ssh -V
[01:38:48.928] ssh exited with code: 0
[01:38:48.928] Got stderr from ssh: OpenSSH_7.9p1, LibreSSL 2.7.3
[01:38:48.929] Running script with connection command: ssh -o ClearAllForwardings=true -o ConnectTimeout=15 macbook_local bash
[01:38:48.929] Install and start server if needed
[01:38:49.616] > Warning: Permanently added '192.168.168.161' (ECDSA) to the list of known hosts.
[01:38:49.616] Got some output, clearing connection timeout
[01:38:50.863] > Running remote connection script
[01:38:50.880] > Unsupported architecture: Darwin x86_64
[01:38:50.880] Received install output: b7f4d0ff-58d1-442d-9e4d-95da4f89a8f9##27##
[01:38:50.880] Unsupported architecture
[01:38:50.881] The remote server architecture is not supported
[01:38:50.881] TELEMETRY: {"eventName":"resolver","properties":{"outcome":"failure","reason":"ExitCode"},"measures":{"resolveAttempts":1,"exitCode":27,"retries":1}}
[01:38:50.881] ------
[01:38:51.147] "install" terminal command done
[01:38:51.148] Install terminal quit with output:

@JtMotoX
Copy link

JtMotoX commented Aug 15, 2019

In case anyone was wondering, the script that executes on the remote system that performs the install and provides the logs that you see when you are connecting is located on the client (see below). Each time you attempt a connection it creates a new sh file with a random id. This shell script is not compatible with mac, neither is the vscode-server binaries that the script downloads. We will just have to wait until they release a MS & Mac version of this script and binaries.

Example:
%localappdata%\Temp\vscode-linux-multi-line-command-macbook_local-926166174.sh

Short Snip:

ARCH=$(uname -sm | sed 's/^linux //gi')

case $ARCH in
	x86_64) VSCODE_ARCH="x64";;
	armv7l)
		
			echo "$ARCH is only supported when running VS Code Insiders"
			echo "ae30ce89-4710-42e6-a7c5-1d03ddb58d75##29##"
			exit 0
		
		;;
	*)
		echo "Unsupported architecture: $ARCH"
		echo "ae30ce89-4710-42e6-a7c5-1d03ddb58d75##27##"
		exit 0
		;;
esac

@mikehardy
Copy link

Doesn't look like it's in the current iteration plan #1135

...but maybe with some luck it will show up for the September iteration plan.

My use case is similar to a commenter above - react-native (multi-platform mobile) development where most dev is on PC host (for the cheaper laptop horsepower) with just polishing/build checks done on less-capable macOS machines. I know a lot of people even rent machines on e.g. MacStadium to implement a similar workflow, and it could be useful for Xamarin devs too if macOS was a valid host target. I'll keep my fingers crossed it gets priority. Cheers

@Yelloow
Copy link

Yelloow commented Nov 17, 2019

I am grateful for all the of the workarounds that have been suggested here but has there been any word if this is being looked at officially? I would hate to see this thread locked with no response.

@Hultner
Copy link

Hultner commented Nov 19, 2019

@kieferrm This is currently the most voted issue in the whole repo by a far margin (>2.5x to the 2nd). Please consider it when making the December iteration plan, or at least make an official statement instead of leaving us hanging.

@arnavs
Copy link

arnavs commented Nov 19, 2019

I emailed the assignee for this issue a few days ago. Haven't heard anything back.

@rgov
Copy link

rgov commented Nov 19, 2019

The VS Code developers are undoubtedly aware of the community's interest in this, and unfortunately it does not seem that pinging, e-mailing, or posting further +1 comments will do anything but irritate the developers, whom we should empathize with as developers ourselves.

Ultimately, if they had wanted to respond they would have, so the official statement appears to be "no comment," and I would speculate that this policy is not an engineering decision. The Remote extension is unusual in that it is not open source and comes with a separate license restricting how it can be used, so there are clearly other factors involved behind the scenes besides what the community desires. [Edit: See long-awaited official reply below.]

@Chuxel
Copy link
Member

Chuxel commented Nov 19, 2019

As @rgov says, we are definitely listening, the requests are clear, and we really appreciate the excitement from all of the different communities that have made requests! So, the response is, "thank you, and we absolutely hear you!" Absolutely keep up-voting - it is a core part of our planning process, and we'll let you know when we pick the issue up. As with the microsoft/vscode repo, once we understand an issue, we watch 👍 reactions across issues to understand interest rather than individual responses due to the sheer volume of them that comes across.

This repository follows the same planning process as VS Code. We plan month-by-month, and our primary way of communicating updates for well understood issues is through iteration plans and an issue getting added into a milestone for that iteration.

Last iteration was an "issue grooming" iteration that is done periodically (including in microsoft/vscode) to make sure we have a clear picture of the product and fix critical issues that we missed. This issue was not closed during this period exactly because it is something we want to look into as we move forward.

This month is impacted by the holidays and conferences as is the next, so our progress is a bit slowed. Please bear with us as we continue to stabilize and grow the extensions during preview.

Each platform we've supported has brought with it some unique issues particularly in the area of extensions. Many extensions either directly include native code or indirectly through Node modules. Some of this native code only runs on one platform which can cause extensions to break on one platform but not another . A few (examples) (of) (problems) are in the extension guide. So, we'd want to be sure we can commit to doing the needed testing and support during the iteration before picking it up.

For SSH, we started with the most common server targets and then expanded into ARM devices given the huge interest in them - this was a direct reaction to community input. We've closed many of these issues so macOS is now at the top of the community request list. However, we also want to be sure we've stabilized the platforms that are supported before adding others, so that is why you are seeing other things get picked up in some cases.

Hopefully that helps answer some of the questions here. Thanks again!

@sharumpe
Copy link

Thanks for the response and explanation, that was very helpful!

@Hultner
Copy link

Hultner commented Nov 19, 2019

As @rgov says, we are definitely listening, the requests are clear, and we really appreciate the excitement from all of the different communities that have made requests! So, the response is, "thank you, and we absolutely hear you!" Absolutely keep up-voting - it is a core part of our planning process, and we'll let you know when we pick the issue up. As with the microsoft/vscode repo, once we understand an issue, we watch 👍 reactions across issues to understand interest rather than individual responses due to the sheer volume of them that comes across.

This repository follows the same planning process as VS Code. We plan month-by-month, and our primary way of communicating updates for well understood issues is through iteration plans and an issue getting added into a milestone for that iteration.

Last iteration was an "issue grooming" iteration that is done periodically (including in microsoft/vscode) to make sure we have a clear picture of the product and fix critical issues that we missed. This issue was not closed during this period exactly because it is something we want to look into as we move forward.

This month is impacted by the holidays and conferences as is the next, so our progress is a bit slowed. Please bear with us as we continue to stabilize and grow the extensions during preview.

Each platform we've supported has brought with it some unique issues particularly in the area of extensions. Many extensions either directly include native code or indirectly through Node modules. Some of this native code only runs on one platform which can cause extensions to break on one platform but not another . A few (examples) (of) (problems) are in the extension guide. So, we'd want to be sure we can commit to doing the needed testing and support during the iteration before picking it up.

For SSH, we started with the most common server targets and then expanded into ARM devices given the huge interest in them - this was a direct reaction to community input. We've closed many of these issues so macOS is now at the top of the community request list. However, we also want to be sure we've stabilized the platforms that are supported before adding others, so that is why you are seeing other things get picked up in some cases.

Hopefully that helps answer some of the questions here. Thanks again!

Thanks!
The answer is highly appreciated and provides great insight as to why this haven’t been prioritized. The development team is doing great work here, and we love the product you are delivering.

@DanielSmith
Copy link

DanielSmith commented Nov 20, 2019

Daniel here - I was one of the folks suggesting the hackish workaround of using Docker on macOS, as a sort of shim/connection point for VS Code. As @Hultner and others point out, supporting the server side endpoint isnt just a simple shell script (the community would have figured that out a long time ago).

Thanks to @jnovack and others that posted an implementation / instructions on how to use Docker as a go-between. In a way, it gives MS a little breathing room, as there is a workaround for the short term. If you need to edit on macOS as a server side endpoint, it's worth checking out, as long as you are ok with the caveats (we're just making VS Code happy, because it wants to connect to a Linux OpenSSH, and we use Docker to mount a macOS filesystem) Cheers!

@WellspringCS
Copy link

Look guys, I've been waiting patiently for this feature since way back in the 2010's

And here I am, a decade later, still waiting.

(Had to say that)

🎉🎉🎉🎉

@mariosanchez23
Copy link

still waiting for this 👎

@DanTup
Copy link

DanTup commented Jan 16, 2020

It's not as straight forward, but FWIW depending on your needs you can use VS Online's "self-host" setup to somewhat achieve this with some caveats:

https://docs.microsoft.com/en-gb/visualstudio/online/how-to/vscode#self-hosted

You register the Mac as a VS Online "environment" and then from another machine (eg. Windows) you connect VS Code to that Online environment. It requires an Azure account and I think it's all proxied through Azure - but as far as I can tell it's completely free (as long as you're using your own attached environment, and not spawning up an Azure machine).

It's a bit quirky (for ex. you have to have installed and launched VS Code on the Mac), but doing this I was able to launch Flutter apps on a simulator running on the Mac (I have no reason to believe it won't work with a physical iPhone, but don't have one to test) from Windows (including VS Code on Windows showing the iPhone Simulator as the selected Flutter device).

@FrobtheBuilder
Copy link

@DanTup's solution works, pretty well in fact as there seems to be feature parity with remote SSH. The only caveat is the latency which is pretty bad since the connection is being routed through Microsoft's infrastructure, it makes using the integrated terminal pretty frustrating. Otherwise, it's quite usable. Thanks!

@roblourens
Copy link
Member

This now works in the Remote-SSH Nightly extension. Please try it out! I do have some more testing to do but it should basically work.

@roblourens roblourens added this to the February 2020 milestone Feb 17, 2020
@jamiewest
Copy link
Author

Thank you!

@yueyericardo
Copy link

yueyericardo commented Feb 17, 2020

THANKS!!!!!
It's working.

FYI
Download VS Code Insider.
Then search Extenstion Remote - SSH (Nightly)

image

jnovack added a commit to jnovack/docker-vscode-hack-osx that referenced this issue Feb 24, 2020
[Issue 24](microsoft/vscode-remote-release#24) has been closed
upstream with a work-around until official mainstream support.  I am archiving this repository
for posterity.  I am no longer accepting issues or pull-requests since official support will
be provided.  Please support the original developers.
@slu216
Copy link

slu216 commented Mar 9, 2020

Hi,
Has anyone tried out this new feature with v1.43 for macOS host?
I am seeing error about something like this (I replace the directory path by $HOME)

[15:55:27.345] > Server did not start successfully. Full server log at _$HOME_/.vscode-server/.78a4c91400152c0f27ba4d363eb56d2835f9903a.log >>>
[15:55:27.349] > _$HOME_/.vscode-server/bin/78a4c91400152c0f27ba4d363eb56d2835f9903a/server.sh: line 12: 22345 Killed: 9               "$ROOT/node" ${INSPECT:-} "$ROOT/out/vs/server/main.js" "$@"
> <<< End of server log
> 87e8cfe4172e##32##
[15:55:27.350] Received install output: 87e8cfe4172e##32##
[15:55:27.351] Terminating local server
[15:55:27.352] Resolver error: The VS Code Server failed to start
[15:55:27.362] ------

@brucejo75
Copy link

I just set up remote ssh with v1.43. All is working as expected for me! Yay.

@david02871
Copy link

Could someone point me to instructions on how to set up a MacOS SSH host and connect with VSCode?
This was announced in the February release but the documentation still says a MacOS SSH server is "Not supported yet."

https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-server

@brucejo75
Copy link

I followed the directions here.

For the mac server just enable remote login, that automatically starts up the SSH server.

https://www.booleanworld.com/access-mac-ssh-remote-login/

@roblourens
Copy link
Member

Docs are getting updated - sorry about that and yes, thanks @brucejo75

@vscodebot vscodebot bot locked and limited conversation to collaborators Apr 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature-request Request for new features or functionality mac Issue on mac on-testplan ssh Issue in vscode-remote SSH
Projects
None yet
Development

No branches or pull requests