FYI VSCode's SSH Agent is a godsend for remote development - the "disadvantages" that Fly lists are part of its advantages. I've worked in several teams that have made extensive use of the extension, and it's never been an issue. You can restrict SSH access arbitrarily to ensure whatever security or access guardrails you need.
it's worse than that, last i looked into this - there's functionality in the protocol that allows the remote system to modify files and execute code on the local/frontend system. it really is bananas.
Edit: there's a security note (still) on the remote ssh extension page:
Security Note
Using Remote-SSH opens a connection between your local machine and the remote. Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine.
The ability to remotely run arbitrary code on a machine that intentionally gives SSH shell and write+execute access to the filesystem is not a vulnerability just because it's a productivity aid to users who want to leverage this access to do bad things on the remote machine.
A remote access protocol that gives a potentially untrustworthy remote system the ability to execute arbitrary code on the local machine is a serious problem in any scenario where the remote connection is presumed to be a one-way trust boundary.
Which of course includes any scenario where I myself deliberately run untrustworthy code on the remote, no matter how much I trust the remote itself and its owners.
There's also the risk that VS Code is a "trusted" application in many enterprises because developers force it to be. VS Code's node runtime (and plugin system) executing somewhat arbitrary Javascript means that any dev servers become vulnerable to exploits you otherwise might not have prepared to defend against [1].
Otherwise, you could see Javascript running on a server and instantly know something was odd, depending on the server.
danielklnstein · · focus · HN ↗
FYI VSCode's SSH Agent is a godsend for remote development - the "disadvantages" that Fly lists are part of its advantages. I've worked in several teams that have made extensive use of the extension, and it's never been an issue. You can restrict SSH access arbitrarily to ensure whatever security or access guardrails you need.
miohtama · · focus · HN ↗
devonbleak · · focus · HN ↗
Edit: there's a security note (still) on the remote ssh extension page:
Security Note Using Remote-SSH opens a connection between your local machine and the remote. Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine.
<a href="https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh" rel="nofollow">https://marketplace.visualstudio.com/items?itemName=ms-vscod...
jasomill · · focus · HN ↗
The ability to remotely run arbitrary code on a machine that intentionally gives SSH shell and write+execute access to the filesystem is not a vulnerability just because it's a productivity aid to users who want to leverage this access to do bad things on the remote machine.
A remote access protocol that gives a potentially untrustworthy remote system the ability to execute arbitrary code on the local machine is a serious problem in any scenario where the remote connection is presumed to be a one-way trust boundary.
Which of course includes any scenario where I myself deliberately run untrustworthy code on the remote, no matter how much I trust the remote itself and its owners.
kevinrineer · · focus · HN ↗
Otherwise, you could see Javascript running on a server and instantly know something was odd, depending on the server.
[1] - <a href="https://www.darktrace.com/blog/darktrace-identifies-campaign-targeting-south-korea-leveraging-vs-code-for-remote-access" rel="nofollow">https://www.darktrace.com/blog/darktrace-identifies-campaign...