Persistent SSH session

[davidanthoff]

A lot of users of our Julia extension love the remote SSH features, they are super useful in a scientific research computing context!

One thing that has come up a lot lately, though, is that folks want an ability to have a persistent session on a server that they can disconnect from and then reconnect to way later.

The scenario is essentially something like this:

1. User connects to some remote server via the Remote SSH extension
2. They do some work
3. They get interrupted and close their local VS Code instance
4. They do something else for a couple of days
5. The now want to reconnect to the server, and ideally nothing was shut down on the server. For example, if they opened a REPL in step 2 and started a Julia instance in that REPL, it would still be running, and was never shut down. Similarly with pretty much all other runtime state they had.

I think this might be related to #440, but what I'm really asking for is not just an option to change the timeout, but some way to make the timeout infinit, so that the server session never shuts down.

This might also require some kind of UI, maybe a command like "Disconnect but keep server alive" or something like that, not sure.

[xgdgsc]

#1790 also related.

[EricChen1248]

Not a perfectly solution, but what about opening the terminal into Screen. Users could reconnected back to their screen session each time, also gives more fine grain control over resource releases (properly terminating a process vs an always persistent session)

[PavelSosin-320]

This is a well-known pattern in the Cloud Applications. The problem is always that lifecycles of Server and client are not synchronized and either server or client or connection can go down at any point all clients will hang. Then, clients have to re-authenticate. If the client is idle at the point of time was idle its user will have no knowledge of how to proceed. To avoid such a died-end situation client needs awareness of the "session status" i.e. Server needs session management and ability to report either current session status to the client, at least, by the explicit client's request or every re-connect request coming from the client has had session attribute. There is also a security risk that the session can be hijacked by anybody who has a valid login of the server when the client was idle.

[janosh]

Glad I found this! Just wanted to mention that I believe this is far larger in scope than the Julia extension. I bet most people forced to work from home these days would really appreciate this feature!

[bobaoapae]

This is what i need for stop using RDP to remote developmet. Sometimes i need keep service runing for several days and i don't want keep my own pc on just for it. Keep process running without vscode remain connected and re-establish connection/state after re-open vscode will be amazing!

[tom-programming]

This would be a real game changer for myself, and I believe, a whole lot of people. Now I use tmux to achieve the same but it is uncomfortable in many ways

[mineralres]

Glad to hear that this feature request was received, it would be very useful for my working context.

[ImMrMa]

Is there any progress on this feature recently?

[abhijithda]

Hopefully the timeout considers people coming back to work from long weekends, and resuming/waking up a sleeping computer/laptop :)

[taiya]

This would be a real game changer for myself, and I believe, a whole lot of people. Now I use tmux to achieve the same but it is uncomfortable in many ways

Agreed, e.g. tmux interferes with mouse scrolling, and does 100x other things on top of having just a persistent SSH session. Considering vscode has a server running remotely... it shouldn't be impossible to have a keep-server-alive mode?

[ImMrMa]

It has been nearly two years since this issue opened. Could we pay a little attention to solve the problem? I think it is a great improvement to users.

[lrnv]

@davidanthoff Is there some kind of workaround available for a remote and long-lasting Julia session, that would allow disconnecting and reconnecting multiple times without losing the (remote) Julia REPL ?
In both cases, what is your current workflow for this kind of remote developpement ? It seems like the Julia extension has a 'remote development' section in its documentation, but sadly empty.

[xgdgsc]

@lrnv It supports tmux now https://discourse.julialang.org/t/ann-vs-code-extension-1-2-released/62118

[restyler]

I would be happy if VS code finally managed to restore all terminals properly after SSH disconnect.
If other node.js developers sometimes launch nodemon process and then struggle to kill the detached nodemon session because of VS Code remote lost session, here is a set of commands how to quickly locate the nodemon PID & kill it:
https://pixeljets.com/blog/killing-detached-nodemon-process/ (second part)

My major pain with tmux in VS Code Remote is that I can't copy&paste text to my vs code editor. Is there an easy way to fix it? I tried xclip on my remote Ubuntu and

set -g mouse on
bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "xclip -se c -i"
bind-key -T copy-mode MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "xclip -se c -i"

from https://www.vinnie.work/blog/2020-11-24-why-so-hard-tmux-copy-paste/ article without any success. Apparently it is not good for VS code terminal approach which is understandable - we have another link in our chain (Mac <-> Ubuntu <-> tmux )

[larsrgit]

For the time the code server keeps running, either the default time-out or when keeping it running forever using this solution #3096 (comment), how can I reconnect to it?

For me even if on the host the code server and all related processes are still running, when I reconnect to the host (even if the ssh connection is only interrupted for a few seconds), it starts a second code server on the host instead of reconnecting to the old one.

[pkubik]

Has anyone tried a simpler way to create a tunnel with https://code.visualstudio.com/docs/remote/tunnels ?
I used it on Remote window, but it only gave me access to my local workstation. Maybe it's worth a shot to install VSCode CLI on remote machine and use it there?

I'm only worried that this "server" code that you can install manually is slightly different from code command that is made available when you run remote connection. I wouldn't like to lose the ability to quickly open files in my editor.

Edit:

tl;dr doesn't work like we expected

I tried it. It's kind of scary, but fairly simple. The important thing is that You need to install code on the server (e.g. the deb package). The code command available after connecting to a machine doesn't work at all. The code server installed by remote connection plugin works, but it doesn't print any URIs to connect to.

After you run code tunnel it will ask you to authenticate with your GitHub. This is scary, because you give your server access to your GitHub. Normally, you give it access anyway so I guess there is nothing to worry about (above what you should normally worry about :P). Let's assume your server is secure.

Then you can click the link to open VSCode in browser and again authenticate to gain access to the machine. I did it, and the machine also showed up in my remote explorer on the locally installed VSCode. When I closed the browser I could still use my remote connection from my PC. I guess you could try to skip this step and manually add this remote server to your local VSCode by URI, without opening the browser.

The browser version works nicely, because it preserves all windows and terminal sessions. Unfortunately, desktop VSCode treat this connection slightly differently, because it ties all editor and terminal windows to specific desktop instance. Once you close the VSCode window all progress is gone.

[abdelDarwish510]

Any updates on official support for this feature?

[vrtem]

hey, any updates here?

[dcnatsos]

Yeap, we need this feature!! And there must also be support for Jupyter Notebooks

[eliezedeck]

AWS Cloud9 already has this persistent feature for years and years now. Gitpod also provides this via their own extension, however, it's tied to Gitpod servers (arguably cheaper than Azure Dev Box) and you need to configure timeouts to be higher than default (depending on your usecase). So, the possibility is there, it's just not getting enough attention. I wonder why this stays stall for a long time, and yet it's got lots of demands.

[mmphego]

4 years later, and this issue still open.

[albertopasqualetto]

I think (but I still have not tested) that here is the problem

[eliezedeck]

I think (but I still have not tested) that here is the problem

Interesting finding. So you're saying that you've tested it and it became persistent afterwards?

[marios1861]

Any updates on this? For remote AI training on GPU machines this is going to be such a huge quality of life improvement.

[youngdjn]

Another vote for this!

[wayhoww]

For those who consider persistent ssh session as a critically important feature, you can also try JetBrains Fleet. By utilizing its collaboration feature(which is similar to vscode-tunnel), it keeps terminals and debugging sessions after client being closed. Though it's not open source, and it does not even support plugins.

[moyamejiasr]

I also think we need this. And the worst part is how it is so easy to implement by making the stupid --enable-remote-auto-shutdown optional from the settings yet it has been 4 years and no progress.

[ionagamed]

Is there a confirmation from the team that PRs with a flag in extension settings for --enable-remote-auto-shutdown would be accepted?

[marios1861]

@ionagamed The microsoft remote development extensions are not open source (see #30). From my exploration, the struct CodeServerArgs in code_server.rs needs to have an additional Option argument (e.g. keep_alive), which needs to be used in the listen_on_port function. To actually wire this back up to the extension settings, we would need permission to access and directly contribute to the actual extension. It's so infuriating that they have close-sourced the extension and simultaneously don't bother with SIMPLE quality of life improvements because they are focused on the (profitable) dev containers project, or the Microsoft hosted remote - tunnels, for which the rug can be pulled at any time. We should just write our own remote ssh dev extension.

[TomRaz]

That would be a great addition

[mrakgr]

I want this too.

[benz0id]

this would be great!

[PRO-2684]

Any news regarding this feature? This would be a great improvement. In my usecase, when I build a devcontainer, it might take hours, and I don't want to keep VSCode open on my laptop for that long - I'd like to close VSCode, do something else on my laptop, and reattach peoredically to check the progress. For now, as a workaround, I'm inspecting logs of devcontainer and running them manually with nohup, but this approach has certain minor short-comings.

[mrakgr]

Any news regarding this feature? This would be a great improvement. In my usecase, when I build a devcontainer, it might take hours, and I don't want to keep VSCode open on my laptop for that long - I'd like to close VSCode, do something else on my laptop, and reattach peoredically to check the progress. For now, as a workaround, I'm inspecting logs of devcontainer and running them manually with nohup, but this approach has certain minor short-comings.

I've been using tmux to get around the lack of persistent sessions. tmux is utility that allows you to start detached terminals, which enables you to smoothly reconnect to them after restarting the editor.

[antonmx]

One workround for now (only for users who wants the remote-server persistent FOREVER, not for users who wish to change the timeout value):

vscode starts the remote server by launching sh <vscode-server-bin-path>/bin/code-server --start-server --host=127.0.0.1 --accept-server-license-terms --enable-remote-auto-shutdown --port=0 --telemetry-level all --connection-token-file <path-to-token-file> in your default shell (/bin/bash in my case) after it established the SSH connection.

Therefore, just remove the --enable-remote-auto-shutdown argument, and the server will run without the idle timeout. This can be achieved by a customised wrapper for sh. My version goes like:

 #! /bin/bash

 args="$@"

 ignore_me='--enable-remote-auto-shutdown'

 if echo "$@" | grep -q -- "/.vscode-server"; then
     if echo "$@" | grep -q -- "$ignore_me"; then
         args=$(echo "$@" | sed "s/$ignore_me//g")
     fi
 fi

 /usr/bin/sh $args

And then export PATH=<path-where-you-put-that-wrapper>:$PATH in .bashrc (or into vscode's ssh-config, if you dislike polluting your shell environment). Now vscode will launch the remote-server without enabling the annoying idle-shutdown.

Thanks much for this idea! It did not work for me directly - I guess .../.vscode-server is executed with "#!/usr/bin/env sh" which still points to /usr/bin/sh, rather than one in the PATH. I got it working via another dirty hack:

sudo mv /usr/bin/sh /usr/bin/sh.real

and creating slightly modified version of your suggestion in /usr/bin/sh:

#!/bin/bash

args="$@"

ignore_me='--enable-remote-auto-shutdown'

if echo "$@" | grep -q -- "/.vscode-server"; then
    if echo "$@" | grep -q -- "$ignore_me"; then
        args=$(echo "$@" | sed "s/$ignore_me//g")
    fi
fi

/usr/bin/sh.real $args

I have observed side effects as some errors reported on vscode startup, but no visible issues otherwise.

BTW, instead of using those two if's in the script you can replace them with the single line:
args=$( sed 's:\(.*/\.vscode-server.*\)$ignore_me\(.*\):\1\2:g' <<< "$@" )

I suspect in the above line better to quote "$(...)" as well as "$args" in the last line. Also in the last line I probably should use eval?

[Arcadiyyyyyyyy]

Please please please please please

[MTDickens]

Any updates on this long-lasting issue?

[edechamps-Google]

As part of my work I often find myself starting a long-running command (e.g. a build) in a VS Code Terminal, and then close my laptop and go to a meeting. When I open my laptop again 30 minutes later, I have to run the command again because the VS Code server bailed while I was away. This is quite annoying - at the very least the grace period should be customizable (I would personally set it to something like 3 hours).