[gentoo-user] SSH: No X11 forwarding any longer

[gentoo-user] SSH: No X11 forwarding any longer

[Alex Schuster]

Hi there!

For a little while now I have a problem on one of my hosts, X11 forwarding 
stopped working. I do not know where to look, but I thought maybe someone 
here has an idea? I have a .Xauthority file dated from Sept 19, this might 
be around the last time forwarding was working.

Here is my /etc/ssh/sshd_config, stripped by all commented lines in order to 
save space:

Protocol 2,1
PermitRootLogin no
PasswordAuthentication no
UsePAM yes
X11Forwarding yes
ClientAliveInterval 180
Banner /etc/ssh/tolles.banner
Subsystem       sftp    /usr/lib/misc/sftp-server

I stopped the ssh service and started sshd manually with option -d:

root@zone:~ /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.7p1
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
socket: Address family not supported by protocol
Generating 768 bit RSA key.
RSA key generation complete.
[Now comes the login]
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.1.4 port 38166
debug1: Client protocol version 2.0; client software version OpenSSH_4.6
debug1: match: OpenSSH_4.6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_4.7
debug1: permanently_set_uid: 22/22
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user wonko service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "wonko"
debug1: PAM: setting PAM_RHOST to "weird.wonkology.org"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth_send_banner: sent
debug1: userauth-request for user wonko service ssh-connection method 
publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 1000/100 (e=0/0)
debug1: trying public key file /home/wonko/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1000/100 (e=0/0)
debug1: trying public key file /home/wonko/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for wonko from 192.168.1.4 port 38166 ssh2
debug1: userauth-request for user wonko service ssh-connection method 
publickey
debug1: attempt 2 failures 2
debug1: temporarily_use_uid: 1000/100 (e=0/0)
debug1: trying public key file /home/wonko/.ssh/authorized_keys
debug1: matching key found: file /home/wonko/.ssh/authorized_keys, line 1
Found matching DSA key: 01:57:eb:6f:53:3f:6f:d8:a7:87:6f:c2:a7:a4:7a:18
debug1: restore_uid: 0/0
debug1: ssh_dss_verify: signature correct
debug1: do_pam_account: called
Accepted publickey for wonko from 192.168.1.4 port 38166 ssh2
debug1: monitor_child_preauth: wonko has been authenticated by privileged 
process
debug1: PAM: establishing credentials
debug1: permanently_set_uid: 1000/100
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request x11-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug1: server_input_channel_req: channel 0 request pty-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: init
debug1: session_new: session 0
debug1: session_pty_req: session 0 alloc /dev/pts/2
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: PAM: setting PAM_TTY to "/dev/pts/2"
debug1: Setting controlling tty using TIOCSCTTY.


I did the same on another host where forwarding is working. Here is a diff 
of the two logs: (< ok, > not ok)

1a2
> debug1: private host key: #0 type 0 RSA1
3c4
< debug1: private host key: #0 type 1 RSA
---
> debug1: private host key: #1 type 1 RSA
5c6
< debug1: private host key: #1 type 2 DSA
---
> debug1: private host key: #2 type 2 DSA
10a12,14
> Generating 768 bit RSA key.
> RSA key generation complete.
>
14c18
< Connection from 127.0.0.1 port 55291
---
> Connection from 192.168.1.4 port 35800
18c22
< debug1: Local version string SSH-2.0-OpenSSH_4.7
---
> debug1: Local version string SSH-1.99-OpenSSH_4.7
36c40
< debug1: PAM: setting PAM_RHOST to "localhost"
---
> debug1: PAM: setting PAM_RHOST to "weird.wonkology.org"
37a42
> debug1: userauth_send_banner: sent
47c52
< Failed publickey for wonko from 127.0.0.1 port 55291 ssh2
---
> Failed publickey for wonko from 192.168.1.4 port 35800 ssh2
57c62
< Accepted publickey for wonko from 127.0.0.1 port 55291 ssh2
---
> Accepted publickey for wonko from 192.168.1.4 port 35800 ssh2
74,75d78
< debug1: x11_create_display_inet: Socket family 10 not supported
< debug1: channel 1: new [X11 inet listener]
82c85
< debug1: session_pty_req: session 0 alloc /dev/pts/19
---
> debug1: session_pty_req: session 0 alloc /dev/pts/7
86c89
< debug1: PAM: setting PAM_TTY to "/dev/pts/19"
---
> debug1: PAM: setting PAM_TTY to "/dev/pts/7"

So, this is the main difference, it appears only on the machine where 
forwarding is working:
< debug1: x11_create_display_inet: Socket family 10 not supported
< debug1: channel 1: new [X11 inet listener]

Any idea what's wrong?

	Alex
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] SSH: No X11 forwarding any longer

[Iain Buchanan]

On Thu, 2007-09-27 at 20:13 +0200, Alex Schuster wrote:
> Hi there!
> 
> For a little while now I have a problem on one of my hosts, X11 forwarding 
> stopped working.

how are you ssh-ing in?  -X? -Y?  What is the actual error from the
client?

-- 
Iain Buchanan <iaindb at netspace dot net dot au>

BOFH Excuse #148:

Insert coin for new game

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] SSH: No X11 forwarding any longer

[Alex Schuster]

Iain Buchanan writes:

> On Thu, 2007-09-27 at 20:13 +0200, Alex Schuster wrote:

> > For a little while now I have a problem on one of my hosts, X11
> > forwarding stopped working.
>
> how are you ssh-ing in?  -X? -Y?

Yes. Well, I usually have forwarding enabled automatically 
in /etc/ssh/ssh_config, but I always try with -X or -Y anyway.

> What is the actual error from the client?

$DISPLAY is not set.

But I notice a change since yesterday: I now get this warning:
Warning: No xauth data; using fake authentication data for X11 forwarding.

Don't know what causes this, I emerged a couple of things due to world 
update and (still!) some problems with the expat update, but nothing which 
I would think has to do with ssh. Anyway, DISPLAY still does not get set.

	Alex
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] SSH: No X11 forwarding any longer

[Alex Schuster]

I wrote:

> Yes. Well, I usually have forwarding enabled automatically
> in /etc/ssh/ssh_config, but I always try with -X or -Y anyway.
>
> > What is the actual error from the client?
>
> $DISPLAY is not set.
>
> But I notice a change since yesterday: I now get this warning:
> Warning: No xauth data; using fake authentication data for X11
> forwarding.
>
> Don't know what causes this, I emerged a couple of things due to world
> update and (still!) some problems with the expat update, but nothing
> which I would think has to do with ssh. Anyway, DISPLAY still does not
> get set.

I sort of found the solution to my problem, but still do not fully 
understand what happened. First I thought I had to add X to the server's 
use flags. Looked like I then had DISPLAY set, but still got the warning 
about missing xauth data. When trying to start an X application, I got 
this:

  Xlib: connection to "localhost:10.0" refused by server
  Xlib: Invalid MIT-MAGIC-COOKIE-1 key
  xterm Xt error: Can't open display: localhost:10.0

Then I looked at the configs again, and in the man page for ssh_config I 
finally found this:
     XAuthLocation
             Specifies the full pathname of the xauth(1) program.  The
             default is /usr/openwin/bin/xauth.

/usr/openwin? I added "XAuthLocation /usr/bin/xauth" to the 
client's /etc/ssh/ssh_config, and now all was fine. Even without the X use 
flag.

Looking at a gentoo box I did not update for a while, I see the man page 
there tells the default location is /usr/bin/xauth. Okay, now I know this 
change is responsible. But why aren't forum and this list flooded with 
people experiencing the same problem as me?

	Alex
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] SSH: No X11 forwarding any longer

[Mick]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

On Sunday 14 October 2007, Alex Schuster wrote:

> Then I looked at the configs again, and in the man page for ssh_config I
> finally found this:
>      XAuthLocation
>              Specifies the full pathname of the xauth(1) program.  The
>              default is /usr/openwin/bin/xauth.
>
> /usr/openwin? I added "XAuthLocation /usr/bin/xauth" to the
> client's /etc/ssh/ssh_config, and now all was fine. Even without the X use
> flag.
>
> Looking at a gentoo box I did not update for a while, I see the man page
> there tells the default location is /usr/bin/xauth. Okay, now I know this
> change is responsible. But why aren't forum and this list flooded with
> people experiencing the same problem as me?

Perhaps because most use vanilla ssh to manage servers?  I have every now and 
then used an ssh tunnel to forward VNC connections, but that is exceptional 
as far as my usage of ssh goes.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] SSH: No X11 forwarding any longer

[Alex Schuster]

Mick writes:

> On Sunday 14 October 2007, Alex Schuster wrote:
> > Then I looked at the configs again, and in the man page for ssh_config
> > I finally found this:
> >      XAuthLocation
> >              Specifies the full pathname of the xauth(1) program.  The
> >              default is /usr/openwin/bin/xauth.
> >
> > /usr/openwin? I added "XAuthLocation /usr/bin/xauth" to the
> > client's /etc/ssh/ssh_config, and now all was fine. Even without the X
> > use flag.
> >
> > Looking at a gentoo box I did not update for a while, I see the man
> > page there tells the default location is /usr/bin/xauth. Okay, now I
> > know this change is responsible. But why aren't forum and this list
> > flooded with people experiencing the same problem as me?
>
> Perhaps because most use vanilla ssh to manage servers?  I have every now
> and then used an ssh tunnel to forward VNC connections, but that is
> exceptional as far as my usage of ssh goes.

Well, my setup looks pretty vanilla to me, I did not talk about more 
sophisticated tunneling stuff. I just have a server and a client, and need 
to put the XAuthLocation line into the client's config when I want X 
forwarding.

I know found out what happened. The old boxes with working forwarding have 
a /usr/openwin symlink pointing to /usr/X11R6. This makes xauth being 
found. It belongs to x11-libs/xview, but the last xview update removed the 
symlink, now X forwarding fails.

Still no idea why you all do NOT have the problem.

	Alex
-- 
gentoo-user@gentoo.org mailing list