VSCode over SSH

I’m running Electric Eel RC2 and would like to use VSCode with the SSH remoting mechanism. Unfortunately, when I try to connect, it throws an error about dynamic port forwarding not being available, and that’s a requirement for it to work. Looking at /etc/ssh/sshd_config, it looks like AllowTcpForwarding is set to no. Is that something that is safe to change, or was that locked down to prevent conflicts with Docker/etc.? I’m hesitant to make changes on TrueNAS given how customized it is versus a traditional Debian box.

It’s a security feature. It prevents people from doing what you want to do.

If you want to do it, you can enable it in the ssh service prefs pane, and then you can use vs code.

2 Likes

I seem to have lost ssh functionality with vscode as well. Before migrating to Electric Eel, I had no issues. I already have AllowTCPForwarding set to on as well as all of the standard ssh config settings. When I ssh from the terminal, I connect just fine. However, if I connect via vscode, I get the following error

Error: Couldn't install vscode server on remote server, install script returned non-zero exit status

It seems that my server downloads the vscode-server files just fine, but cannot execute them when called via the ssh startup. I have also uninstalled the created folder rm -rf .vscode-server and attempted the ssh connection again and receive the same error.

Has anyone been able to successfully resolve this error?

Only workaround is to use the root-account over ssh for vscode, which is not desired!

Even if you are member of the “builtin_administrators” Group, you will not be able to install the vscode-server as a regular user. …will this change, or is this limitation part of the mandatory security-concept?

[12:28:16.365] [server] Error installing server: error unpacking /mnt/Work/itservice/home/andur/.vscode-server/cli/servers/Stable-17baf841131aa23349f217ca7c570c76ee87b957.staging/server/: Custom { kind: PermissionDenied, error: TarError { desc: “failed to set permissions to 755 for /mnt/Work/itservice/home/andur/.vscode-server/cli/servers/Stable-17baf841131aa23349f217ca7c570c76ee87b957.staging/server/”, io: Os { code: 1, kind: PermissionDenied, message: “Operation not permitted” } } }

No. This just means that you have your ZFS dataset’s aclmode set to RESTRICTED.

1 Like

Right, it was “restricted”!
The Fix for VScode over remote SSH for my user was:
The Home-Path of my user is on a NTFSv4 Dataset, which is shared via Samba.
So i edited the advanced details of the shared Dataset to become “passthrough”, which is as i expect it from other Installations.

  • If aclmode is discard, the file’s permissions will change to 755, and the ACL will be removed.
  • If aclmode is passthrough, the file’s permissions will change to 755, and the ACL will be adjusted to be consistent with the new permissions.
  • If aclmode is restricted, the chmod command will fail, and the file’s permissions and ACL will remain unchanged.

Thanks, very good!

Right, but do remember the chmod is altering the ACL in a way that may not be desired. Generally it would be better if tools would leave permissions alone.

Problem closed.
Now i can remotely use vscode to edit the Docker-Containers on Site.
With modes explained, nobody touches this in an enterprise situation.
The dangerous workaround via root login is gone.

1 Like