Prev: network mirror
Next: Sudden X11 forwarding glitch - Can't open display"localhost:10.0"
From: Mike Jones on 10 Feb 2010 11:44
Responding to allend:

> Just wondering whether there is something in your setup that is 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'.


Yup. I have 6000-6063 blocked in my firewalls. (Paranoia!)

All networking is done via ssh, and has worked fine up until this week.

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
From: Henrik Carlqvist on 10 Feb 2010 15:00
Joost Kremers <joostkremers(a)yahoo.com> wrote:
> 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.

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(a)localhost postmaster(a)localhost

From: Mike Jones on 10 Feb 2010 19:19
Responding to Henrik Carlqvist:

> Mike Jones <Not(a)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?

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
From: Grant on 11 Feb 2010 03:35
On Thu, 11 Feb 2010 00:20:55 GMT, Mike Jones <Not(a)Arizona.Bay> wrote:

>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/
From: Martin Schmitz on 11 Feb 2010 15:52
Bit Twister wrote:
> $ 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

First  |  Prev  | 
Pages: 1 2 3 4
Prev: network mirror
Next: Sudden X11 forwarding glitch - Can't open display"localhost:10.0"