code cannot read files on remote server

[MalikTeng]

Checklist

• Using latest version on the App Store
• Read the docs
• Searched for existing GitHub issues

Configuration

Blink version: 15.0.6.528
iOS version: 15.3.1

Describe the bug

I am using ProxyCommand to go through the host to my remote_server and have configured the host and server in Blink. Using ssh command works fine, but I can't use "code remote_server:path/to/project" to get VS Code to read the files on the remote server.

Since I don't have permission to upgrade OpenSSH (version 7.2) on the host, I had to configure the remote server with 'ProxyCommand ssh -W %h:%p host' instead of ProxyJump.

[akihitoh]

I have a similar issue with ProxyJump. Since I am not sure that either blink or Blink-FS handle with this issue, I have not been able to ascertain any further details of this issue.

[carloscabanero]

The ProxyJump flag is handled by the client, Blink in this case. It internally will do the translation for you, but we have to rely on that as we cannot really run "arbitrary" commands when working with Code or the Files.app. Could you try changing it to ProxyJump and see if this is still an issue?

[MalikTeng]

Hi carloscabanero -I tried to use ProxyJump, but still no success, the error is connError(msg: "Socket error: disconnected"). I managed to connect to my remote server yesterday via tunnel forwarding and got access to the project files via blink code. However, this requires connecting to the proxy host first and connecting to the remote server via tunnel forwarding, in which case FIles.app doesn't work very well.

[carloscabanero]

It has been a while of this, but in case someone else runs into the same issue.

The way to go is to try and connect over ssh first. We have been making a few adjustments to the connections trying to simplify and improve logging as well. It should be possible to use LogLevel debug in .ssh/config and read the output from either the commands or the .blink/blinkCode.log file.

If ssh works, then the FileProvider has to work.

I also just noticed that we were using a remote_server as a name, and this could have triggered #1440. This has now been fixed as well.