* [gentoo-user] ssh -X problem [no help sofar on ssh group]
@ 2014-12-20 17:17 Harry Putnam
2014-12-20 19:05 ` J. Roeleveld
2014-12-21 21:32 ` [gentoo-user] " Mark David Dumlao
0 siblings, 2 replies; 8+ messages in thread
From: Harry Putnam @ 2014-12-20 17:17 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: text/plain, Size: 3705 bytes --]
This properly belongs on the ssh group, but posting there has not gotten
any responses... and the list is quite slow to boot.
I like using ssh -X to other lan remotes but with new versions of openssh
or perhaps the configs, it only works 1 way.
I can `ssh -X' to the gentoo host from a debian host but not the other
way round.
Two different versions of openssh appear to be involved. But not sure
how different they are.
RHOST=a debian HOST
LHOST= Gentoo HOST
ssh -vN $RHOST 2>&1|grep "remote software version"
[...] OpenSSH_6.7p1 Debian-3
ssh -vN $LHOST 2>&1|grep "remote software version"
[...] OpenSSH_6.7p1-hpn14v5
One thing I tried to do was to copy the RHOST sshd_config and ssh_config to
LHOST. Restart and try again... there were a few incompatible bits in
the files so after commenting a few out until no config errors.
However ssh -X still displayed the error and would NOT work when:
ssh -X RHOST from LHOST
({Note that plain ssh LHOST or RHOST works in any direction}
Error outut with ssh -X $RHOST "xterm"
,----
| Warning: untrusted X11 forwarding setup failed: xauth key data not generated
| Warning: No xauth data; using fake authentication data for X11 forwarding.
| Invalid MIT-MAGIC-COOKIE-1 keyxterm: Xt error: Can't open display: localhost:10.0
`----
[Full Error output with ssh -vv -X is very lengthy so is attached at the end]
I'm not seeing how to debug this further. So going back to the stock
version of sshd_config ssh_config on gentoo with two changes:
commented out this line:
PasswordAuthentication no
added this:
X11Forwarding yes
------- ------- ---=--- ------- -------
Full sshd_config on LHOST: sudo grep ^[^#] /etc/ssh/sshd_config
------- ------- ---=--- ------- -------
UsePAM yes
X11Forwarding yes
PrintMotd no
PrintLastLog no
UsePrivilegeSeparation sandbox # Default for new installations.
Subsystem sftp /usr/lib/misc/sftp-server
AcceptEnv LANG LC_*
------- Config END -------
------- ------- ---=--- ------- -------
Full ssh_config on LHOST: sudo grep ^[^#] /etc/ssh/ssh_config
------- ------- ---=--- ------- -------
ForwardX11 yes
SendEnv LANG LC_*
------- Config END -------
#######################################################
Now the same info for RHOST
------- ------- ---=--- ------- -------
Full sshd_config on RHOST: ssh root@RHOST "grep ^[^#] /etc/ssh/sshd_config"
------- ------- ---=--- ------- -------
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
AcceptEnv LANG LC_*
ChallengeResponseAuthentication no
IgnoreRhosts yes
HostbasedAuthentication no
KeyRegenerationInterval 3600
LogLevel INFO
LoginGraceTime 120
PermitEmptyPasswords no
PermitRootLogin yes
Port 22
PrintLastLog yes
PrintMotd no
Protocol 2
PubkeyAuthentication yes
RSAAuthentication yes
RhostsRSAAuthentication no
ServerKeyBits 1024
SyslogFacility AUTH
StrictModes yes
Subsystem sftp /usr/lib/misc/sftp-server
TCPKeepAlive yes
UsePAM yes
UsePrivilegeSeparation sandbox
X11Forwarding yes
------- Config END -------
------- ------- ---=--- ------- -------
Full ssh_config on RHOST: ssh root@RHOST "grep ^[^#] /etc/ssh/ssh_config"
------- ------- ---=--- ------- -------
Host *
ForwardX11 yes
SendEnv LANG LC_*
HashKnownHosts yes
------- Config END -------
############################################
############################################
The only thing more I can think to include is the full lengthy output of
ssh -vv -X
[-- Attachment #2: output of ssh -vv -X --]
[-- Type: text/plain, Size: 15368 bytes --]
HOST:gv ~
harry > ssh -vv -X harry@dv 'xterm'
OpenSSH_6.7p1-hpn14v5, OpenSSL 1.0.1j 15 Oct 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to dv [192.168.0.5] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1-hpn14v5
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-3
debug1: Remote is NON-HPN aware
debug1: match: OpenSSH_6.7p1 Debian-3 pat OpenSSH* compat 0x24000000
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ED25519 78:0a:64:ae:48:55:a2:32:f2:ce:75:01:b4:ee:fa:21
debug1: Host 'dv' is known and matches the ED25519 host key.
debug1: Found key in /home/harry/.ssh/known_hosts:2
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/harry/.ssh/id_rsa ((nil)),
debug2: key: /home/harry/.ssh/id_dsa ((nil)),
debug2: key: /home/harry/.ssh/id_ecdsa ((nil)),
debug2: key: /home/harry/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/harry/.ssh/id_rsa
debug1: Trying private key: /home/harry/.ssh/id_dsa
debug1: Trying private key: /home/harry/.ssh/id_ecdsa
debug1: Trying private key: /home/harry/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
harry@dv's password:
debug2: we sent a password packet, wait for reply
debug1: Single to Multithread CTR cipher swap - client request
debug1: Authentication succeeded (password).
Authenticated to dv ([192.168.0.5]:22).
debug1: HPN to Non-HPN Connection
debug1: Final hpn_buffer_size = 2097152
debug1: HPN Disabled: 0, HPN Buffer Size: 2097152
debug1: channel 0: new [client-session]
debug1: Enabled Dynamic Window Scaling
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: need rekeying
debug1: SSH2_MSG_KEXINIT sent
debug1: rekeying in progress
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-qqfAyxQhvSOr/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug1: enqueue packet: 98
debug2: fd 3 setting TCP_NODELAY/SCTP_NODELAY
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug1: Sending command: xterm
debug2: channel 0: request exec confirm 1
debug1: enqueue packet: 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 1
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ED25519 78:0a:64:ae:48:55:a2:32:f2:ce:75:01:b4:ee:fa:21
debug1: verify_host_key: server host key matches cached key
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: set_newkeys: rekeying
debug1: spawned a thread
debug1: spawned a thread
debug1: dequeue packet: 98
debug1: dequeue packet: 98
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: set_newkeys: rekeying
debug1: spawned a thread
debug1: spawned a thread
debug1: SSH2_MSG_NEWKEYS received
debug2: tcpwinsz: 318720 for connection: 3
debug2: channel_input_status_confirm: type 99 id 0
debug2: X11 forwarding request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: tcpwinsz: 318720 for connection: 3
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 41191
debug2: fd 7 setting O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug2: tcpwinsz: 318720 for connection: 3
debug2: tcpwinsz: 318720 for connection: 3
debug2: tcpwinsz: 318720 for connection: 3
debug2: tcpwinsz: 318720 for connection: 3
debug2: tcpwinsz: 318720 for connection: 3
debug2: tcpwinsz: 318720 for connection: 3
debug2: tcpwinsz: 318720 for connection: 3
debug2: tcpwinsz: 318720 for connection: 3
debug2: tcpwinsz: 318720 for connection: 3
debug2: channel 1: read<=0 rfd 7 len 0
debug2: channel 1: read failed
debug2: channel 1: close_read
debug2: channel 1: input open -> drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed
debug2: tcpwinsz: 318720 for connection: 3
debug2: tcpwinsz: 318720 for connection: 3
debug2: channel 0: rcvd ext data 30
debug2: channel 1: rcvd eof
debug2: channel 1: output open -> drain
debug2: channel 1: obuf empty
debug2: channel 1: close_write
debug2: channel 1: output drain -> closed
debug2: channel 0: rcvd ext data 7
debug2: tcpwinsz: 318720 for connection: 3
debug2: channel 1: send close
Invalid MIT-MAGIC-COOKIE-1 keyxterm: debug2: channel 0: written 37 to efd 6
debug2: tcpwinsz: 318720 for connection: 3
debug2: channel 1: rcvd close
debug2: channel 0: rcvd ext data 45
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd close
debug2: tcpwinsz: 318720 for connection: 3
debug2: channel 0: obuf_empty delayed efd 6/(45)
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 2
Xt error: Can't open display: localhost:10.0
debug2: channel 0: written 45 to efd 6
debug2: tcpwinsz: 318720 for connection: 3
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 4756, received 2908 bytes, in 0.2 seconds
Bytes per second: sent 30810.3, received 18838.6
debug1: Exit status 1
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [gentoo-user] ssh -X problem [no help sofar on ssh group]
2014-12-20 17:17 [gentoo-user] ssh -X problem [no help sofar on ssh group] Harry Putnam
@ 2014-12-20 19:05 ` J. Roeleveld
2014-12-20 20:50 ` Rich Freeman
2014-12-21 21:32 ` [gentoo-user] " Mark David Dumlao
1 sibling, 1 reply; 8+ messages in thread
From: J. Roeleveld @ 2014-12-20 19:05 UTC (permalink / raw
To: gentoo-user
On 20 December 2014 18:17:57 CET, Harry Putnam <reader@newsguy.com> wrote:
>This properly belongs on the ssh group, but posting there has not
>gotten
>any responses... and the list is quite slow to boot.
>
>I like using ssh -X to other lan remotes but with new versions of
>openssh
>or perhaps the configs, it only works 1 way.
>
>I can `ssh -X' to the gentoo host from a debian host but not the other
>way round.
>
>Two different versions of openssh appear to be involved. But not sure
>how different they are.
>
>RHOST=a debian HOST
>LHOST= Gentoo HOST
>
>ssh -vN $RHOST 2>&1|grep "remote software version"
>
> [...] OpenSSH_6.7p1 Debian-3
>
>ssh -vN $LHOST 2>&1|grep "remote software version"
>
> [...] OpenSSH_6.7p1-hpn14v5
>
>
>One thing I tried to do was to copy the RHOST sshd_config and
>ssh_config to
>LHOST. Restart and try again... there were a few incompatible bits in
>the files so after commenting a few out until no config errors.
>
>However ssh -X still displayed the error and would NOT work when:
> ssh -X RHOST from LHOST
>({Note that plain ssh LHOST or RHOST works in any direction}
>
>Error outut with ssh -X $RHOST "xterm"
>
>,----
>| Warning: untrusted X11 forwarding setup failed: xauth key data not
>generated
>| Warning: No xauth data; using fake authentication data for X11
>forwarding.
>| Invalid MIT-MAGIC-COOKIE-1 keyxterm: Xt error: Can't open display:
>localhost:10.0
>`----
>
>[Full Error output with ssh -vv -X is very lengthy so is attached at
>the end]
>
>I'm not seeing how to debug this further. So going back to the stock
>version of sshd_config ssh_config on gentoo with two changes:
>
>commented out this line:
> PasswordAuthentication no
>
>added this:
> X11Forwarding yes
>
>------- ------- ---=--- ------- -------
>Full sshd_config on LHOST: sudo grep ^[^#] /etc/ssh/sshd_config
>------- ------- ---=--- ------- -------
> UsePAM yes
> X11Forwarding yes
> PrintMotd no
> PrintLastLog no
> UsePrivilegeSeparation sandbox # Default for new installations.
> Subsystem sftp /usr/lib/misc/sftp-server
> AcceptEnv LANG LC_*
>
>------- Config END -------
>
>
>------- ------- ---=--- ------- -------
>Full ssh_config on LHOST: sudo grep ^[^#] /etc/ssh/ssh_config
>------- ------- ---=--- ------- -------
>
> ForwardX11 yes
> SendEnv LANG LC_*
>
>------- Config END -------
>
>#######################################################
>
>Now the same info for RHOST
>
>------- ------- ---=--- ------- -------
>Full sshd_config on RHOST: ssh root@RHOST "grep ^[^#]
>/etc/ssh/sshd_config"
>------- ------- ---=--- ------- -------
>
>HostKey /etc/ssh/ssh_host_rsa_key
>HostKey /etc/ssh/ssh_host_dsa_key
>HostKey /etc/ssh/ssh_host_ed25519_key
>AcceptEnv LANG LC_*
>ChallengeResponseAuthentication no
>IgnoreRhosts yes
>HostbasedAuthentication no
>KeyRegenerationInterval 3600
>LogLevel INFO
>LoginGraceTime 120
>PermitEmptyPasswords no
>PermitRootLogin yes
>Port 22
>PrintLastLog yes
>PrintMotd no
>Protocol 2
>PubkeyAuthentication yes
>RSAAuthentication yes
>RhostsRSAAuthentication no
>ServerKeyBits 1024
>SyslogFacility AUTH
>StrictModes yes
>Subsystem sftp /usr/lib/misc/sftp-server
>TCPKeepAlive yes
>UsePAM yes
>UsePrivilegeSeparation sandbox
>X11Forwarding yes
>
>------- Config END -------
>
>
>------- ------- ---=--- ------- -------
>Full ssh_config on RHOST: ssh root@RHOST "grep ^[^#]
>/etc/ssh/ssh_config"
>------- ------- ---=--- ------- -------
>Host *
> ForwardX11 yes
> SendEnv LANG LC_*
> HashKnownHosts yes
>
>------- Config END -------
>
>############################################
>############################################
>
>The only thing more I can think to include is the full lengthy output
>of
>ssh -vv -X
Try "ssh -Y ".
It's what I have been using for a long time now.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [gentoo-user] ssh -X problem [no help sofar on ssh group]
2014-12-20 19:05 ` J. Roeleveld
@ 2014-12-20 20:50 ` Rich Freeman
2014-12-21 11:25 ` [gentoo-user] " Harry Putnam
0 siblings, 1 reply; 8+ messages in thread
From: Rich Freeman @ 2014-12-20 20:50 UTC (permalink / raw
To: gentoo-user
On Sat, Dec 20, 2014 at 2:05 PM, J. Roeleveld <joost@antarean.org> wrote:
>
> Try "ssh -Y ".
> It's what I have been using for a long time now.
Correct - ssh -X hasn't worked on Gentoo for ages. It has been a
while since I looked up the details but I seem to recall it being an
upstream issue and that it is actually broken on many (but not all)
distros.
--
Rich
^ permalink raw reply [flat|nested] 8+ messages in thread
* [gentoo-user] Re: ssh -X problem [no help sofar on ssh group]
2014-12-20 20:50 ` Rich Freeman
@ 2014-12-21 11:25 ` Harry Putnam
2014-12-21 12:42 ` Rich Freeman
0 siblings, 1 reply; 8+ messages in thread
From: Harry Putnam @ 2014-12-21 11:25 UTC (permalink / raw
To: gentoo-user
Rich Freeman <rich0@gentoo.org> writes:
> On Sat, Dec 20, 2014 at 2:05 PM, J. Roeleveld <joost@antarean.org> wrote:
>>
>> Try "ssh -Y ".
>> It's what I have been using for a long time now.
>
> Correct - ssh -X hasn't worked on Gentoo for ages. It has been a
> while since I looked up the details but I seem to recall it being an
> upstream issue and that it is actually broken on many (but not all)
> distros.
Thanks for the input... that's about how long I've been off gentoo. I
used it successfully on several different strains of solaris and on
debian. In fact, it works on those hosts right now.
Still kind of puzzled about how ssh determines, when -Y is used, when
xll-forwardings are `TRUSTED'.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [gentoo-user] Re: ssh -X problem [no help sofar on ssh group]
2014-12-21 11:25 ` [gentoo-user] " Harry Putnam
@ 2014-12-21 12:42 ` Rich Freeman
0 siblings, 0 replies; 8+ messages in thread
From: Rich Freeman @ 2014-12-21 12:42 UTC (permalink / raw
To: gentoo-user
On Sun, Dec 21, 2014 at 6:25 AM, Harry Putnam <reader@newsguy.com> wrote:
>
> Still kind of puzzled about how ssh determines, when -Y is used, when
> xll-forwardings are `TRUSTED'.
>
When -Y is used, all forwarding is trusted, and when -X is used
nothing is trusted. With -Y all ssh does is forward X11 traffic to
the X server unfiltered. With -X there is an X11 security extension
that gets used to prevent some things like keyboard snooping. X11 is
pretty weak from a security standpoint - in its normal state any X
client can do all kinds of stuff that could compromise security, like
capture keyboard input to a window owned by another client. So, your
music player can keylog your browser session/etc. Obviously remote X
clients further compounds this.
-X is supposed to protect against some of these issues, but it doesn't
work on Gentoo. I'd have to research why again - I forget if it was
an ssh issue, or an xorg issue.
--
Rich
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [gentoo-user] ssh -X problem [no help sofar on ssh group]
2014-12-20 17:17 [gentoo-user] ssh -X problem [no help sofar on ssh group] Harry Putnam
2014-12-20 19:05 ` J. Roeleveld
@ 2014-12-21 21:32 ` Mark David Dumlao
2014-12-21 23:29 ` [gentoo-user] " Harry Putnam
1 sibling, 1 reply; 8+ messages in thread
From: Mark David Dumlao @ 2014-12-21 21:32 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: text/plain, Size: 4834 bytes --]
On Sun, Dec 21, 2014 at 1:17 AM, Harry Putnam <reader@newsguy.com> wrote:
> This properly belongs on the ssh group, but posting there has not gotten
> any responses... and the list is quite slow to boot.
>
> I like using ssh -X to other lan remotes but with new versions of openssh
> or perhaps the configs, it only works 1 way.
>
> I can `ssh -X' to the gentoo host from a debian host but not the other
> way round.
>
> Two different versions of openssh appear to be involved. But not sure
> how different they are.
>
> RHOST=a debian HOST
> LHOST= Gentoo HOST
>
> ssh -vN $RHOST 2>&1|grep "remote software version"
>
> [...] OpenSSH_6.7p1 Debian-3
>
> ssh -vN $LHOST 2>&1|grep "remote software version"
>
> [...] OpenSSH_6.7p1-hpn14v5
>
>
> One thing I tried to do was to copy the RHOST sshd_config and ssh_config to
> LHOST. Restart and try again... there were a few incompatible bits in
> the files so after commenting a few out until no config errors.
>
> However ssh -X still displayed the error and would NOT work when:
> ssh -X RHOST from LHOST
> ({Note that plain ssh LHOST or RHOST works in any direction}
>
> Error outut with ssh -X $RHOST "xterm"
>
> ,----
> | Warning: untrusted X11 forwarding setup failed: xauth key data not
> generated
> | Warning: No xauth data; using fake authentication data for X11
> forwarding.
> | Invalid MIT-MAGIC-COOKIE-1 keyxterm: Xt error: Can't open display:
> localhost:10.0
>
I believe you're looking for the "xhost" command and its archaic
permissions setup settings.
The idea is that the machine hosting the X server has an additional
permissions setting that controls which
hosts are allowed to use the X displays.
Since you say that it's apparently the debian host that doesn't allow
launching of X programs,
what happens if, from the working GUI on the debian host, you run:
xhost +
Before you try connecting to it from the gentoo machine? It should say
something like
access control disabled, clients can connect from any host
And you should be able to open your xterm using ssh -X.
`----
>
> [Full Error output with ssh -vv -X is very lengthy so is attached at the
> end]
>
> I'm not seeing how to debug this further. So going back to the stock
> version of sshd_config ssh_config on gentoo with two changes:
>
> commented out this line:
> PasswordAuthentication no
>
> added this:
> X11Forwarding yes
>
> ------- ------- ---=--- ------- -------
> Full sshd_config on LHOST: sudo grep ^[^#] /etc/ssh/sshd_config
> ------- ------- ---=--- ------- -------
> UsePAM yes
> X11Forwarding yes
> PrintMotd no
> PrintLastLog no
> UsePrivilegeSeparation sandbox # Default for new
> installations.
> Subsystem sftp /usr/lib/misc/sftp-server
> AcceptEnv LANG LC_*
>
> ------- Config END -------
>
>
> ------- ------- ---=--- ------- -------
> Full ssh_config on LHOST: sudo grep ^[^#] /etc/ssh/ssh_config
> ------- ------- ---=--- ------- -------
>
> ForwardX11 yes
> SendEnv LANG LC_*
>
> ------- Config END -------
>
> #######################################################
>
> Now the same info for RHOST
>
> ------- ------- ---=--- ------- -------
> Full sshd_config on RHOST: ssh root@RHOST "grep ^[^#]
> /etc/ssh/sshd_config"
> ------- ------- ---=--- ------- -------
>
> HostKey /etc/ssh/ssh_host_rsa_key
> HostKey /etc/ssh/ssh_host_dsa_key
> HostKey /etc/ssh/ssh_host_ed25519_key
> AcceptEnv LANG LC_*
> ChallengeResponseAuthentication no
> IgnoreRhosts yes
> HostbasedAuthentication no
> KeyRegenerationInterval 3600
> LogLevel INFO
> LoginGraceTime 120
> PermitEmptyPasswords no
> PermitRootLogin yes
> Port 22
> PrintLastLog yes
> PrintMotd no
> Protocol 2
> PubkeyAuthentication yes
> RSAAuthentication yes
> RhostsRSAAuthentication no
> ServerKeyBits 1024
> SyslogFacility AUTH
> StrictModes yes
> Subsystem sftp /usr/lib/misc/sftp-server
> TCPKeepAlive yes
> UsePAM yes
> UsePrivilegeSeparation sandbox
> X11Forwarding yes
>
> ------- Config END -------
>
>
> ------- ------- ---=--- ------- -------
> Full ssh_config on RHOST: ssh root@RHOST "grep ^[^#] /etc/ssh/ssh_config"
> ------- ------- ---=--- ------- -------
> Host *
> ForwardX11 yes
> SendEnv LANG LC_*
> HashKnownHosts yes
>
> ------- Config END -------
>
> ############################################
> ############################################
>
> The only thing more I can think to include is the full lengthy output of
> ssh -vv -X
>
>
--
This email is: [ ] actionable [ ] fyi [ ] social
Response needed: [ ] yes [ ] up to you [ ] no
Time-sensitive: [ ] immediate [ ] soon [ ] none
[-- Attachment #2: Type: text/html, Size: 6337 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* [gentoo-user] Re: ssh -X problem [no help sofar on ssh group]
2014-12-21 21:32 ` [gentoo-user] " Mark David Dumlao
@ 2014-12-21 23:29 ` Harry Putnam
2014-12-21 23:48 ` Rich Freeman
0 siblings, 1 reply; 8+ messages in thread
From: Harry Putnam @ 2014-12-21 23:29 UTC (permalink / raw
To: gentoo-user
Mark David Dumlao <madumlao@gmail.com> writes:
[...]
> I believe you're looking for the "xhost" command and its archaic
> permissions setup settings.
>
> The idea is that the machine hosting the X server has an additional
> permissions setting that controls which
> hosts are allowed to use the X displays.
>
> Since you say that it's apparently the debian host that doesn't allow
> launching of X programs,
> what happens if, from the working GUI on the debian host, you run:
> xhost +
I thought I had indicated it was the gentoo machine with the problem.
But I guess you could see it the other way round.
I'm getting myself a little confused here; this is what happens:
If I do: Gentoo ssh -X debian "xterm" it fails. The error message
changes with diffent options set but generally it cannot open a
display on localhost
Now the other way round:
debian ssh -X gentoo "xterm" works fine
> Before you try connecting to it from the gentoo machine? It should say
> something like
> access control disabled, clients can connect from any host
>
> And you should be able to open your xterm using ssh -X.
Doing `xhost +' on debian before ssh -x from gentoo does not help a
bit.
Apparently as others have indicated it is a long standing gentoo
problem.
But since -Y works... well I'm about ready to go on about my business
and ignore the failure of -X.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [gentoo-user] Re: ssh -X problem [no help sofar on ssh group]
2014-12-21 23:29 ` [gentoo-user] " Harry Putnam
@ 2014-12-21 23:48 ` Rich Freeman
0 siblings, 0 replies; 8+ messages in thread
From: Rich Freeman @ 2014-12-21 23:48 UTC (permalink / raw
To: gentoo-user
On Sun, Dec 21, 2014 at 6:29 PM, Harry Putnam <reader@newsguy.com> wrote:
> Mark David Dumlao <madumlao@gmail.com> writes:
>
>> Before you try connecting to it from the gentoo machine? It should say
>> something like
>> access control disabled, clients can connect from any host
>>
>> And you should be able to open your xterm using ssh -X.
>
> Doing `xhost +' on debian before ssh -x from gentoo does not help a
> bit.
Nor should it. Connections forwarded by ssh are made from the local
machine using your cookie. Xhost should have no effect. If you were
having the client connect directly to the server then it might help,
but presumably you wouldn't want your X server accepting
unauthenticated connections from anywhere on the internet on an
internet-accessible port.
--
Rich
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-12-21 23:48 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-20 17:17 [gentoo-user] ssh -X problem [no help sofar on ssh group] Harry Putnam
2014-12-20 19:05 ` J. Roeleveld
2014-12-20 20:50 ` Rich Freeman
2014-12-21 11:25 ` [gentoo-user] " Harry Putnam
2014-12-21 12:42 ` Rich Freeman
2014-12-21 21:32 ` [gentoo-user] " Mark David Dumlao
2014-12-21 23:29 ` [gentoo-user] " Harry Putnam
2014-12-21 23:48 ` Rich Freeman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox