Troubleshooting remote connection or login issues

[This is a Wiki post, feel free to edit!]

First and foremost, you can always contact BIC IT to get help. However, you can also quickly try a few basic steps, described here.

First step: SSH
Possibly the most informative step is to try to login on the workstation via ssh. This will tell you if the system is on and responsive, if your password works, and it allows you to restart services, your session, or even reboot the system. First, log onto login.bic. For Linux/MacOS:

ssh <username>

You can use the Chrome SSH extension, or PuTTY on Windows.
Then click Open and enter your username and password.

Once logged in, you may receive a warning if your home folder is full. This can cause a variety of issues, including difficulties connecting, and should be taken care of first.

You can then attempt to connect to your workstation:

ssh -x <workstation>

replacing <workstation> with your machine name (e.g. If you get the error no route to host, the system is offline or unresponsive. There’s not much that can be done remotely in that case. Someone probably has to go restart the system on site. You can also double check with:

ping <workstation>

ctrl-c to stop pinging. If it doesn’t show many lines with response times, and 100% packet loss once you stop, the system likely has to be restarted on site.

If you are able to log in, it already confirmed the system is on and your credentials are good. You can now choose to reboot or troubleshoot some more.

The sledgehammer: reboot
The obvious thing when you don’t have ongoing computations or unsaved work is to reboot. You should however also consider that other users may be using the system, so please always check that first. Unfortunately, who or w don’t include everything, so you can use:

ps -fp $(pgrep "x2goagent|nxnode|bash|tcsh") | egrep -v "^(root|nx)"

If you are not alone, best to contact the others, but you can also look at running processes with ps or one of these to see what is running:

top -u <username>

Press q to exit top.

If you determine it’s safe:

sudo reboot

The chisel: services and processes
If you are not getting to the desktop screen using either McGill VPN + NoMachine or X2Go, you can try the other one. With X2Go, also try a remote session (e.g. MATE, KDE, GNOME, etc) if you were using “connect to the local desktop”.

If you’re having difficulties with NoMachine but it was working before, you can try restarting the NX server:

sudo systemctl restart nxserver.service

If it appears you are connecting, but the local session (that includes connecting with NoMachine, and with X2Go with the option “connect to the local desktop”) is unresponsive or giving you trouble, you can restart the X desktop manager. This will end your local session, similarly to doing ctrl-alt-backspace when at the computer. It’s not quite as drastic as rebooting ALTHOUGH it will affect other users with remote sessions, so DON’T try this unless you are indeed the only person logged in (use the ps command to check):

sudo /usr/sbin/service lxdm restart

Otherwise, once you’re logged in via a terminal, you can look at running processes with top or ps commands. If a process is obviously causing a problem, you can stop it with:

kill <PID>

where <PID> stands for the process ID # listed by ps or top. One example is the screensaver process, which if frozen will prevent you from logging in, possibly showing only a black screen, or the lock screen. You can only kill your own processes. If nothing in the list of processes pops out at you, probably best to ask for help.


If you’re able to log in via ssh through login.bic, but you get a timeout error or connection refused when trying to connect directly to your workstation while using the MGill VPN, it may be useful to verify your VPN IP in case McGill added new IP ranges that would be blocked by the workstation firewall.

X2GO: black screen or the screen is not responsive

When using remote access with X2GO and MATE, connection is successful but there is a black screen, or the screen is not responsive. This problem seems to be related to the presence of two active screensaver services, one for GNOME and one for MATE. To fix it, disable the GNOME screensaver.:

  1. Open the preferences for the GNOME screensaver with the command:
  2. Change the Mode to ‘Disable Screen Saver’
  3. Optional: Preferences for the MATE screensaver can be modified with the command:
1 Like