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.
)
… Huh, it works, thanks!
(~/.config/fish/config.fish in my case.)
I could’ve sworn I’d tried that already,
but I guess I must’ve messed up somehow while juggling all the other stuff in the switch to opensuse..
I never ran into this issue at all with other distros,
so it’s only after switching to opensuse that I even encountered this
so I only just learned about xhost at all while researching it.
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
ssh enabled
open ssh port N/A #2023-03-23(03:51) open
#
PolicyKit default privileges:
Default
Restrictive
Standard
-> Easy
#
CPU Mitigations
Auto + No SMT
-> Auto
Off
Manually
#
Major Linux Security Module
None
SELinux
-> AppArmor
and:
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?
Environment? I’m using kde if that’s what you mean.
If you mean, like, environment variables in my shell or something, I dunno?
My $XAUTHORITY is apparently at /run/user/1000/xauth_[some hash or something?]
but I never touched that manually,
or messed with anything I can think of that would affect that?
And
And like, putting into my ~/.config/fish/config.fish
if test -z "$SSH_CLIENT"
xhost +LOCAL: &>/dn
end
made it work for me now,
so… there’s nothing wrong with doing it that way, right?
Yes. And if XAUTHORITY is not defined, programs try ~/.Xauthority location and fail to access X server because it does not exist (or has the wrong content).
Meaning you have ssh’d in to a computer running opensuse and run stuff with DISPLAY=:0
and it worked for you without needing to do anything further?
As for the file /etc/ssh/sshd_config,
I just checked and I don’t have it at all.
All I have is my keys,
and two empty sub-dirs (ssh_config.d/ and sshd_config.d/)
Maybe the difference is from…
kde
and/or tumbleweed
and/or something in other options I chose during installation
and/or just something that was changed between your installation and mine
and/or I messed with the dir and forgot about it (maybe that’s where sshd_config.d/ came from?)
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
Duration: 1.055s
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)
CPU: 601ms
Jun 19 08:26:26 thinkbook systemd[1]: Starting Distribution Upgrade...
Jun 19 08:26:26 thinkbook nm-online[3958]: [41B blob data]
Jun 19 08:26:26 thinkbook systemd[1]: Started Distribution Upgrade.
Jun 19 08:26:27 thinkbook zypper[3963]: Loading repository data...
Jun 19 08:26:27 thinkbook zypper[3963]: Reading installed packages...
Jun 19 08:26:27 thinkbook zypper[3963]: 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[3963]: Computing distribution upgrade...
Jun 19 08:26:27 thinkbook zypper[3963]: Nothing to do.
Jun 19 08:26:27 thinkbook systemd[1]: dup.service: Deactivated successfully.
3400g:~ #
Running Yast on remote host:
Command ssh -X 3400g yast2 issued on host thinkbook readily starts Yast on host 3400g.
No. It is defined and exported by display manager when it starts your GUI session and is only inherited by programs started as part of your GUI session. Your ssh session runs outside of GUI session.
Have you even tried to read the topic I mentioned?
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,
playing alerts,
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.
No, you should not edit anything in /usr. You should either create file in /etc/ssh/sshd_config.d or copy the whole /usr/etc/ssh/sshd_config into /etc/ssh.