Sudden X11 forwarding glitch - Can't open display "localhost:10.0"
Mike Jones
I've no idea what happened, but something is barfing my X11 forwarding
all of a sudden. I'm getting Can't open display "localhost:10.0" for
ssh -Y 192.168.1.1 X11app
Everything else works fine, console apps like Lynx, nano, etc. Its just
the X11 apps that can't seen to get hold of the X11 display, even though
everything worked fine a week ago (confirmed by client-machine use). The
problem seems to be located on the server box as all clients and all
accounts on the LAN are affected the same, no X11 apps suddenly.
Where should I start looking for problems on this one? I've been checking
through looking for any hack-glitches I might have introduced over the
last week (since this problem appeared), but I can't recall fiddling with
anything X11 or ssh related for while now.
Puzzled.
--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
allend
server?
Either globally:
X11Forwarding yes
or:
per user
Match User <username>
X11Forwarding yes
Match
Aaron W. Hsu
> I've no idea what happened, but something is barfing my X11 forwarding
> all of a sudden. I'm getting Can't open display "localhost:10.0" for
>
> ssh -Y 192.168.1.1 X11app
A few points to note here. I see a lot of people using the -Y option, but
from everything that I've read and heard, that's asking for trouble, as
none of the appropriate security measures are taken to ensure that you
have a secure connection. The -X option is the one that enables these
security measures by default.
> Everything else works fine, console apps like Lynx, nano, etc. Its just
> the X11 apps that can't seen to get hold of the X11 display, even though
> everything worked fine a week ago (confirmed by client-machine use). The
> problem seems to be located on the server box as all clients and all
> accounts on the LAN are affected the same, no X11 apps suddenly.
>
> Where should I start looking for problems on this one? I've been checking
> through looking for any hack-glitches I might have introduced over the
> last week (since this problem appeared), but I can't recall fiddling with
> anything X11 or ssh related for while now.
When I run X11 Forwarding, I usually have to do two things. Firstly, I
have to make sure that I use the -X option, and secondly, I need to make
sure that connections to my localhost are enabled. That is, I need to make
sure that local non-loopback X11 connections are okay. I do this with
'xhost +localhost'. This usually works for me.
Aaron W. Hsu
--
A professor is one who talks in someone else's sleep.
Mike Jones
1: The whole LAN sits behind a firewalled server box. No forwarding
outside the LAN occurs. Therefore, the -Y switch is acceptable in this
contained environment, and necessary for client machines to use server-
based internet apps via ssh.
2: Everything else works fine. All connections run and all non-X11
applications poerate as normal. The fault is a Can't open display
"localhost:10.0" one and its appearance is a mystery to me.
What I'm looking for here is what folks would be looking for if this
glitch suddenly occured on their LAN.
Cheers.
Mike Jones
Yup, all just as it was last week when everything worked fine.
I'm a bit stuck as to what happened, and I'm suspecting that my server's
MOBO might be terminally borked. Its had a rough life and does a few
other odd things every so often. This is my last fault-investigation
before I commit cash to a new MOBO, so I need to make sure it is hardware
and not something I'm going to slap my head over the week after spending
money.
I guess due to the lack of "Oh yeah! That happend to me, and..."
responses that it might indeed be hardware related. I've never heard of a
slackware system glitching like this.
Bit Twister
I have yet to be forced to use -Y or -X
> What I'm looking for here is what folks would be looking for if this
> glitch suddenly occured on their LAN.
Check forwarding in ssh config file
$ grep -i forward /etc/ssh/sshd_config
#AllowAgentForwarding yes
#AllowTcpForwarding yes
X11Forwarding yes
# X11Forwarding no
# AllowTcpForwarding no
If I change anything reboot sshd daemon.
Verify I can ssh on local node and same on the target node.
$ xhost +localhost
$ ssh $USER@localhost
$ xterm
$ exit
Next try target machine by ip address.
$ xhost +target_machine_ip_addy_here
$ ssh $USER@target_machine_ip_addy_here
$ xterm
$ exit
Last, check for dns lookup problem.
$ xhost +target_machine_name_here
$ ssh $USER@target_machine_name_here
$ xterm
$ exit
Mike Jones
Everything /except/ X11 apps is still working fine. The LAN uses static
IP addresses. All current client machines have the same X11 apps problem
(with the common server) at the same time. Something odd has happened on
the server box, and its got something to do with the display @ 10.0
thing, related to -X and -Y usage.
"ssh -t 192.168.1.1 nano" gets me nano.
"ssh -X 192.168.1.1 dillo" doesn't get me an expected "bad atom" fault.
"ssh -Y 192.168.1.1 dillo" gets Can't open display "localhost:10.0"
AFAICR I've done nothing that could cause a SNAFU here, and this has been
a problem for up to the last week, based on client reports of failure to
access X11 apps via ssh. I'm scratching for clues here.
Henrik Carlqvist
> I've no idea what happened, but something is barfing my X11 forwarding
> all of a sudden. I'm getting Can't open display "localhost:10.0"
Do you have your home directory on an NFS file system? Does some of your
machines in the LAN run kernel 2.6.24 or newer? If so, you might have been
bitten by a kernel bug: http://bugzilla.kernel.org/show_bug.cgi?id=12557
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
Henrik Carlqvist
> I see a lot of people using the -Y option,
Many X applications crash with error messages about bad atoms when using
the -X option.
> but from everything that I've read and heard, that's asking for trouble, as
> none of the appropriate security measures are taken to ensure that you
> have a secure connection.
The connection is just as encrypted and safe with -Y as with -X. The big
difference is that you with -Y will have to trust the remote machine more.
Someone with root access on the remote machine might be able to start X
applications on your display from that remote machine if you are using the
-Y switch, the -X switch prevents this in newser versions of openssh.
Those applications started by root could include bad applications that
takes screen shots and logs keys from your display.
Mike Jones
> Mike Jones <N...@Arizona.Bay> wrote:
>> I've no idea what happened, but something is barfing my X11 forwarding
>> all of a sudden. I'm getting Can't open display "localhost:10.0"
>
> Do you have your home directory on an NFS file system? Does some of your
> machines in the LAN run kernel 2.6.24 or newer? If so, you might have
> been bitten by a kernel bug:
> http://bugzilla.kernel.org/show_bug.cgi?id=12557
>
> regards Henrik
Not using NFS, but sshfs. As I mentioned before, there have been no
problems of this kind ever before, and suddenly, this week, "Can't open
display" becomes permanent. The patches in the URL you suggested look
interesting, as I'm using the standard S12.2 kernel (2.6.27.7), but the
behaviour pattern of this fault strongly suggests some other cause. this
is why I've thrown this to the NG, just in case anybody else had a "Oh
yeah, that one eh?" experience and a few tips on where to start looking
for glitches I may have intruduced without knowing it. Yes, I know nobody
else but me would know what I've fiddled with over the weeks\months
\years, but a process of "Check this, check that, check the other" might
be the thing that moves this one, as I'm now scratching my head wondering
what happened, clue-free. :(
Thanks for the URL BTW.
allend
machine when you attempt the X forwarding?
Mike Jones
> Probably silly question, but do you have X running on the local machine
> when you attempt the X forwarding?
Yup. Not that that should make a difference, but...
Don't worry about silly questions, the problem is silly. :)
Henrik Carlqvist
> Don't worry about silly questions, the problem is silly. :)
Are you able to find any clue to the cause if you do something like:
ssh -vvv -X remotemachine
Mike Jones
> Mike Jones <N...@Arizona.Bay> wrote:
>> Don't worry about silly questions, the problem is silly. :)
>
> Are you able to find any clue to the cause if you do something like:
>
> ssh -vvv -X remotemachine
>
> regards Henrik
Only that the connection Can't open display "localhost:10.0"
EVerything else works just as it did and should. I've just lost that one
single detail, and have no idea how. I'm thinking maybe that kernel bug
might be playing up due to something else otherwise inconnected changing
the results of that "race" mentioned?
Aaron W. Hsu
> The whole LAN sits behind a firewalled server box. No forwarding
> outside the LAN occurs. Therefore, the -Y switch is acceptable in this
> contained environment, and necessary for client machines to use server-
> based internet apps via ssh.
I understand why you wouldn't necessary bother with -X if you are sure
that your LAN is secure, though I would still recommend that you do not do
this. I don't understand your last statement. What about -Y and the
server-based internet applications that you use requires the use of this
option? I'm not aware of any situation in which you can't readily use -X
provided the appropriate client X server and network configuration.
Aaron W. Hsu
> Everything else works fine. All connections run and all non-X11
> applications poerate as normal. The fault is a Can't open display
> "localhost:10.0" one and its appearance is a mystery to me.
> What I'm looking for here is what folks would be looking for if this
> glitch suddenly occured on their LAN.
If absolutely nothing changed in the state of the machines, then there
shouldn't be any reason for this error, but the best I can guess is that
something did, in fact, change. Whether this was configuration, firewall
or something, something changed, and it would be good to figure out what.
On the other hand, there are a few errors that you should see depending on
the context. If the DISPLAY variable isn't set, then you shouldn't be
getting the localhost in your error message. If there was a problem with
the client X server, then you should get a connection refused error.
Beyond these two errors, I found the following blog post that might be of
some help to you. An excerpt follows:
[N]ot only do you need X11Forwarding yes in /etc/ssh/sshd_config on the
machine youre sshing into, you also need AllowTcpForwarding yes. (And
also ForwardX11 yes, or ForwardX11Trusted yes, depending on your
security preferences and access requirements, in /etc/ssh/ssh_config on
the machine youre sshing from, for the record.)
-- Problems Forwarding X over SSH
Juliet Kemp [1]
I hope this helps.
Aaron W. Hsu
[1]
http://www.oreillynet.com/linux/blog/2006/08/problems_forwarding_x_over_ssh.html
Aaron W. Hsu
> Yup. Not that that should make a difference, but...
Could you give us some more information on the client and server machines,
the LAN layout, as well as the software running on the machines at the
time you try to do this. I'm not sure why you think that it wouldn't make
a difference whether X is running on the client machine or not, because it
does. Unless you meant that it shouldn't make a difference that a question
is silly. :-)
Anyways, I'm sure that you are running X on the client machines, because
the DISPLAY environment is set, and unless you set that environment
variable manually, the only way to get that environment variable to show
up automatically is with the X server running.
Anyways, you didn't post the output of the -vvv options, and that could
help.
Aaron W. Hsu
Aaron W. Hsu
On Sun, 07 Feb 2010 20:00:18 -0500, Mike Jones <N...@arizona.bay> wrote:
> Everything /except/ X11 apps is still working fine.
Yes, we know, you've told us this plenty of times, and of course, that
doesn't surprise any of us. X11 forwarding is a very special, particular
part of SSH and so it's very easy and common for everything else to be
working fine, but to have X11 Forwarding not working. That's not strange
at all. X11 Forwarding requires more configuration, and obviously
something is wrong. You haven't been providing us with much information,
and you need to do that if you want us to solve the problem.
> The LAN uses static
> IP addresses. All current client machines have the same X11 apps problem
> (with the common server) at the same time.
You haven't given us, to my recollection, any information about the
clients and their machines. You said that they were all on the local LAN,
I believe, but we need more information than that. Are they all running
the same SSH configuration? Are they all running the same firewall and
other software? You have not posted any of this information for us. You
should post your configuration files.
> Something odd has happened on
> the server box, and its got something to do with the display @ 10.0
> thing, related to -X and -Y usage.
Why is localhost:10.0 freaking you out? That is nothing special. It's a
simple specification or content of the DISPLAY variable. It's natural and
normal. Assuming that your X Server on the client side is actually getting
that variable, then nothing should surprise you. Of course it is related
to -X, -Y usage (yes, I'm being rather blunt), no duh, man, I mean, come
on, those options are the ones that you *use* to get X11 Forwarding, so of
course, if you don't have X11 Forwarding, then it has to do with X11
Forwarding. On the other hand, I'm pretty sure that you didn't mess up ssh
badly enough that -X and -Y don't work. They work.
It's possible that something has happened with the server box, and if your
clients all have different configurations, then it is that much more
likely that the problem is on the server box. You haven't told us, either,
whether this problem occurs with multiple users or not. I assume that it
does, since you say that multiple clients (I'm assuming this means
multiple users with different machines and potentially different
configurations) are having this issue.
So, why don't you post up all the information you can give us, including
logs, terminal sessions, configuration files, and the like?
> "ssh -t 192.168.1.1 nano" gets me nano.
>
> "ssh -X 192.168.1.1 dillo" doesn't get me an expected "bad atom" fault.
This is strange, in that I have been able to run dillo fine with the -X
option, and I havne't had this bad atom problem. I'd like to know more
about this problem once you have the other issue figured out.
> "ssh -Y 192.168.1.1 dillo" gets Can't open display "localhost:10.0"
This means, quite literally, that while you can, supposedly, connect to
the localhost, the X server running on the local host is not providing any
display 10.0, and I don't know if this is true or not. It does seem like
this could be a problem, unless you have a lot of clients connecting at a
time. Here are some things I wonder:
1) Why on earth would you have 10 X sessions running on your client
machine!? Now, I don't know, because I have seen high values like 10.0 on
single sessions, but usually, it is much more likely for the client to
have a DISPLAY environment variable like localhost:0.0.
2) What is the startup script for the user's login script? Is there
anything in there that manually sets the DISPLAY variable? The DISPLAY
variable needs to be handled automatically or you need to know ahead of
time the location. I don't like the 10.0, because it seems high, and this
is why I ask this question.
3) Have you done nay port sniffing on your client machines to ensure that
the right ports are open? Post your results.
> AFAICR I've done nothing that could cause a SNAFU here, and this has been
> a problem for up to the last week, based on client reports of failure to
> access X11 apps via ssh. I'm scratching for clues here.
You are basing this on client reports, so why don't you check out the logs
on your server machine? What's happening? Who are these clients of yours?
You tell me that they can't connect? Where are they located? Have you
tried this on other various machines and users and verified whether it
works or not? We are guessing blind here, because we have no idea how your
current network configuration looks.
MORE INFO!
Henrik Carlqvist
> 1) Why on earth would you have 10 X sessions running on your client
> machine!?
His local display is probably set to something like localhost:0 but when
doing ssh with X tunneling the display gets a uniqueue number on the
remote machine. From that uniqueue number which really corresponds to a
tcp port X traffic is tunneled to ssh to localhost:0 at the X server on
the console that he is logged in to.
10 is the default offset used by openssh and thus it seems as this session
is his first ssh session to the remote machine. If he keeps that session
open and logs in from another xterm to the same remote machine again he
will in that xterm get the display localhost:11.
Henrik Carlqvist
> Responding to Henrik Carlqvist:
>> Are you able to find any clue to the cause if you do something like:
>>
>> ssh -vvv -X remotemachine
> Only that the connection Can't open display "localhost:10.0"
Even if you are unable to read anything out from the debug messages
someone else might be able to tell something. Please do the following:
ssh -vvv -X remotemachine ls /dev/null >& /tmp/log.txt
Then post your contents of /tmp/log.txt
Aaron W. Hsu
<Henrik.C...@deadspam.com> wrote:
> His local display is probably set to something like localhost:0 but when
> doing ssh with X tunneling the display gets a uniqueue number on the
> remote machine.
Yes, that's right, I forgot about that.
Mike Jones
> On Sun, 07 Feb 2010 18:24:04 -0500, Mike Jones <N...@arizona.bay> wrote:
Interesting, but I've aready covered all that. Thats why everything has
worked fine up until this mystery glitch.
See posted logfile in reply to Hernrik.
Mike Jones
> Mike Jones <N...@Arizona.Bay> wrote:
>
>> Responding to Henrik Carlqvist:
>>> Are you able to find any clue to the cause if you do something like:
>>>
>>> ssh -vvv -X remotemachine
>
>> Only that the connection Can't open display "localhost:10.0"
>
> Even if you are unable to read anything out from the debug messages
> someone else might be able to tell something. Please do the following:
>
> ssh -vvv -X remotemachine ls /dev/null >& /tmp/log.txt
>
> Then post your contents of /tmp/log.txt
>
> regards Henrik
Ok. SRVR=server USER=common_user_account
============================================
OpenSSH_5.1p1, OpenSSL 0.9.8i 15 Sep 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to SRVR [192.168.1.1] port 4503.
debug1: Connection established.
debug3: Not a RSA1 key file /home/USER/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/USER/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-
hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-
group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
c...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
c...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-
ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-
ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit: none,zl...@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: diffie-hellman-group-exchange-sha256,diffie-
hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-
group1-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
c...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
c...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-
ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-
ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com
debug2: kex_parse_kexinit: none,zl...@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: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 136/256
debug2: bits set: 996/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: put_host_port: [192.168.1.1]:4503
debug3: put_host_port: [box1]:4503
debug3: check_host_in_hostfile: filename /home/USER/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 3
debug3: check_host_in_hostfile: filename /home/USER/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug1: Host '[box1]:4503' is known and matches the DSA host key.
debug1: Found key in /home/USER/.ssh/known_hosts:3
debug2: bits set: 1013/2048
debug1: ssh_dss_verify: signature correct
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: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/USER/.ssh/id_dsa (0x80a1950)
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/USER/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 433
debug2: input_userauth_pk_ok: fp
d1:ec:dc:75:00:1e:62:8d:6c:5c:c4:5f:cb:f5:ca:96
debug3: sign_and_send_pubkey
debug1: Authentication succeeded (publickey).
debug2: fd 5 setting O_NONBLOCK
debug3: fd 6 is O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-...@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug1: Sending command: ls /dev/null
debug2: channel 0: request exec confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype e...@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
/dev/null
debug3: channel 0: will not send data after close
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
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
debug3: channel 0: close_fds r -1 w -1 e 6 c -1
debug1: fd 1 clearing O_NONBLOCK
debug3: fd 2 is not O_NONBLOCK
Transferred: sent 2512, received 2640 bytes, in 0.1 seconds
Bytes per second: sent 45802.6, received 48136.5
debug1: Exit status 0
============================================
Jim Diamond
> Responding to Henrik Carlqvist:
>
>> Mike Jones <N...@Arizona.Bay> wrote:
>>
>>> Responding to Henrik Carlqvist:
>>>> Are you able to find any clue to the cause if you do something like:
>>>>
>>>> ssh -vvv -X remotemachine
>>
>>> Only that the connection Can't open display "localhost:10.0"
>>
>> Even if you are unable to read anything out from the debug messages
>> someone else might be able to tell something. Please do the following:
>>
>> ssh -vvv -X remotemachine ls /dev/null >& /tmp/log.txt
>>
>> Then post your contents of /tmp/log.txt
>>
>> regards Henrik
>
>
> Ok. SRVR=server USER=common_user_account
To me, that wasn't very illuminating. Perhaps someone else will see
your problem, but it might be more informative if you tried a command
that actually uses your X connection. Try this and post it:
ssh -vvv -X remotemachine xclock >& /tmp/log.txt
Cheers.
Jim
Henrik Carlqvist
> debug1: Authentication succeeded (publickey).
> debug2: fd 5 setting O_NONBLOCK
> debug3: fd 6 is O_NONBLOCK
> debug1: channel 0: new [client-session]
> debug3: ssh_session2_open: channel_new: 0
> debug2: channel 0: send open
> debug1: Requesting no-more-...@openssh.com
> debug1: Entering interactive session.
> debug2: callback start
> debug2: x11_get_proto: /usr/bin/xauth list :0.0 2>/dev/null
> debug1: Requesting X11 forwarding with authentication spoofing.
> debug2: channel 0: request x11-req confirm 0
> debug2: client_session2_setup: id 0
> debug1: Sending command: ls /dev/null
I can't say for sure why it goes wrong, but when I compare with my own log
I have some other xauth lines:
debug1: Authentication succeeded (publickey).
debug3: clear hostkey 1
debug3: clear hostkey 2
debug2: fd 5 setting O_NONBLOCK
debug3: fd 6 is O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-cmtAy20610/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-cmtAy20610/xauthfile list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug1: Sending command: ls /dev/null
However, the difference might be explained by the fact that I am doing the
test on a rather old Slackware 9.1 installation.
Are you able to start some X program on your local console machine from
the terminal where you later call ssh? If you for some reason would be
unable to start local X applications you would also not be able to tunnel
X with ssh as your ssh client then behaves like an X application.
Lew Pitcher
Henrik.C...@deadspam.com wrote:
FWIW, here's another successful log to compare against
X client (ssh server) is fully patched and current Slackware 13.0
X server (ssh client) is fully patched and current Slackware 12.0
Command was: ssh -vvv -X merlin xclock >& /tmp/log.txt
debug1: Authentication succeeded (publickey).
debug2: fd 5 setting O_NONBLOCK
debug3: fd 6 is O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-...@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-ZZsYWH7725/xauthfile
generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-ZZsYWH7725/xauthfile
list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug1: Sending command: xclock
debug2: channel 0: request exec confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 38013
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------
Mike Jones
$> ssh -vvv -X SRVR dillo >& sshtest.out
OpenSSH_5.1p1, OpenSSL 0.9.8i 15 Sep 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 4503.
debug2: dh_gen_key: priv key bits set: 122/256
debug2: bits set: 1017/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: put_host_port: [192.168.1.1]:4503
debug3: put_host_port: [192.168.1.1]:4503
debug3: check_host_in_hostfile: filename /home/USER/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug3: check_host_in_hostfile: filename /home/USER/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug1: Host '[192.168.1.1]:4503' is known and matches the DSA host key.
debug1: Found key in /home/USER/.ssh/known_hosts:2
debug2: bits set: 1055/2048
debug1: ssh_dss_verify: signature correct
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: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/USER/.ssh/id_dsa (0x80a1900)
debug1: Sending command: dillo
debug2: channel 0: request exec confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd ext data 35
debug2: channel 0: rcvd ext data 1
Can't open display "localhost:10.0"
debug2: channel 0: written 36 to efd 6
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype e...@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
debug3: channel 0: will not send data after close
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
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
debug3: channel 0: close_fds r -1 w -1 e 6 c -1
debug1: fd 1 clearing O_NONBLOCK
debug3: fd 2 is not O_NONBLOCK
Transferred: sent 2496, received 2704 bytes, in 0.1 seconds
Bytes per second: sent 20942.4, received 22687.6
debug1: Exit status 1
...and again with the -Y flag
$> ssh -vvv -Y SRVR dillo >& sshtest.out
OpenSSH_5.1p1, OpenSSL 0.9.8i 15 Sep 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 4503.
debug2: dh_gen_key: priv key bits set: 129/256
debug2: bits set: 1033/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: put_host_port: [192.168.1.1]:4503
debug3: put_host_port: [192.168.1.1]:4503
debug3: check_host_in_hostfile: filename /home/USER/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug3: check_host_in_hostfile: filename /home/USER/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug1: Host '[192.168.1.1]:4503' is known and matches the DSA host key.
debug1: Found key in /home/USER/.ssh/known_hosts:2
debug2: bits set: 1011/2048
debug1: ssh_dss_verify: signature correct
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: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/USER/.ssh/id_dsa (0x80a1900)
debug1: Sending command: dillo
debug2: channel 0: request exec confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd ext data 35
debug2: channel 0: rcvd ext data 1
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 e...@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
debug3: channel 0: will not send data after close
debug2: channel 0: obuf_empty delayed efd 6/(36)
Can't open display "localhost:10.0"
debug2: channel 0: written 36 to efd 6
debug3: channel 0: will not send data after close
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
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
debug3: channel 0: close_fds r -1 w -1 e 6 c -1
debug1: fd 1 clearing O_NONBLOCK
debug3: fd 2 is not O_NONBLOCK
Transferred: sent 2496, received 2704 bytes, in 0.1 seconds
Bytes per second: sent 21023.4, received 22775.3
debug1: Exit status 1
Jim Diamond
> Responding to Jim Diamond:
>
>> On 2010-02-09 at 09:08 AST, Mike Jones <N...@Arizona.Bay> wrote:
>>> Responding to Henrik Carlqvist:
>>>
>>>> Mike Jones <N...@Arizona.Bay> wrote:
>>>>
>>>>> Responding to Henrik Carlqvist:
>>>>>> Are you able to find any clue to the cause if you do something like:
>>>>>>
>>>>>> ssh -vvv -X remotemachine
>>>>
>>>>> Only that the connection Can't open display "localhost:10.0"
>>>>
>>>> Even if you are unable to read anything out from the debug messages
>>>> someone else might be able to tell something. Please do the following:
>>>>
>>>> ssh -vvv -X remotemachine ls /dev/null >& /tmp/log.txt
>>>>
>>>> Then post your contents of /tmp/log.txt
>>>>
>>>> regards Henrik
>>>
>>>
>>> Ok. SRVR=server USER=common_user_account
>>
>> To me, that wasn't very illuminating. Perhaps someone else will see
>> your problem, but it might be more informative if you tried a command
>> that actually uses your X connection. Try this and post it:
>>
>> ssh -vvv -X remotemachine xclock >& /tmp/log.txt
> $> ssh -vvv -X SRVR dillo >& sshtest.out
It is possibly too bad that you didn't use xclock like I suggested,
since I don't have dillo on the remote machine. It probably doesn't
matter, but you never know.
> OpenSSH_5.1p1, OpenSSL 0.9.8i 15 Sep 2008
I have
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009
so the noted differences below may be because of that
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to 192.168.1.1 [192.168.1.1] port 4503.
Hmmm... I see you are using a non-standard ssh port (4503 instead of
22). I don't know whether that could cause a problem, but the fewer
variations on the usual theme, the better.
<snip>
I didn't notice anything noteworthy there, but maybe I missed something.
> debug3: put_host_port: [192.168.1.1]:4503
> debug3: put_host_port: [192.168.1.1]:4503
> debug3: check_host_in_hostfile: filename /home/USER/.ssh/known_hosts
Am I safe in assuming you edited your real username in a fit of
paranoia? Is the real userid lower case?
<snip>
> debug2: fd 5 setting O_NONBLOCK
> debug3: fd 6 is O_NONBLOCK
Interesting. Later in the conversation I get
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
I wonder why your fd's are different (from each other).
> debug1: channel 0: new [client-session]
> debug3: ssh_session2_open: channel_new: 0
> debug2: channel 0: send open
> debug1: Requesting no-more-...@openssh.com
> debug1: Entering interactive session.
> debug2: callback start
> debug2: x11_get_proto: /usr/bin/xauth list :0.0 2>/dev/null
> debug1: Requesting X11 forwarding with authentication spoofing.
> debug2: channel 0: request x11-req confirm 0
> debug2: client_session2_setup: id 0
> debug1: Sending command: dillo
> debug2: channel 0: request exec confirm 1
> debug2: fd 3 setting TCP_NODELAY
> debug2: callback done
> debug2: channel 0: open confirm rwindow 0 rmax 32768
> debug2: channel 0: rcvd adjust 2097152
> debug2: channel_input_confirm: type 99 id 0
> debug2: exec request accepted on channel 0
> debug2: channel 0: rcvd ext data 35
> debug2: channel 0: rcvd ext data 1
> Can't open display "localhost:10.0"
Here are my last few lines, for comparison:
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-...@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug1: Sending command: xclock
debug2: channel 0: request exec confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
Pretty much the same as yours, and then:
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 43365
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
Sorry that I can't help, aside from my probably-spurious comments above.
Jim
Henrik Carlqvist
> FWIW, here's another successful log to compare against
> debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-ZZsYWH7725/xauthfile
> generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
> debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-ZZsYWH7725/xauthfile
> list :0.0 2>/dev/null
Yep, you get the same kind of xauth lines that I do. On the other hand Jim
Diamond gets the same xauth line as Mike Jones and it works for Jim.
I really can't tell what is going wrong, I have been trying to provocate
my machines to get the error, but the closest I get is this attempt:
> xclock
(local xclock shows up on display)
> unsetenv DISPLAY
> xclock
Error: Can't open display:
> ssh -X mugin xclock
Error: Can't open display:
Even though I get an error about the display from my ssh session I am not
able to get the error about display localhost:10.
Aaron W. Hsu
<Henrik.C...@deadspam.com> wrote:
> Even though I get an error about the display from my ssh session I am not
> able to get the error about display localhost:10.
What about doing something like this?
ssh -X host
which takes you into a shell. Then, print the environment for us. That
might reveal something. Also, try to run xclock once you are inside the
shell. I don't know why this would make a difference, but maybe we can get
more information.
Mike Jones
> On Wed, 10 Feb 2010 02:17:17 -0500, Henrik Carlqvist
I get
Error: Can't open display "localhost:10.0"