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"
Mike Jones
No worries. Its a headscratcher for sure.
Don't forget that all this worked fine (rock-solid and dependable) for
some time, and this is the first time I've ever seen a glitch like this.
Either I've done something somewhere else thats affecting this by some
curious WTH? thing, or there is a sneaky bug that has now decided to
surface, or my MOBO is as carp as I think it is and something is on the
cusp of failing.
Joost Kremers
> Responding to Aaron W. Hsu:
>>
>> ssh -X host
>
>
> Error: Can't open display "localhost:10.0"
you know, perhaps i'm just stupid and i don't understand this X-forwarding thing
at all, but from the logs you posted, i gather that this error message is *not*
from ssh (as it wasn't prepended with "debug0:" or something similar). so,
assuming it's an error from the X client (i.e., the X program running on the
remote machine), isn't it strange that it is trying to connect to localhost?
shouldn't that be 192.168.x.x (or 10.x.x.x, whichever you're using)?
i mean, to the X client localhost is the remote machine, while the display is on
the machine you're connecting from, where the X server is running. right?
--
Joost Kremers joostk...@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
allend
stopping traffic on port 6010.
When I do 'ssh -Y server' then 'netstat -atn' then I see a line:
"tcp 0 0 127.0.0.1:6010 0.0.0.0:*
LISTEN"
This line does not appear when I do 'ssh server'.
Bit Twister
> you know, perhaps i'm just stupid and i don't understand this
> X-forwarding thing at all, but from the logs you posted, i gather
> that this error message is *not* from ssh (as it wasn't prepended
> with "debug0:" or something similar). so, assuming it's an error
> from the X client (i.e., the X program running on the remote
> machine), isn't it strange that it is trying to connect to
> localhost?
Not in my setup.
Guessing actual IP comes from the SSH_CONNECTION variable built from
the SSH_CLIENT contents.
> i mean, to the X client localhost is the remote machine, while the
> display is on the machine you're connecting from, where the X server
> is running. right?
$ get_wan_ip.pl
71.170.056.46
$ echo $DISPLAY
:0.0
ssh $USER@kitty
$ get_wan_ip.pl
24.117.051.251
$ echo $DISPLAY
DISPLAY=localhost:10.0
$ env | grep 170.056
SSH_CLIENT=71.170.056.46 44543 22
SSH_CONNECTION=71.170.056.46 44543 24.117.051.251 22
Mike Jones
Yup. I have 6000-6063 blocked in my firewalls. (Paranoia!)
All networking is done via ssh, and has worked fine up until this week.
Mike Jones
[...]
>> i mean, to the X client localhost is the remote machine, while the
>> display is on the machine you're connecting from, where the X server is
>> running. right?
>
> $ get_wan_ip.pl
> 71.170.056.46
>
> $ echo $DISPLAY
> :0.0
>
> ssh $USER@kitty
> $ get_wan_ip.pl
> 24.117.051.251
>
> $ echo $DISPLAY
> DISPLAY=localhost:10.0
Hmmm?
On the server box...
$SRVR echo $DISPLAY
:0.0
$
On the client box...
$CLIENT echo $DISPLAY
:0.0
$
On the client box...
$CLIENT ssh $SRVR
$SRVR echo $DISPLAY
$
I just got a blank line on the RXVT I sshed to the SRVR on.
This looks wrong.
Joost Kremers
> On the client box...
> $CLIENT ssh $SRVR
> $SRVR echo $DISPLAY
>
> $
>
> I just got a blank line on the RXVT I sshed to the SRVR on.
>
> This looks wrong.
try ssh -Y $SRVR
that should give you something like 'localhost:10.0'.
and even though i don't understand why it says 'localhost' (the display, after
all, is not on the machine one is logged into), it does seem to be correct.
Henrik Carlqvist
> Yup. I have 6000-6063 blocked in my firewalls. (Paranoia!)
>
> All networking is done via ssh, and has worked fine up until this week.
Aha!
Could it be that port 6010 on the remote machine is also blocked for
localhost? If so we might have found the explanation.
Henrik Carlqvist
> perhaps i'm just stupid and i don't understand this X-forwarding thing
> at all,
There is nothing stupid about this, X-forwarding is only a subset of the
tcp port forwarding mechanisms in ssh and it can be confusing.
> isn't it strange that it is trying to connect to localhost?
> i mean, to the X client localhost is the remote machine, while the
> display is on the machine you're connecting from, where the X server is
> running. right?
Yes, you are right. The good old way of doing this would be to do
something like:
xhost +remotemachine
ssh remotemachine (or rsh, telnet or whatever)
export DISPLAY=localmachine:0
xterm
Now the ssh X-forwarding way differs in how it is used and what it does,
you can simply do:
ssh -Y remotemachine
xterm
As you have noticed on remotemachine DISPLAY will automatically be set by
sshd to something like localhost:10. You could say that sshd acts as an X
server (display) with display number 10 on remotemachine. Also, ssh acts
as an X client (program) on localmachine. Things does not get less
confusing with the nomenclature of servers and clients with X...
Now the advantages of X forwarding with ssh is the following:
1) As everything on your display comes from a local program (ssh) there is
no need to give other hosts access to your display with xhost.
2) All the X traffic is encrypted by ssh in the X forwarding tunnel. This
means that you can safely type passwords and other sensitive data in
xterm or any other X application on remote machines without having to
worry about network traffic being sniffed.
3) sshd automatically assigns the right display number for you on the
remote machine.
So X forwarding with ssh really means less work for you and gives you a
secure X connection! The only possible disadvantage is if you have very
much X traffic on a high capacity network. If so your CPUs encrypting
performance might become a bottleneck.
It is possible for ssh to do port forwarding of other traffic than X. With
the -L and -R switches you can do things like tunneling of http traffic.
Doing so will make one of your machines behave like a web server on its
network and the other machine will behave like a web client.
Mike Jones
> Mike Jones <N...@Arizona.Bay> wrote:
>> Yup. I have 6000-6063 blocked in my firewalls. (Paranoia!)
>>
>> All networking is done via ssh, and has worked fine up until this week.
>
> Aha!
>
> Could it be that port 6010 on the remote machine is also blocked for
> localhost? If so we might have found the explanation.
>
> regards Henrik
Not really, as all this has been working fine *via ssh* for some time
now. It /could/ be possible I've been "getting away with" something that
shouldn't really work though?
Mike Jones
> Mike Jones wrote:
>> On the client box...
>> $CLIENT ssh $SRVR
>> $SRVR echo $DISPLAY
>>
>> $
>>
>> I just got a blank line on the RXVT I sshed to the SRVR on.
>>
>> This looks wrong.
>
> try ssh -Y $SRVR
>
> that should give you something like 'localhost:10.0'.
>
> and even though i don't understand why it says 'localhost' (the display,
> after all, is not on the machine one is logged into), it does seem to be
> correct.
Should, but doesn't.
It all seems to hang on that one single detail, something isn't seeing
\getting access to localhost:10.0
Lew Pitcher
Hi! My name is Lew Pitcher!!!
I steal domain names! I pretend to be everyone's friend but I know
that everybody thinks I am a piece of shit because I steal domain
names!
Lew Pitcher
"I am gay and I am so fucking proud of it!"
Check out: http://lewpitcher.ca/
One and only Lew Pitcher? lpit...@teksavvey.com
Have a Great Fucking Day!!!!
Grant
>Responding to Joost Kremers:
>
>> Mike Jones wrote:
>>> On the client box...
>>> $CLIENT ssh $SRVR
>>> $SRVR echo $DISPLAY
>>>
>>> $
>>>
>>> I just got a blank line on the RXVT I sshed to the SRVR on.
>>>
>>> This looks wrong.
>>
>> try ssh -Y $SRVR
>>
>> that should give you something like 'localhost:10.0'.
>>
>> and even though i don't understand why it says 'localhost' (the display,
>> after all, is not on the machine one is logged into), it does seem to be
>> correct.
>
>
>Should, but doesn't.
>
>It all seems to hang on that one single detail, something isn't seeing
>\getting access to localhost:10.0
Unclean shutdown? Did you check for lock files(/var/lock/, var/run/, /etc/??)
can't remember where else they're kept.
Grant.
--
http://bugs.id.au/
Mike Jones
Not thought of that. Just checked and everything seems clean enough.
Martin Schmitz
> $ get_wan_ip.pl
> 71.170.056.46
> $ get_wan_ip.pl
> 24.117.051.251
> $ env | grep 170.056
> SSH_CLIENT=71.170.056.46 44543 22
> SSH_CONNECTION=71.170.056.46 44543 24.117.051.251 22
These are really strange representations of ip addresses, by the way. I
guess that many programs aren't able to handle them the right way. A '0'
at the beginning of an octet means that it's an octal digit.
So these addresses SHOULD be written 71.170.46.46 and 24.117.41.251.
Look what ping does:
[dakini]~# ping 71.170.056.46
PING 71.170.056.46 (71.170.46.46) 56(84) bytes of data.
64 bytes from 71.170.46.46: icmp_seq=1 ttl=53 time=189 ms
In contrast 'ipcalc' isn't able to interpret it right:
[dakini]~# ipcalc 71.170.056.46
Address: 71.170.56.46 01000111.10101010.00111000. 00101110
So maybe this has something to do with your problem...?
Martin
Bit Twister
Not really. I was munging the ip addresses. I have no problems.
Just giving a working example.