Vscode-remote-release: Please support macOS SSH host

[jamiewest]

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]

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]

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]

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

[DanTup]

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]

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]

This is must be

[jpike88]

@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]

@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]

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] [email protected]
[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]

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?

On Wed, Aug 14, 2019 at 8:44 PM Jen Garcia [e-mail] wrote:

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] [email protected]
[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:

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-remote-release/issues/24?email_source=notifications&email_token=AAULT2RLBZLUCUEWLQVJ3STQERHAPA5CNFSM4HKIOKH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4JXNOA#issuecomment-521369272,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAULT2WNF6UEHOX25GTFNULQERHAPANCNFSM4HKIOKHQ
.

--
Med vänlig hälsning
Alexander Hultnér

[JtMotoX]

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 https://github.com/microsoft/vscode-remote-release/issues/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] [email protected]
[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]

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]

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

[themdrnsamurai]

+1 for making this a priority. This would be a HUGE win.

[sjdweb]

Looks like it's not in September's iteration plan either #1390
Windows support for SSH is listed though, so maybe October is macOS' month? 🙏

My personal use case is a beefy machine running macOS at home that I can connect to from anywhere (ZeroTier ftw). Would be great to be able to use a lightweight machine while out.

[Hultner]

I have the same use case as @sjdweb, right now running my clients stack alongside VSCode on my 13" MBP (16GB ram) slows it to a crawl, vi works fine though. While I do have a 8c16t, 128GB ram Mac at home, being able to leverage the power of this machine on the go in the same way I can with mosh/ssh+tmux+vi would be a true killer feature for VSCode, especially combined with xcode builds for native iOS apps.

[rgov]

There are only minor changes required to the install script. The Node modules all already support macOS as far as I can tell (they are part of the main VS Code.app bundle). Unfortunately, some part of the remote development server still expects on Linux (it fails to enable extensions), so we will have to wait for Microsoft to prioritize it. I don't think it would be a lot of work.

[remi-livescale]

Hello, Could you please make this as a priority ? Thanks ! <3

[arnavs]

Is there any we could prod them to work on this? Maybe donate $ to the development effort or something?

[effolkronium]

Just do it

[rengui]

not in Oct. iteration plan #1661 either 😞

[eugene-yang]

I would really like to see this implemented.
I use this more like a remote workspace instead of a deployment tool.
My main work machine is a mac back my laptop is a windows.
It would be great if I can directly connect to my work machine using VSCode!

[DanielSmith]

there is a really hackish workaround.. hopefully it makes the VSCode team wince enough to fix this ;)

Create an Ubuntu Docker container on the Mac, install openssh in that, expose a port on the macOS host (pfctl) so that you can log in remote... you can mount a host filesystem in the container.

A bit ugly, but it works because VSCode is talking to Linux, and you leverage the fact that Docker can bind a local macOS fs.

[JtMotoX]

there is a really hackish workaround.. hopefully it makes the VSCode team wince enough to fix this ;)

Create an Ubuntu Docker container on the Mac, install openssh in that, expose a port on the macOS host (pfctl) so that you can log in remote... you can mount a host filesystem in the container.

A bit ugly, but it works because VSCode is talking to Linux, and you leverage the fact that Docker can bind a local macOS fs.

@DanielSmith This is exactly what I have been doing the past few months.

[Hultner]

there is a really hackish workaround.. hopefully it makes the VSCode team wince enough to fix this ;)

Create an Ubuntu Docker container on the Mac, install openssh in that, expose a port on the macOS host (pfctl) so that you can log in remote... you can mount a host filesystem in the container.

A bit ugly, but it works because VSCode is talking to Linux, and you leverage the fact that Docker can bind a local macOS fs.

Yeah I've been doing this as well but it's not that great since I can't debug applications running on macos etc so I might add well just use vi then. Been looking at Coder though, it's server runs on macos and let's you access VSCode via any browser https://github.com/cdr/code-server

Might be a better solution for now since VSCode remote doesn't seem very interested in adding mac support.

[JtMotoX]

Yeah I've been doing this as well but it's not that great since I can't debug applications running on macos etc so I might add well just use vi then. Been looking at Coder though, it's server runs on macos and let's you access VSCode via any browser https://github.com/cdr/code-server

Might be a better solution for now since VSCode remote doesn't seem very interested in adding mac support.

I have switched to code-server about 2 weeks ago. They have a new stable V2 which is much improved over V1. I wrote a script that downloads the latest stable version, synchronizes my local settings and packages, then runs it. I can then connect from from my browser from anywhere and it looks and feels exactly like my local setup. The downside is that you cannot change any settings or install any packages from my browser(code-server). I must do that on my local vsc and then re-run my script which will re-sync my local settings and packages to code-server.

Short snip of my ./start-code-server.sh script.

# 110 lines redacted so I don't flood this thread.  Essentially it sets some vars, stops code-server if currently running, checks the current version of code-server, checks the latest stable version, downloads latest stable version if newer than current version.

DATADIR=~/.local/share/code-server/data
EXTDIR=~/.local/share/code-server/extensions
EXTBUILTINDIR=~/.local/share/code-server/extensions-builtin
EXTEXTRADIR=~/.local/share/code-server/extensions-extra

echo "Synchronizing settings and extensions from local vsc installation . . ."

# COPY SETTINGS
mkdir -p "$DATADIR"
rsync -a --delete ~/Library/Application\ Support/Code/ "$DATADIR"

# COPY 3rd PARY EXTENSIONS
mkdir -p "$EXTDIR"
rsync -a --delete ~/.vscode/extensions/ "$EXTDIR"

# COPY VSC built-in extensions
mkdir -p "$EXTBUILTINDIR"
# rsync -a --delete ~/Library/Caches/com.microsoft.VSCode.ShipIt/update.*/Visual\ Studio\ Code.app/Contents/Resources/app/extensions/ "$EXTBUILTINDIR"

mkdir -p "$EXTEXTRADIR"

# START CODE-SERVER
echo "Starting code-server"
nohup ./code-server \
    --user-data-dir "$DATADIR" \
    --extensions-dir "$EXTDIR" \
    --extra-builtin-extensions-dir "$EXTBUILTINDIR" \
    --extra-extensions-dir "$EXTEXTRADIR" \
    --cert "$CERTIFICATE" \
    --cert-key "$PRIVATEKEY" \
    --port $PORT \
    --auth password \
    --disable-telemetry \
    ~ >$LOGFILE 2>&1 &

(tail -n +1 -f $LOGFILE & P=$!; sleep 4; kill -9 $P 2>/dev/null)

[arnavs]

It looks like this issue has an assignee: @roblourens. But they haven't yet posted in this thread.

Rob, are you still available to work on this? If not, do you mind re-assigning it to someone who has bandwidth? It appears this is a pretty desirable feature...

[jnovack]

Remote Host

1. Install Docker.
2. Open Terminal
3. mkdir vscode-hack
4. cd vscode-hack
5. vi Dockerfile
6. docker build -t ssh .
7. docker run -d -p 2222:22 --name ssh -v ${HOME}:/opt --restart unless-stopped ssh

Dockerfile

FROM centos:latest

RUN yum install -y openssh-server

RUN mkdir /var/run/sshd
RUN echo 'root:DanielSmithRocks' | chpasswd
RUN sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config

EXPOSE 22
RUN /usr/bin/ssh-keygen -A

CMD ["/usr/sbin/sshd", "-D"]

You may want to change the password on Line 6, or not. :)

Local Host

Within VSCode:

1. Click Remote Explorer
2. Click Settings
3. Edit .ssh/vscode.config

vscode.config

Host OSX
    HostName IP.AD.DR.ESS
    User root
    Port 2222
    StrictHostKeyChecking no
    UserKnownHostsFile=/dev/null

---

In an attempt to not get this issue locked, please direct all questions regarding this work-around to my repository. Please create an issue for your question.

jnovack/docker-vscode-hack-osx

[andyneff]

@jnovack, I've tried your idea several different ways, and I get my vscode client to connect to the server, but when I go to click "Open Folder", it timeouts saying "Could not fetch remote environment"

The last thing I see in the details are:

36316b264e77: start
sshAuthSock====
agentPort==39287==
webViewServerPort====
osReleaseId==centos==
arch==x86_64==
webUiAccessToken====
36316b264e77: end

I even updated to the latest VS Code 1.40.1. Any ideas?

[jnovack]

In an attempt to not get this issue locked, please direct all questions regarding this work-around to my repository. Please create an issue for your question.

jnovack/docker-vscode-hack-osx

(Mods: Sorry for the litter...)

[Yelloow]

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]

@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]

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

[rgov]

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]

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]

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

[Hultner]

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]

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]

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]

still waiting for this 👎

[DanTup]

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]

@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]

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.

[jamiewest]

Thank you!

[yueyericardo]

THANKS!!!!!
It's working.

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

[doomlsn]

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]

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

[david02871]

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]

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]

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