[Solved] startx over SSH? (not VNC!)

chrabyrd · 2018-10-09 14:53:42

Hi all!

I have a remote machine (htpc) that's connected to a TV 100% of the time. I gain access to it over ssh/vnc for everything except watching stuff. I'm currently running the two VNC servers supplied in the TigerVNC package, `vncserver` and `x0vncserver`. I'm not running any display managers, just using xinit to run xfce4. `x0vncserver` allows control over the current session, and for it to run correctly the remote machine needs an instance of xfce up and running. However, when I try to run startx over SSH, I get an error message saying "/usr/lib/Xorg.wrap: Only console users are allowed to run the X server". Is there a way to alias myself so that xorg thinks I'm using the console of the remote machine directly, instead of over SSH?

To clarify, I do not want to give the startx command over SSH and have an immediate graphical instance on my local machine. Rather I'd like the remote machine to think that the startx command came from the keyboard attached to it and start its own local instance of xfce, so that I can then access it via TigerVNC's `x0vncserver` service.

Thanks for the help!

Last edited by chrabyrd (2018-10-13 07:42:08)

olive · 2018-10-09 16:00:11

Edit (or create) the file /etc/X11/Xwrapper.config with the following content:

allowed_users=anybody
needs_root_rights=yes

see man Xorg.wrap for more information. Note that it will just do what you ask, launch the X server on the remote machine. By default you will not be able to interact with it with the distant keyboard or mouse. But it can do what you want if you configure it correctly.

Last edited by olive (2018-10-09 16:05:13)

qinohe · 2018-10-09 16:05:33

There is another way that don't need root for X.

On the remote machine:
Set your user to autologin in '/etc/systemd/system/getty@tty1.service.d/override.conf'

Add this to your 'zprofile' or 'bash_profile'

if [[ ! $DISPLAY && $XDG_VTNR -eq 1 ]]; then
  exec startx
fi

See: https://wiki.archlinux.org/index.php/Xi … X_at_login &
https://wiki.archlinux.org/index.php/Ar … atic_Login (was the first I know it was documented)

Like @olive says you still not able to interact directly.

olive · 2018-10-09 16:11:51

@qinohe Sorry I have updated my post while you answered it.

I was saying indeed that your way will not answer his question (launch startx over ssh) but autolaunch the Xserver (you are correct, I missed the systemd configuration); which is different. You can achieve the same thing with a login manager (for example lightdm).

Last edited by olive (2018-10-09 16:23:07)

qinohe · 2018-10-09 16:17:44

@olive, maybe he don't want it running all the time, I don't know he doesn't say but he does say:

the remote machine needs an instance of xfce up and running

Well my answer is based on that.

edit:@olive first autologin then startx I did say that

edit2:@olive why add the overhead of a DM when you don't really need one?

edit3:@olive, don't worry , but it's a lot of edits, anyway, but to be certain about this, you can't remotely start X over SSH, I know.

Last edited by qinohe (2018-10-09 16:34:21)

olive · 2018-10-09 16:35:00

qinohe wrote:

edit2:@olive why add the overhead of a DM when you don't really need one?

A display manager like lightdm is barely an overhead. The solution of using a display manager is more standard. Moreover, the solution you suggest will launch the X server when you reach the systemd multi-user target, not the systemd graphical target. If you make a service (other than the display manager that you don't need) that depends on the graphical target, it will not be launched with your configuration.

If for some reason you want to boot the machine without launching the X server (for example because there is a problem with it) you can use the boot manager and add `systemd.unit=multi-user.target` to force the multi-user target instead of the graphical one. This will also not work if the X server is launched in the multi-user target like you suggest.

Last edited by olive (2018-10-09 16:35:33)

olive · 2018-10-09 16:41:23

qinohe wrote:

edit3:@olive, don't worry , but it's a lot of edits, anyway, but to be certain about this, you can't remotely start X over SSH, I know.

With the configuration I suggest, you can.

Last edited by olive (2018-10-09 16:41:42)

qinohe · 2018-10-09 16:43:40

@ olive, I guess this not true, I have an archiso explicitly built like this booting into the graphical target and starting X automatically (well it starts a DM I made in bash) but you wouldn't need it, it starts without it too.
So if you don't have more than one WM it would be overhead to have a DM, at least I think so

edit:@olive it becomes a mess with all the edits

Last edited by qinohe (2018-10-09 16:45:04)

olive · 2018-10-09 17:01:28

qinohe wrote:

@ olive, I guess this not true, I have an archiso explicitly built like this booting into the graphical target and starting X automatically (well it starts a DM I made in bash) but you wouldn't need it, it starts without it too.
So if you don't have more than one WM it would be overhead to have a DM, at least I think so

I have said barely an overhead in the sense that using lightdm is light enough to not make a real difference: it is only 2Mb and does not slow down the boot in practice. As I said, the solution of auto launching it the way you suggest has the problem to not distinguish the multi-users from the graphical target. More standard configuration mean better tested system. I have just realized the problem about the systemd target, maybe there are other problems we didn't realize.

Sorry about the edits. I edited my posts while at the same time you answered to the old version. I really should double read my posts before I post them...

qinohe · 2018-10-09 17:15:50

Okay, lets not fight over a DM, normally that would be personal taste, but, please before we agree that being so;

the solution of auto launching it the way you suggest has the problem to not distinguish the multi-users from the graphical target

I don't get it , than why does it work in the first place? The way I said works while booting into the graphical target, at least here it does, or am I also overseeing something?

olive · 2018-10-09 17:54:47

qinohe wrote:

I don't get it , than why does it work in the first place? The way I said works while booting into the graphical target, at least here it does, or am I also overseeing something?

But if you boot into the multi-users target, you expect that the X server will not be launched; it will in your case. Another related thing that won't work (the way you expect) is `systemctl isolate multi-users.target` which is supposed to stop the X server and return you to pure multi-users.target.

The graphical target depends on the multi-users target and launch ("wants" in the systemd sense) the display-manager.service. I think that if you enable the graphical target without enabling (or maybe even installing) a display manager, then the multi-users target will be launched (as a requirement of the graphical target), which will auto launch startx. A display manager service cannot be launched since there is none. This is a working but buggy configuration. You don't have a multi-users target that work as expected leading to, among others, the problems I mention previously. Moreover if you install a display manager and enable it afterwards, the X server will be launched two times: with the auto launching of startx within the multi-users target and once again by the display manager service. This will of course fail.

Last edited by olive (2018-10-09 18:26:13)

qinohe · 2018-10-09 19:16:09

olive wrote:

But if you boot into the multi-users target, you expect that the X server will not be launched; it will in your case. Another related thing that won't work (the way you expect) is `systemctl isolate multi-users.target` which is supposed to stop the X server and return you to pure multi-users.target
The graphical target depends on the multi-users target and launch ("wants" in the systemd sense) the display-manager.service. I think that if you enable the graphical target without enabling (or maybe even installing) a display manager, then the multi-users target will be launched (as a requirement of the graphical target), which will auto launch startx. A display manager service cannot be launched since there is none. This is a working but buggy configuration. You don't have a multi-users target that work as expected leading to, among others, the problems I mention previously. Moreover if you install a display manager and enable it afterwards, the X server will be launched two times: with the auto launching of startx within the multi-users target and once again by the display manager service. This will of course fail.

Yes multi-users does launch X server and `systemctl isolate multi-users.target` doesn't stop X, the way I say. But would this be worse than running X as root?

Of course if you start using a DM auto launching of X needs to be disabled. I cannot speak for other DM's, mine is only working because there is 'autologin' in the first place, it's a crappy POS but working, so maybe your right, maybe he should go with a root enabled X, but I know a lot of devs also from Arch say you shouldn't login to X as root, that was my rationale to react.

olive · 2018-10-09 19:35:17

Yes multi-users does launch X server and `systemctl isolate multi-users.target` doesn't stop X, the way I say. But would this be worse than running X as root?

Running the X server as root was the standard way a few years ago and remain necessary with some graphic drivers. If you login normally with a display manager, X will usually run as root too. Because it run before you login (to display the display manager), it cannot run as you. It was needed because the X server access the hardware directly. Now a way to run the server as a usual user is supported.

Please note that it is the X server itself that run as root; you do not login as root and your Desktop/Windows manager run as you, a regular user; you launch startx as you (which launches Xorg.wrap which is suid and can launch the X server as root). It is safe unless you are paranoid that the X server will do evil thing. That can only happen if there is a serious bug in it.

Of course if you start using a DM auto launching of X needs to be disabled. I cannot speak for other DM's, mine is only working because there is 'autologin' in the first place, it's a crappy POS but working, so maybe your right, maybe he should go with a root enabled X, but I know a lot of devs also from Arch say you shouldn't login to X as root, that was my rationale to react.

A normal display manager is graphical, so the X server is needed to display the display manager. Unless of course you have some strange console based display manager. Again do not mistake running the X server as root and login as root (see above).

Last edited by olive (2018-10-09 19:52:16)

qinohe · 2018-10-09 19:56:30

olive wrote:

Running the X server as root was the standard way a few years ago and remain necessary with some graphic drivers. If you login normally with a display manager, X will usually run as root too. Because it run before you login (to display the display manager), it cannot run as you. It was needed because the X server access the hardware directly. Now a way to run the server as a usual user is supported.
Please note that it is the X server itself that run as root; you do not login as root and your Desktop/Windows manager run as a regular user. It is safe unless you are paranoid that the X server will do evil thing. That can only happen if there is a serious bug in it.

That makes sense , I would not have gathered this from the wiki, thanks for explaining.

A normal display manager is graphical, so the X server is needed to display the display manager. Unless of course you have some strange console based display manager. Again do not mistake running the X server as root and login as root (see above).

Get it, system starts X as root and run as user. Yes my display manager is a strange console based thing and needs quite a few little adaptions, files and a little love to work, so POS, but it does work, thanks.

edit:@chrabyrd, you should definitely go with the method @olive suggetst in #2 or use my method and have a somehow crippled system which I live with btw.;)

Last edited by qinohe (2018-10-09 20:38:57)

Arch Linux

#1 2018-10-09 14:53:42

[Solved] startx over SSH? (not VNC!)

#2 2018-10-09 16:00:11

Re: [Solved] startx over SSH? (not VNC!)

#3 2018-10-09 16:05:33

Re: [Solved] startx over SSH? (not VNC!)

#4 2018-10-09 16:11:51

Re: [Solved] startx over SSH? (not VNC!)

#5 2018-10-09 16:17:44

Re: [Solved] startx over SSH? (not VNC!)

#6 2018-10-09 16:35:00

Re: [Solved] startx over SSH? (not VNC!)

#7 2018-10-09 16:41:23

Re: [Solved] startx over SSH? (not VNC!)

#8 2018-10-09 16:43:40

Re: [Solved] startx over SSH? (not VNC!)

#9 2018-10-09 17:01:28

Re: [Solved] startx over SSH? (not VNC!)

#10 2018-10-09 17:15:50

Re: [Solved] startx over SSH? (not VNC!)

#11 2018-10-09 17:54:47

Re: [Solved] startx over SSH? (not VNC!)

#12 2018-10-09 19:16:09

Re: [Solved] startx over SSH? (not VNC!)

#13 2018-10-09 19:35:17

Re: [Solved] startx over SSH? (not VNC!)

#14 2018-10-09 19:56:30

Re: [Solved] startx over SSH? (not VNC!)

Board footer