X11 forwarding support
infokiller opened this issue · 14 comments
Does ET support X11 forwarding (which corresponds to the SSH -X and -Y CLI params)?
For context, my motivation for this is clipboard integration (for example, copying something in vim running on the SSH server and pasting it in my client host browser).
I tried enabling it in ~/.ssh/config using ForwardX11Trusted yes, but the verbose logs show that this config line isn't supported.
Thanks!
You can use port tunneling to tunnel your ssh port and use ssh to get port forwarding.
Thanks for your quick response!
Can you please clarify how would one go about using port tunneling to get X11 forwarding?
Typically I just ssh -Y <hostname> to activate X11 forwarding, and then $DISPLAY is set to something like localhost:10.0 in the SSH shell session on the remote. Then, SSH seems to listen on port 6010 on the remote host and forward X11.
If I try something like et -r 6010:22 -N <hostname> it doesn't work for me (copying to clipboard just hangs).
et -t 6010:22 (hostname)
Then in another terminal
ssh -Y localhost -p 6010
Thanks, that works indeed!
For the record, I had to specify the port using a separate -p parameter.
Hi,
I'm trying to use et with X11 forwarding, from a chromebook client (with default debian-based linux image) to a linux (ubuntu) PC.
The first command works fine: et -t 6010:22 <hostname> It gives me a shell on the linux PC, but starting an X application returns "Error: can't open display" (as expected)
I leave that shell open and in a new terminal window on the client, I run the second command.
The second command fails: ssh -Y localhost:6010 returns: "ssh: Could not resolve hostname localhost:6010: Name or service not known".
Can this have something to do with the way Linux is deployed on a chromebook?
Best regards,
Vic
Ssh doesn't support the colon notation and you need to use the -p switch
Oops, true! Second command should be ssh -Y -p 6010 localhost. Thanks!
@MisterTea Your proposed solution doesn't work for me. Would it be possible at all to just make it an extra flag on ET to forward X11?
@reeseovine AFAIK it's not straightforward because ET doesn't implement the SSH protocol (see https://eternalterminal.dev/howitworks/) and for good reasons. To get all SSH features with ET, I wrote a simple script you can try: https://github.com/infokiller/ssh-et
@infokiller that script looks cool! Feel free to submit a PR putting a copy of that script in the scripts/ folder of this repo.
Thanks, I'll submit a PR.
ET is great. I'm thinking of going further and making it a drop in replacement for ssh. ET can be toggled via an option, either in the command line (for example ssh -oET=yes ...) and in the config files (~/.ssh/config etc). This way you can use ET with anything that uses uses ssh behind like rsync or VSCode (with the remote ssh extension).
I'm thinking of implementing a wrapper around OpenSSH), similar to ssh-et, but with the ability to understand ET-specific settings (a simple toggle of UseET=yes/no is sufficient for my current use, but perhaps more customization will be needed in the future).
From the command line, you would use it like this: ssh [your_ssh_options] -oUseET=yes <host>. The wrapper will intercept the UseET option and will only forward to ssh the other options (and if UseET is set to yes, the wrapper will create an ET tunnel).
For ~/.ssh/config, OpenSSH can ignore unknown options with the IgnoreUnknown yes option, so adding UseET=yes won't cause errors when using OpenSSH without the wrapper.
For example, let's say you have this ~/.ssh/config:
Host my-server
HostName my-server.my-domain.com
IdentityFile ~/.ssh/id_ed25519_my_server
ForwardX11 yesIf you want to use ET by default when connecting to my-server, you will edit it as following:
# Put this at the start of `~/.ssh/config` to prevent SSH errors for ET options
Host *
IgnoreUnknown UseET
Host my-server
HostName my-server.my-domain.com
IdentityFile ~/.ssh/id_ed25519_my_server
ForwardX11 yes
UseET yesHave ya tried Xpra1 at all? I use it for any X11 forwarding and it's exquisite, what X11 forwarding should be. It's already designed to handle/recover from unstable connections, too, like screen or tmux, but for GUI's or even entire desktop sessions. They call it "screen for X" even.
With --ssh option, we can specify the ssh command to use with Xpra (which already uses paramiko instead of standard ssh by default). Using a server in which et is already working, I tried Xpra with --ssh="et" but that cause Xpra to hang.
Now I've found ssh-et as well! but it doesn't quite appear to be a drop in replacement. Where ssh fooserver works, and so does et fooserver, ssh-et fooserver returns:
ssh-et: Found open port: 52200
ssh-et: Running: et -t 52200:22 -N fooserver
et: ET running, feel free to background...
ssh-et: Running: ssh -p 52200 -oHostName=127.0.0.1 -oHostKeyAlias=fooserver fooserver
kex_exchange_identification: read: Connection reset by peer
Connection reset by 127.0.0.1 port 52200I did find another server that ssh-et ran on, after confirming mess with the saved associated with localhost fingerprints, and forced to login with password instead of defined key:
ssh-et: Found open port: 52201
ssh-et: Running: et -t 52201:22 -N fooserver2
et: ET running, feel free to background...
ssh-et: Running: ssh -p 52201 -oHostName=127.0.0.1 -oHostKeyAlias=fooserver2 fooserver2
The authenticity of host 'fooserver2 ([127.0.0.1]:52201)' can't be established.
ED25519 key fingerprint is blah.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:453: fooserver2.arizona.edu
~/.ssh/known_hosts:457: FooServer2.arizona.edu
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'fooserver2' (ED25519) to the list of known hosts.
C@fooserver2's password:
Last login: today from ::1
[...]
Now, I tried Xpra with --ssh="ssh-et" and... Xpra returns a Connection failed error. Not a problem since I'm just sharing info with everyone for now. I imagine figuring this out might be nice for when VPN disconnects every 24 hours and Xpra session, instead of detaching like screen might when connection lost, keeps running and remains responsive. That would be sick!