When you're running VS Code Remote SSH and loose network connectivity over a long period of time and return to VS Code, the status on the bottom left show's "Disconnected from SSH: ". However, there doesn't seem to be a way to reconnect the session. I always have to revert to starting a new VS Code Remote SSH session. How can I reconnect?
You can reload the window. It keeps unsaved changes even.
Press F1 to search for commands, then search for:
Developer: Reload Window
Version of VSCode when trying this: 1.53.2.
EDIT: This does NOT work to reestablish the connection. It only helps to keep it alive. Thanks for the comments. I misinterpreted the question while looking for something similar for myself.
I'll leave the answer just in case it helps someone else.
You need to set a custom ssh file and add parameters to keep the connection to your host alive :
Host SomeRemoteHost
HostName MyRemoteHostName
User MyUsername
ServerAliveInterval 60
ServerAliveCountMax 30
Go to the SSH extension settings and set the new custom ssh config file path. This won't work if your machine goes into sleep mode, but it will keep the connection alive in the background while you work on other things.
PS: Make sure your ssh settings are correct for the host or you won't be able to log in.
It seems that there is something that drops your idle connection. As I know SSH doesn't have any configuration for dropping an idle connection but firewalls has. there might be some sort of firewall or monitoring software or hardware device which drops your connection. if you are using Linux OS the following command might help you:
ssh -o "ServerAliveInterval 60" <SERVER_ADDRESS>
this command sends keep alive request to ssh every 60 seconds.
In line with #PaulOmta answer, the easiest way is now adding this Reload button extension! It adds a Reload button to your status bar on the bottom right.
I found that ⌘-R shortcut didn't work on mine (maybe because I have other keybinders on)
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=natqe.reload
Related
I find that if I leave my VS Code Remote SSH connection open it disconnects automatically after a certain amount of time. Following automatic disconnection I find the Remote SSH then fails: when I try to log in again I get repeated requests for my remote password and every time I enter my password I just get another password prompt.
My current workaround is to go to the Command Palette and do "Remote-SSH: Kill VS Code Server on Host". Sometimes I need to do this multiple times for it to take effect. Then when I next log in there is a lengthy VS Code installation script that needs to run before I can start coding again.
Is there a way of setting up VS Code Remote SSH that avoids this issue? I have tried some of the suggestions on this page - https://code.visualstudio.com/docs/remote/troubleshooting. However I feel like I am completely in the dark regarding what the underlying issue is. I do not even know how I could go about generating informative diagnostics / a log.
Maybe the problem is that the remote machine has a limited number of proccess to run at same time. When a automatic disconnection of vscode happen, the that session is still running, but you cannot create a new one because you are over the limit in number of process.
In my case, asking to the remote machine to kill my process (manually done by the technician working in that machine in this case) works.
A better solution will be close the vscode sessions from your machine, to be able to start a new one again.
The exact error is "Could not establish connection to "[server_name]": Remote host key has changed, port forwarding is disabled."
I recently "rolled back" a production environment's update by launching a new instance from a back up. This gives me a new server host key, as expected. Every other SSH connection tool I've used (WinSCP, FileZilla, Text Wrangler, Putty, Terminal, DBeaver, etc) has a notification of the change and lets you confirm the key yourself and verify it is valid (or not).
I cannot find that option in VS Code remote dev tools. It prompts to simply close or retry(same error, obviously). The "More actions" option doesn't give me anything but configuration file options, settings that I believe don't allow me to update the host key, and the documentation which to the best of my knowledge doesn't explain how to update the host key either.
I assume I'm missing something simple somewhere... any help is appreciated.
It was something simple. Found while trying to review the question.
"A supported OpenSSH compatible SSH client must also be installed." as listed in the system requirements of the documentation(linked in question). The key simply needs to be updated in said OpenSSH client before attempting the connection in Visual Studio again.
In this exact case it was as simple as going to [local_path]/.ssh/known_hosts and removing the old entry for the IP address and then attempting the connection again which now allows the verification of the new key.
remove the hostname's key
ssh-keygen -R "hostname"
I'm currently trying to access a remote server using VS Code's Remote SSH extension. I haven't had a problem when using it before (that was around a month ago) but today when I tried to access the server I ran into some trouble.
I have the hostname and everything configured in a config file, and so I just click on that option and type in the password. However, VS Code seems to be stuck on "Opening Remote..." for the past hour or so. The dialogue I get in the terminal is as follows:
username#host's password:
Running remote connection script
Acquiring lock on /home/username/.vscode-server/bin/abcdefghijklmnop1234567989/
vscode-remote-lock.abcdefghijklmnop1234567989
Installing to /home/username/.vscode-server/bin/abcdefghijklmnop1234567989...
Downloading with wget
Does anybody know what the problem might be? Is this normal?
EDIT
As soon as I posted this the connection was successfully made. However, I would also like to still know what the problem was and if it normally takes around an hour, and what this process might be doing. I also believe it would be helpful to the community overall.
Thank you.
I've faced the same issue just now and realized that firewall protection has something to do with it.
As soon as I disabled it, the remote connection was established and I managed to see my code again.
My issue is while launching the RemoteApp it keeps spinning and says "Configuring remote session". Not all the time, though. It was launching a while ago and signed off. Now again launched the RemoteApp it just spinning.
And when I try to cancel it won't Cancel the RemoteApp I have to kill through the Task manager.
After killing it, I launched again and it just worked as expected
I need to get this fixed. Please suggest a resolution for me.
RDS is on Windows server 2012 R2
Client launching from Windows 10
Could you please let us know the following details.
Is this a recurring issue or 1 time occurred issue?
Please try to telnet the remote machine and check whether it's reachable or not when this problem occurs and share the feedback with us.
And also try the below solutions also, may be it'll fix this RDB freezing issue.
Try to see whether reducing Graphics helps.
This seems to have helped in few cases. This verifies whether you have the correct graphics driver.
Here’s how:
Right click the Windows desktop and choose Personalize.
Click "Display Settings".
Click "Advanced Settings”.
Click on "Troubleshoot" tab.
Click on "Change Settings".
On the resulting Display Adapter Troubleshooter dialog box, drag the slider one notch to the left.
If changing the video hardware acceleration solves the problem, it's a signal that your computer's video driver isn't quite perfect.
In such cases, download the driver from the link below.
http://support.dell.com/support/downloads/driverslist.aspx?c=us&cs=19&l=en&s=dhs&os=WW1&osl=en&catid=&impid=&SystemID=STUDIOXPS8100
Connect and see if there’s any improvement.
Security software could also be one of the reasons.
Temporarily disable them and verify the result.
Try disabling Receive Window Auto-Tuning.
Here is what you need to do:
Go to Start and type cmd.
Right-click on cmd and select “Run as administrator”.
Type: netsh interface tcp set global autotuninglevel=disabled and press Enter.
If you want to to re-enable it:
Type: netsh interface tcp set global autotuninglevel=normal and press Enter.
If this doesn’t help, please post your concerns at Technet forums for further support.
http://social.technet.microsoft.com/Forums/en/w7itpronetworking/threads
Note: Ensure to enable all your security software by now.
If the above steps unsuccess, use below steps and try the same.
Logon to the Remote Desktop Services Session Host computer as an administrator
Start--Run gpedit.msc
In the left pane, under Computer Configuration, navigate to following:
Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment
In the right pane, double-click on Set compression algorithm for RDP data
Select Enabled, and choose Balances memory and network bandwidth
Click OK to save the change
This page from the Emacs manual describes a function called make-frame-on-display that allows you to access a remote Emacs session. My interest in this function is to use it to share buffers for pair programming remotely with a colleague.
From the page:
It is even possible to use this feature to let two or more users type simultaneously on the two displays, within the same Emacs job. In practice, however, the different users can easily interfere with each others' edits if they are not careful.
How exactly do I set this up? What do I need? What does my partner need? The details are not stated, but I don't know enough about Emacs to know where to start.
Is there any other way to get a shared Emacs session? This page from the Emacs Wiki refers to something called multi-tty. The questions I asked above also apply to this.
Which is better: multi-tty or make-frame-on-display?
I haven't tried multi-tty, but make-frame-on-display is pretty simple. You type M-x make-frame-on-display, hit return, then type the display you want the frame to show up on. For example:
I have my local host (thor) running emacs and I want to make a frame pop up on a machine called zeus, on its only X display (0.0). So I would type M-x make-frame-on-display<ret>zeus:0.0<ret>
All set!
You may need to configure the remote machine's X server to accept incoming connections from your machine with "xhost +thor". You may also need to configure its firewall to allow incoming connections on the X11 port, which is 6000. Keep in mind that X forwarding is not encrypted, so if you aren't working with someone on your LAN you may want to go through a VPN in order to keep things private.
Edited to fix brackets.
You can also have the person at zeus type ssh -X thor emacsclient -c.
Did you ever consider using GNU screen on a shared account for pair programming? It's dead easy to get it to work and you get to pick any console based editor you and your partner like (emacs, vim, joe, nano, zile, ...). However, this does of course not work with editors that cannot run inside a terminal.
To set it up, create a shared account on a computer running ssh. Then both log in to that account. One of the partners starts screen with
screen
and the other connects to it with
screen -x
where -x means "attach to a not detached screen session". The users can detach from their sessions w/ "C-a d".
Old question, new solution for anyone landed on this page from year 2016.
I set this up in Ubuntu 14.04 and it works perfectly:
Suppose I want to co-edit or demo some cool stuffs on emacs with my colleague Joe on the other end of the world.
Make sure an ssh server with emacs installed at either end. That is, either MyPC or JoePC must be a SSH server and have Emacs installed. From now on, let's say I asked Joe to install SSH server and Emacs on his computer.
Make sure byobu is installed on JoePC. Byobu supports both tmux and screen as backends (I prefer tmux for a more mordern and feature-rich).
I connect to JoePC with ssh remoteuser#joepc. No need for X-forwarding.
Open emacs from byobu-ssh terminal: TERM=xterm-256color && emacsclient --alternate-editor="" -t. One can make an alias for this command. I recommend this long command because it enables both better color support in the terminal and running Emacs in daemon mode. The daemon mode make it fast to close and reopen frames.
Now the magic unfold: Ask Joe to login with the same remoteuser I am loggin in; open the terminal and start byobu if it hasn't for him.
Start hacking or fumbling :-)
Comment:
Because the way byobu work. This approach works for any other program inside the byobu terminal.
This setup performs much better than Teamviewer or any other GUI remote desktop solutions.
Because the connection is through ssh to the remote server directly, it is as secure as the ssh conenction can offer.