10

So my workstation at work got rebooted and I'm currently not logged in physically there with a graphical session. I have ssh access to it, and I can start a new X windows session and use my graphical applications remotely. I was just wondering if there was a way to start the main desktop session remotely, so that I can then connect and interact with it and next time I get in front of the workstation, I can just pick up where I left off...

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
FrenchKheldar
  • 203
  • 1
  • 2
  • 6

2 Answers2

6

I'd suggest a look at the following projects (although I kind of doubt that xpra can handle a whole session)

  • the x2go terminal server project seems pretty well for this task (see this Linux Magazine article); however it could be a little over-the-top for a smallish setup.

  • xpra:

    Xpra is 'screen for X': it allows you to run X programs, usually on a remote host, direct their display to your local machine, and then to disconnect from these programs and reconnect from the same or another machine, without losing any state. It gives you remote access to individual applications.

And have a look around, some other tools have also been mentioned here already (e.g. here).

(Something more direct might be possible (see this note of "startx over ssh"), but it the "picking up where I left part" will not work.)

Edit Something just crossed my mind -- if you use some desktop manager that supports auto-login (say, slim, nodm, gdm3, kdm); you should be able to start a session for one specific user on :0 (via, say, /etc/init.d/gdm3 start).

And there is XDMCP (with security concerns).

Community
  • 1
sr_
  • 15,224
  • 49
  • 55
  • Thanks these are interesting. But I guess there is no way to perform a remote login that accomplish the same thing as a physical login (ie start display:0). – FrenchKheldar Oct 25 '12 at 16:45
2

You can start a console GUI session remotely: run startx. However, that's likely not to work because you'll lack the permission. On most setups, only the user physically logged in on the console is allowed to use the console.

Different distributions have adopted different mechanisms to control who can start an X session on the console. I believe that on RHEL this is done through systemd, but I don't know how.

If you start an X application on the console display, you won't be able to interact with it remotely. There are a few exceptions such as Emacs that are capable of connecting to multiple displays, but in general X applications open a connection to the X display when they start and never look back. You can use Xmove or Xpra to mediate between the X server and the application; an X application started inside Xmove or Xpra can be moved to a different X server (like detaching and attaching a screen session).

Another option once you've started the console X session would be to interact with it remotely. You can use X11vnc for that, and access the remote session with a VNC client.

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
  • Well that's more what I had in mind. If I can run startx then I can connect to the main X server (:0) and interact with my main desktop. I will try and let you know what happens. – FrenchKheldar Oct 26 '12 at 22:00
  • @FrenchKheldar *I will try and let you know what happens.* What happened? – Piotr Dobrogost Jul 24 '17 at 12:44
  • 1
    *However, that's likely not to work because you'll lack the permission.* Could you please elaborate on this in your answer? Does it mean that remote users are not supposed to start X server at all? If not then is there any accepted/canonical way of starting X server remotely? Alternatively you might want to add links answering my questions. – Piotr Dobrogost Jul 24 '17 at 13:03
  • 1
    @PiotrDobrogost Users are supposed to be logged in on the console in order to start a GUI session on the console. That's because if you aren't logged in on the console, you don't have access to the console peripheral. You can start an X server remotely, but it can't access the console, e.g. it can be Xvfb (displaying in a framebuffer in memory) but not Xorg (displaying on an actual screen). Only the administrator (root) may take control of the console (including starting an X server there) without being logged in on it. – Gilles 'SO- stop being evil' Jul 24 '17 at 22:07
  • @PiotrDobrogost If I recall correctly, it didn't work. But it's been a while ! – FrenchKheldar Jul 25 '17 at 14:53
  • I was hoping this question was referring to simulating a console login via gdm3 (etc) from an ssh connection. The nextcloud sync depends on GUI right now, or writing one's own cron/inotify/systemd-path code to do it. I just want to do a regular console login, but without sitting in front of the workstation. Any ideas? – Jack Wasey May 29 '20 at 19:41
  • @JackWasey If you aren't at the console, then by definition you aren't at the console. If you want a GUI remotely, just use SSH as usual, with X11 forwarding enabled. – Gilles 'SO- stop being evil' May 29 '20 at 20:51
  • Agreed - it is somewhat ridiculous of me, and I really just need to bite the bullet and set up automated nextcloud syncing without dependency on a logged-in desktop environment (not just one app). There are also environment differences with Xvnc etc compared to a regular GDM session, which I am sure are possible to resolve, e.g., gnome-keyring seems to be screwed up, and superuser prompts fail, e.g. to start gparted over a VNC-only session, whereas VNC to a GDM/console desktop does allow these things. – Jack Wasey May 30 '20 at 14:13