I’ve read manpages and googled it,
but I’ve gotten conflicting information and none of it seems to work right.
I’m suspecting that the “correct” way to do it might be distro-specific,
so I figured I should try asking here.
The things I’ve tried are like,
setting up a config file (/etc/X0.hosts)
and setting up an autostart login script (using KDE).
If it’s unclear why I need this (or at least, I think it’s what I need in order to accomplish this?)
I often want to ssh into my opensuse laptop from my other (non-opensuse) computer and run something like DISPLAY=:0 xcowsay hi
(well, of course I mean more practically stuff like play a sound or start a timer or do something with the clipboard)
but everytime I restart the opensuse laptop,
I need to first run xhost + on it
Otherwise you just get error messages like:
Authorization required, but no authorization protocol specified
Authorization required, but no authorization protocol specified
(xcowsay:11671): Gtk-WARNING **: 16:04:21.307: cannot open display: :0
Also yeah, I think you’re supposed to use something more specific like xhost +local xhost +localuser
or xhost +localuser:[username]``
or something like that,
but I haven’t yet been able to figure out how too get it working with even just the simplest xhost +local.
I’m not sure xhostis the “correct” way to accomplish what I (think I) need,
but it’s what I found when I googled it…
Although it was a while ago that I first ran into the problem,
and I was juggling so much other stuff that I kinda just gave up and lived with it for a while,
until I finally came back to it and asked here,
so the details of what info I found where and what I tried back then are kinda fuzzy in my mind.
… Meaning you’re already able to ssh into an opensuse computer and run stuff with DISPLAY=:0 by default?
I dunno, I’m using kde, so maybe it’s specific to that?
I originally thought it might be something to do with that ~/.Xauthority “magic cookie” file thing,
but my notes say “apparently not?”
Other than that,
the only maybe relevant things I can find in my old notes are:
installation -> security
firewall disabled #2023-03-23(03:51) tried enabling
open ssh port N/A #2023-03-23(03:51) open
PolicyKit default privileges:
Auto + No SMT
Major Linux Security Module
sudo systemctl enable --now sshd.service # < already enabled?
sudo systemctl enable --now avahi-daemon.service # < already enabled?
sudo systemctl enable --now avahi-daemon.socket # < already enabled?
sudo systemctl enable --now avahi-dnsconfd.service # < only one maybe makes a difference to remember to do?
Will it work tomorrow? Stuff following below works for everybody at every time, to my not so small experience of course. All my hosts run openSUSE Tumbleweed. I never do what you claim you need to do. Ssh works like a charm. No further configuration needed beyond the one shown in my previous post.
Starting service on remote host:
3400g:~ # ssh thinkbook systemctl start dup
Checking status of service on remote host:
3400g:~ # ssh thinkbook systemctl status dup
○ dup.service - Distribution Upgrade
Loaded: loaded (/etc/systemd/system/dup.service; static)
Active: inactive (dead) since Mon 2023-06-19 08:26:27 CEST; 10s ago
TriggeredBy: ● dup.timer
Process: 3958 ExecStartPre=/usr/bin/nm-online (code=exited, status=0/SUCCESS)
Process: 3963 ExecStart=/usr/bin/zypper --non-interactive dist-upgrade (code=exited, status=0/SUCCESS)
Main PID: 3963 (code=exited, status=0/SUCCESS)
Jun 19 08:26:26 thinkbook systemd: Starting Distribution Upgrade...
Jun 19 08:26:26 thinkbook nm-online: [41B blob data]
Jun 19 08:26:26 thinkbook systemd: Started Distribution Upgrade.
Jun 19 08:26:27 thinkbook zypper: Loading repository data...
Jun 19 08:26:27 thinkbook zypper: Reading installed packages...
Jun 19 08:26:27 thinkbook zypper: Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Jun 19 08:26:27 thinkbook zypper: Computing distribution upgrade...
Jun 19 08:26:27 thinkbook zypper: Nothing to do.
Jun 19 08:26:27 thinkbook systemd: dup.service: Deactivated successfully.
Running Yast on remote host:
Command ssh -X 3400g yast2 issued on host thinkbook readily starts Yast on host 3400g.
Hm, I don’t think I fully understand your post right now,
but I’ll keep it in mind for later when I want to do more with background services, thanks!
The stuff I needed to do now that xhost let me do isn’t background service stuff,
but rather interactive scripts.
Ohh, right, of course, I was being stupid. Thank you for pointing that out.
I didn’t understand the relevance at first,
but like I said to karlmistelberger:
I’m talking about interactive stuff like…
controlling volume/output/media on one computer from another,
monkeying with stopwatches and things,
passing stuff between clipboards/selections in GUI tools and input/output of interactive scripts in the shell…
I definitely do know that I need to look in to learning more about how to use systemd properly at some point, though,
so thank you for the tip
– I used the forum’s “bookmark” feature so I can easily find your post again later
(and @karlmistelberger 's as well)
No, I don’t expect that to work although “xhost” can enable it.
I would normally use ssh -X hostname
for this. But that will display on the screen in front of me rather than the screen of the ssh destination computer.
Well yes, except that the xauth magic cookie might be stored elsewhere, depending on your desktop.
Currently, I logged in with “lightdm” and that does store the magic cookie in $HOME/.Xauthority . However, both GDM and SDDM store it elsewhere. Note that we are talking about the displaymanager software for the computer which is the destination of your ssh connection.
This topic is about the same question - how to start GUI program from outside of GUI session. It was slightly more complicated because it had to be started by different user (root), but this discussion still applies - systemd-run offers reasonably portable between Linux distributions way to do it.
Ah, that’s where it is
(it did have already have the line X11Forwarding yes in it).
I’m making a note to remember to check /usr/etc/ too in the future if I can’t find something in /etc/, thanks.
… now that I think about it,
I had actually already gone to the trouble of writing myself a file of detailed notes ages ago like
“linux FSH basic structure and variations cheatsheet”,
but then I completely forgot I had even done that until now.
I had honestly completely forgotten about swapping in non-default display managers as a possibility
(so yeah, I just checked and I’m just using SDDM as you’d expect for kde),
so thanks for pointing out the potential relevancy to me.
I think I had kinda subconsciously replaced the term “display manager” with the term “login manager” in my head
(I think I’ve heard some people do that?),
and I’ve been logging in automatically for a ages, bypassing the login screen completely,
so it kinda just completely fell out of my brain.