Discussion:
ssh -Y behaviour change
Brett Mahar
2018-09-11 22:20:24 UTC
Permalink
Hi to all in OpenBSD-land!

I recently updated my amd-64-current machine to the Sept 7th snapshot (previous snapshot was July 17th).

Prior to update both firefox and iridium browsers were able to be run using 'ssh -Y' as another user on the same machine. Now they do not run - firefox never finishes launching and iridium has a popup windown that says 'page unresponsive'.

I looked in the man page, mailing list archives and FAQ for following current but could not see any config options that might allow this script to work again.

My script:

#!/bin/ksh

ssh -Y -i /home/brett/.ssh/web_id ***@127.0.0.1 \
'/usr/local/bin/firefox https://www.coil.com' \
2>&1 >/dev/null &

I know `ssh -X` is more secure, I use this when I can but use the `ssh -Y` version when I need ability to copy and paste.

Is there some config I can change so this will work again?

Thanks,
Brett.
Solene Rapenne
2018-09-12 06:13:27 UTC
Permalink
Post by Brett Mahar
Hi to all in OpenBSD-land!
I recently updated my amd-64-current machine to the Sept 7th snapshot (previous snapshot was July 17th).
Prior to update both firefox and iridium browsers were able to be run using 'ssh -Y' as another user on the same machine. Now they do not run - firefox never finishes launching and iridium has a popup windown that says 'page unresponsive'.
I looked in the man page, mailing list archives and FAQ for following current but could not see any config options that might allow this script to work again.
#!/bin/ksh
'/usr/local/bin/firefox https://www.coil.com' \
2>&1 >/dev/null &
I know `ssh -X` is more secure, I use this when I can but use the `ssh -Y` version when I need ability to copy and paste.
Is there some config I can change so this will work again?
Thanks,
Brett.
I think you are supposed to use ssh -XY when using a remote X11 app.
Brett Mahar
2018-09-12 09:15:22 UTC
Permalink
On Wed, 12 Sep 2018 08:13:27 +0200
Solene Rapenne <***@perso.pw> wrote:

| Brett Mahar <***@coiloptic.org> wrote:

| > I recently updated my amd-64-current machine to the Sept 7th snapshot (previous snapshot was July 17th).
| >
| > Prior to update both firefox and iridium browsers were able to be run using 'ssh -Y' as another user on the same machine. Now they do not run - firefox never finishes launching and iridium has a popup windown that says 'page unresponsive'.
...
| > Is there some config I can change so this will work again?
| >
| > Thanks,
| > Brett.



|
| I think you are supposed to use ssh -XY when using a remote X11 app.
|

Hi Solene,

That was not the behaviour before and unfortunately still does not work now.

Cheers,
Brett.
Solene Rapenne
2018-09-12 12:03:17 UTC
Permalink
Post by Brett Mahar
On Wed, 12 Sep 2018 08:13:27 +0200
| > I recently updated my amd-64-current machine to the Sept 7th snapshot (previous snapshot was July 17th).
| >
| > Prior to update both firefox and iridium browsers were able to be run using 'ssh -Y' as another user on the same machine. Now they do not run - firefox never finishes launching and iridium has a popup windown that says 'page unresponsive'.
...
| > Is there some config I can change so this will work again?
| >
| > Thanks,
| > Brett.
|
| I think you are supposed to use ssh -XY when using a remote X11 app.
|
Hi Solene,
That was not the behaviour before and unfortunately still does not work now.
Cheers,
Brett.
do you have X11Forwarding yes in your sshd_config?

If so, can you check output if you add -v to ssh command line, lines related to
x11?
Brett Mahar
2018-09-12 22:14:10 UTC
Permalink
On Wed, 12 Sep 2018 14:03:17 +0200
Solene Rapenne <***@perso.pw> wrote:


| > | Brett Mahar <***@coiloptic.org> wrote:
| >
| > | > I recently updated my amd-64-current machine to the Sept 7th snapshot (previous snapshot was July 17th).
| > | >
| > | > Prior to update both firefox and iridium browsers were able to be run using 'ssh -Y' as another user on the same machine. Now they do not run - firefox never finishes launching and iridium has a popup windown that says 'page unresponsive'.


|
| do you have X11Forwarding yes in your sshd_config?
|
| If so, can you check output if you add -v to ssh command line, lines related to
| x11?

Hi Solene,

Yes I have X11Forwarding yes

I added -v to the ssh command, output is below, the only line that stands out is:

debug1: confirm x11
[11321:1527161448:0913/074849.948275:ERROR:process_metrics_openbsd.cc(164)] Not implemented reached in bool base::GetSystemMemoryInfo(base::SystemMemoryInfoKB *)

If I use a similar command with Links browser, it still works as normal:
$ ssh -v -Y -i /home/brett/.ssh/rmit_id ***@127.0.0.1 links -g &
So maybe it is by coiincidence that the behaviour of Firefox, Chrome, and Iridium has altered in the last month or so?

Brett.


=======================================================================================================

Full output using Iridium browser:

[1] 11492
$ OpenSSH_7.8, LibreSSL 2.8.0
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/brett/.ssh/rmit_id type 0
debug1: identity file /home/brett/.ssh/rmit_id-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.8
debug1: match: OpenSSH_7.8 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 127.0.0.1:22 as 'rmit'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-***@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-***@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:qJEIrukQMIjqA8LT8vyaXBG56JZMZ8hjU62BRZ1yJYc
debug1: Host '127.0.0.1' is known and matches the ECDSA host key.
debug1: Found key in /home/brett/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: ECDSA SHA256:TKDpw9aM8mq+fskjBc2G+wEYDasolxkCYwe0f6hDpX0 /home/brett/.ssh/id_ecdsa
debug1: Authentications that can continue: publickey
debug1: Offering public key: RSA SHA256:yKz+QK3wcQoNs/Bkx14V/WEnZ6QQ5WSMdpDQ/Itqcy4 /home/brett/.ssh/rmit_id
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 127.0.0.1 ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-***@openssh.com
debug1: Entering interactive session.
debug1: pledge: exec
debug1: client_input_global_request: rtype hostkeys-***@openssh.com want_reply 0
debug1: Remote: /home/rmit/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/rmit/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending command: iridium
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 4649
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 5579
debug1: channel 2: new [x11]
debug1: confirm x11
[11321:1527161448:0913/074849.948275:ERROR:process_metrics_openbsd.cc(164)] Not implemented reached in bool base::GetSystemMemoryInfo(base::SystemMemoryInfoKB *)
debug1: client_input_channel_open: ctype x11 rchan 5 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 12975
debug1: channel 3: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 6 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 18494
debug1: channel 4: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 20403
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 33893
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 31712
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 24089
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 2375
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 40603
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 22604
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 3408
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
*** autoupdate was enabled, overriding with false
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 20899
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 43234
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 40010
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 15836
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 23694
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 32930
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 8 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 12858
debug1: channel 6: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 7
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 41647
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 6: FORCE input drain
debug1: channel 6: free: x11, nchannels 7
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 26898
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 3238
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 18693
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 40890
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 6140
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: client_input_channel_open: ctype x11 rchan 8 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 20612
debug1: channel 6: new [x11]
debug1: confirm x11
debug1: channel 5: free: x11, nchannels 7
debug1: channel 6: FORCE input drain
debug1: channel 6: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 12037
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: client_input_channel_open: ctype x11 rchan 7 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 2987
debug1: channel 5: new [x11]
debug1: confirm x11
debug1: channel 5: FORCE input drain
debug1: channel 5: free: x11, nchannels 6
debug1: channel 3: FORCE input drain
debug1: channel 4: FORCE input drain
debug1: channel 3: free: x11, nchannels 5
debug1: channel 4: free: x11, nchannels 4
debug1: channel 1: FORCE input drain
debug1: channel 2: FORCE input drain
debug1: channel 1: free: x11, nchannels 3
debug1: channel 2: free: x11, nchannels 2

Then on exit:

debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype ***@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 368556, received 481360 bytes, in 159.9 seconds
Bytes per second: sent 2305.2, received 3010.7
debug1: Exit status 0

=======================================================================================================
Command that works (using Links browser in graphical mode):

$ ssh -v -Y -i /home/brett/.ssh/rmit_id ***@127.0.0.1 links -g &
[2] 79988
$ OpenSSH_7.8, LibreSSL 2.8.0
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/brett/.ssh/rmit_id type 0
debug1: identity file /home/brett/.ssh/rmit_id-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.8
debug1: match: OpenSSH_7.8 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 127.0.0.1:22 as 'rmit'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-***@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-***@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:qJEIrukQMIjqA8LT8vyaXBG56JZMZ8hjU62BRZ1yJYc
debug1: Host '127.0.0.1' is known and matches the ECDSA host key.
debug1: Found key in /home/brett/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: ECDSA SHA256:TKDpw9aM8mq+fskjBc2G+wEYDasolxkCYwe0f6hDpX0 /home/brett/.ssh/id_ecdsa
debug1: Authentications that can continue: publickey
debug1: Offering public key: RSA SHA256:yKz+QK3wcQoNs/Bkx14V/WEnZ6QQ5WSMdpDQ/Itqcy4 /home/brett/.ssh/rmit_id
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 127.0.0.1 ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-***@openssh.com
debug1: Entering interactive session.
debug1: pledge: exec
debug1: client_input_global_request: rtype hostkeys-***@openssh.com want_reply 0
debug1: Remote: /home/rmit/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/rmit/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending command: links -g
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 41437
debug1: channel 1: new [x11]
debug1: confirm x11


=======================================================================================================
Darren Tucker
2018-09-12 11:51:42 UTC
Permalink
On 12 September 2018 at 16:13, Solene Rapenne <***@perso.pw> wrote:
[...]
Post by Solene Rapenne
I think you are supposed to use ssh -XY when using a remote X11 app.
Nope, both -X and -Y enable ForwardX11, but -Y also enables
ForwardX11Trusted. Unfortunately I don't see anything in the OpenSSH
7.7->7.8 changelog (https://www.openssh.com/txt/release-7.8) that
would explain the observed change in behaviour.

$ egrep -C2 "'(X|Y)'" ssh.c
options.forward_x11 = 0;
break;
case 'X':
options.forward_x11 = 1;
break;
--
config_test = 1;
break;
case 'Y':
options.forward_x11 = 1;
options.forward_x11_trusted = 1;
--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Luke A. Call
2018-09-12 15:32:37 UTC
Permalink
Post by Brett Mahar
I know `ssh -X` is more secure, I use this when I can but use the `ssh -Y` version when I need ability to copy and paste.
While this probably doesn't solve your main problem, it might be useful afterward. For what it's worth, I have used ssh -X extensively and copy/paste successfully, so it is a little more secure than ssh -Y for most things. I have added some config to help it work between apps that used different clipboards, to ease interoperability, in the ~/.Xdefaults of the user running X:

XTerm*selectToClipboard: true
*VT100*translations: #override \
Ctrl Shift <Key>V: insert-selection(CLIPBOARD, CUT_BUFFER1) \n

...and where that doesn't work (depends on which apps and in which direction I copy/paste between them), I have a couple of scripts using the xc command (from ports/packages) to work around that.

Then workarounds: I only use ssh -Y occasionally, for a very few apps that seem to only function with it. This is not an area where I have deep understanding, but I did a bunch of web searches, reading and some experimenting. I am also careful what I copy to the clipboard, because any app (probably including those running as different users) can see it, And when that really breaks down (eg, multiline copy/paste from browser to a text-mode app), I just paste into a world-readable text file from one user, and pull it out as the other user.

If any of this is bad practice I would appreciate the feedback.

(I probably wouldn't use ssh -X much, if I could start more than one X session in different ctrl-alt-fX consoles, as different users, to run at the same time as I used to always do on debian.)
Loading...