How do I connect to an xpra server over ssh and have a tty allocated?

[smac89]

I have a server running via systemd, using the following command:

/usr/bin/xpra start --daemon=no --socket-dir="%t/xpra" --terminate-children=yes --systemd-run=no --html=off --exec-wrapper="%s -lc" --clipboard=GDK

• %s is replaced with the user's shell
• %t is replaced with the user runtime directory (something like /run/1000/user/)

Now I can connect with:

xpra attach ssh:user@remote --start kitty

This works great and displays kitty terminal on my desktop. However, what I would really like to do is to simply run xpra attach ssh:user@remote and I should be dropped into a tty where I can run commands, some of which may open a window or not. The point is that I don't want to have to start a new terminal window in order to run commands on the remote, when I'm already inside a terminal.

Is there any solution to this? I've also tried changing the --ssh option to use ssh -t instead, but this doesn't work.

[totaam]

Please try to describe what you're trying to achieve without specifying a technical solution which may or may not be applicable or practical. (ie: tty)
Sounds to me like you want to start applications on demand, after connecting to the server.
That's what the system tray menu is for. Alternatively you can use xpra control $DISPLAY start yourcommand.

--clipboard=GDK

What is this?

ssh:user@remote

This is deprecated, please use ssh://USER@HOST instead.

[smac89]

Please try to describe what you're trying to achieve without specifying a technical solution which may or may not be applicable or practical. (ie: tty)

Clarification

Right. Basically, I've always connected to my server by doing ssh serveralias (where serveralias is configured in my ~/.ssh/config file). From this ssh session, I can run commands, edit files (usually using terminal editors like nano, vi, micro, etc.). If I know ahead of time that I would need to run a GUI application, I will ssh using the -Y option.

Now that I discovered xpra, I would like to still ssh into my server like I used to, but I would also like to be able to launch apps on the server to appear locally.

What I was trying to say in my original post is that I would like to have a way to use xpra and continue using my local terminal, through ssh to run commands and open windows. As opposed to how I was doing it, which is to have xpra server running, and then having to run xpra attach ssh:user@remote --start kitty to open another terminal where I can run those same commands.

(If it's still unclear why I had to open kitty separately with another xpra command, please scroll down to Sources of error section.)

As for your questions

--clipboard=GDK

What is this?

It is one of the options listed in the manual here: https://xpra.org/manual.html

ssh:user@remote

This is deprecated, please use ssh://USER@HOST instead.

I think I saw the other syntax in the manpage, but I must have missed the part where it encourages the use of the newer syntax. Thanks for the reminder.

Solution

It took some trial and error, but I finally figured it out. I use this systemd service on the server:

[Unit]
Description=xpra display

[Service]
Type=exec
ExecStartPre=/usr/bin/mkdir -p %t/xpra
ExecStart=%s -c 'exec {displayfd}>%t/xpra/displayfd; exec /usr/bin/xpra start --daemon=no --socket-dir="%t/xpra" --session-name="%H" --terminate-children=yes --systemd-run=no --html=off --forward-xdg-open=on --displayfd=$${displayfd}'
ExecStop=/usr/bin/xpra stop
ExecStopPost=/usr/bin/rm -f %t/xpra/displayfd
SyslogIdentifier=Xpra
RestartSec=5s
Restart=always

[Install]
WantedBy=multi-user.target

Also on the server, I put the following bit of code into my ~/.zprofile:

# make use of xpra's DISPLAY if available
function {
	if [ -f "${XDG_RUNTIME_DIR}/xpra/displayfd" ]; then
		local display="$(<${XDG_RUNTIME_DIR}/xpra/displayfd)"
		if [ -n "$display" ]; then
			export DISPLAY=":$display"
		fi
	fi
}

And on my client (locally), I created this service:

[Unit]
Description=xpra client
After=ssh-agent.service

[Service]
Type=exec
ExecStart=/usr/bin/xpra --delay-tray=yes attach ssh://serverhost
ExecStop=/usr/bin/xpra detach ssh://serverhost
Restart=always
RestartSec=3s

[Install]
WantedBy=default.target

Now with both services running, when I SSH into my server, the DISPLAY variable is automatically set (if the server service is running), and I can start making use of xpra without having to launch a separate terminal.

Sources of error

I think it's pretty neat that xpra can be configured to work this way. Maybe that's how it was meant to be used, but I struggled to see that through any of the examples in the docs, until I read the Archwiki for Xpra. In fact, a few of the examples in the manual are what led to my confusion.

Case in point being this one:

xpra start :7 --start=screen

I was under the impression that this command will also work over ssh, but it actually doesn't. When xpra runs over ssh, it attaches the -T option to the ssh command, which means that tty is disabled (now you can see why I focused so much on tty), which also means that screen will be unable to start.

So I kept trying to translate:

xpra start :7 --start=screen

to

xpra [start|attach] ssh://serverhost :7 --start=screen

To no avail. It kept failing with the error:

tput: No value for $TERM and no -T specified
Must be connected to a terminal.

The same goes for another example, which I initially thought would lead to what I was expecting, which was simply a terminal to type commands.

xpra shell ssh://serverhost

This one was also pointing to the same problem (lack of a tty)

Connected (version 2.0, client OpenSSH_9.5)
Authentication (publickey) successful!
ssh server OS is 'linux-gnu'
SSH: 'tput: No value for $TERM and no -T specified'
this server does not support the 'shell' subcommand
SSH EOF on stderr of run-xpra

[totaam]

It is one of the options listed in the manual here: https://xpra.org/manual.html

Yes, but what led you to change the default and is it any better? (and if so, how?)

I think I saw the other syntax in the manpage

I doubt it, it's been purged a while back.

when I SSH into my server, the DISPLAY variable is automatically set

Yes, but every other variable will be missing. Don't do that.
That's what xpra control start is for.

until I read the Archwiki for Xpra

The information there is wrong. It's full of terrible advice.
ie: DISPLAY=:7 screen is a bad idea.

To no avail. It kept failing with the error:

Start an xterm then screen.

When xpra runs over ssh, it attaches the -T option to the ssh command

No, the default is to use paramiko which does not use openssh at all.
Archlinux seems to do something else.

[totaam]

This should be tagged as a perfect summary of why archlinux is not a supported platform.

[smac89]

It is one of the options listed in the manual here: https://xpra.org/manual.html

Yes, but what led you to change the default and is it any better? (and if so, how?)

It was listed as an option in the manual. I didn't get a chance to test if it was better, but I didn't notice a difference using it. I have since removed that option.

I think I saw the other syntax in the manpage

I doubt it, it's been purged a while back.

No, it's still definitely there. See

xpra/fs/share/man/man1/xpra.1

Lines 122 to 127 in 9ab62d8

	For backwards compatibility, SSH mode also supports the syntax:
	\fBssh:[USERNAME[:PASSWORD]@]HOST:DISPLAY\fP but this form does not
	support specifying the SSH port number.
	Older versions also used the form \fBprotocol:host:port\fP, but users
	are encouraged to move to a more standard URI format using \fB://\fP as
	separator.

---

I don't think it's a fair assessment to blame everything on Archlinux. Archlinux builds xpra using the same instructions listed in your README. If the instructions are wrong, then the first place to start is updating them.

Also, like I mentioned, all of the examples I was following came from https://xpra.org/manual.html, under the EXAMPLES section. If you can show that those instructions work the way I expected on something like Ubuntu, then I can accept that the problem is indeed with Archlinux. Otherwise, this is just a case of ineffective documentation.

IMO, the biggest hurdle was deciphering which options/commands belong to the server portion and which ones can only be used on the client. If this separation was clearer, it would be easier to isolate problems. Something like xpra server [options...] or xpra client [options...]

[totaam]

No, it's still definitely there.

If you read the very first line you quoted (emphasis mine):

For backwards compatibility, SSH mode also supports the syntax:

---

I was following came from https://xpra.org/manual.html, under the EXAMPLES section

OK, then let me quote this one then:

Note: using DISPLAY=:7 xterm to start applications against a specific display is not recommended.

---

I can accept that the problem is indeed with Archlinux

The packaging is wrong - missing dependencies, the page you quoted is also quite wrong.

---

the biggest hurdle was deciphering which options/commands belong to the server portion and which ones can only be used on the client

If that's the biggest problem, then we're doing OK.