[schmichael]

I think the difference is that what VSCode is doing is not an SSH Session like you get in a terminal with the ssh command or putty.

VSCode is installing a remote agent on the target machine that happens to use ssh as its transport protocol, and offers to share that transport with the user.

Is this a problem? Not if it only does things you want it to do. However any agent based system exposing an arbitrary API is suddenly a much bigger attack and risk surface area than the well trod (and still fraught) path of emulating a terminal over ssh.

[shitter]

> However any agent based system exposing an arbitrary API is suddenly a much bigger attack and risk surface area than the well trod (and still fraught) path of emulating a terminal over ssh.

I can see how this increases local (to the remote system) attack surface, but as long as the agent has the same OS privileges as the user logged in over SSH, what extra remote risk does this introduce?

[smackeyacky]

Because if the Agent code is compromised, the fact that it leaves things behind is enough for an attacker to hide whatever they need along with the vs code blob. Vscode does this for the right reason, mostly it’s so the bulk of it runs on the host where you’re doing remote development or WSL or whatever. But like a lot of dev stuff these days, compromise the npm packages and bingo you can own all the machines.

Npm is already a terrible thing because the packages are managed so haphazardly, but now you’re exposed to the nonsense without even going anywhere near the mad rodeo of node. I like vscode but it’s not going anywhere near a machine I care about.

[lostmsu]

Can you give a specific example of exploitation of a theoretical bug in the agent?

[w0m]

The argument is that you're running code on the remote host, and it could be compromised. The same argument can be made about any code you run on the remote.

VSCode may be seen as a larger attack vector due to its popularity; but maybe not as many won't use the SSH agent? It's also fairly common sense that you should never run it to mount on a production resource; but again, you shouldn't be able to ssh into a production machine anyway.

[zelphirkalt]

They wrote "compromised" not "buggy". There does not have to be any bug. It can all work as intended... by an attacker!

[makeitdouble]

We usually don't hand over full ssh sessions to third party programs, so while you're right, I think people are not used to this level of trust into an app.

The article was to me a good reminder that it's a whole other level of access than just remote mounting a file system.

[cogman10]

A user that can manage remote processes is generally going to have pretty high permissions.

For example, opening up debug ports on the running server processes, sudo privileges, or just the ability to run arbitrary code or curl in random binaries from the internet.

[0xbs0d]

I think the latest Jetbrains tools do the same or similar things. They also install their own server on the target machine and connect to that. And I mean it's Jetbrains, so again, closed source tools. But it's not Microsoft so nobody is talking about it I guess.

[Y-bar]

I think you are talking about https://www.jetbrains.com/remote-development/gateway/ which requires a separate manual install on the client followed by a manual installation on the server during setup. It is not part of the regular IntelliJ IDE as far as I can see.

[0xbs0d]

It isn’t. I mean yeah gateway is what you described. But the functionality is also included in Jetbrains IDEs and doesn’t require any manual install on the server. It installs its own thing exactly like VSCode does.

[Y-bar]

I can't find any such thing in PhpStorm v2024.3, can you tell me the feature name? Is it this you are thinking of (which requires some clear manual steps)?

https://www.jetbrains.com/help/phpstorm/remote-development-o...

[rtsil]

If you're thinking about JetBrains' remote development, it's actually the IDE (a headless version) that's installed on the remote dev machine. Since you first need to install the IDE on the dev server first, you are never under any illusion that it's a simple SSH-based remote editing à la vim (even though it also relies on SSH).

[_boffin_]

They have two ways — remote development, which is what you’re saying and remote execution.

Remote execution is the one I prefer. Rsync and then just runconfig. It’s lightweight and simple

[TZubiri]

I sometimes kick myself for not being more productive.

But then I see the clusterfucks productive people are doing and it looks like I'm onto something

[eru]

Sounds like, if you take this to the limit, the course of action is to not touch a computer?

[what-the-grump]

Just like if you take eating healthy to the limit, the course of action is to not eat and starve to death?

That’s why we don’t take things to the limit right? That’s how you get a singularity.

[regularfry]

From a security perspective, the very best option is to prevent anyone else from touching it either. Including to turn it on.

[shipp02]

Is it better to programmatically interact with bash to provide the features VSCode does? Do note that I am unwilling to accept an implementation with less features/ease of use!

I can see how writing a custom agent that provides remote access to privileged API's is a bad idea but bash isn't exactly the most secure piece of software in the world.

[zelphirkalt]

Bash is not running though. You might get a Bash session once you connect via SSH, but it just sits there waiting for you to input commands, while the VS Code installed agent thing does network stuff on its own iiuc. Bash is not acting as a server, afaik.

[wg0]

Anyone doing such remote edits on production or even staging systems is past the point of caring about any security implications.

The remote development workflow is intended and should be used for dedicated disposable development machines.

That's the responsibility of the operator and it is not for the tool to take care of.

[3abiton]

This is really big. I always thought Vscode ssh capability was just some black magic that the open source community wasn't able to replicat well with vscodium extensions. Yet, it seems the reason why is that MS threw a curve ball with that naming.