Re: Trouble with X11 over SSH on Mandriva 2010.0

On Wed, 24 Feb 2010 12:00:27 -0600, Kevin the Drummer wrote:
> On my Mandriva 2007.0 system X11 works over SSH. Here's my test case
> that I need to have working.
>
> 1. ssh -f somehost xterm
> 2. 'su' in the new xterm
> 3. run any graphical program from the su'd shell
>
> On the Mandriva 2007.0 system this works fine. On my 2010 system I get
> this error:
>
> Error: Can't open display: localhost:11.0
>
>
> Anyone have any suggestions?

-------- standard debugging ssh/sshd problem steps follows: Version 0.4 -------

You may want to read http://www.catb.org/~esr/faqs/smart-questions.html
One tip is to provide configuration and system information.

I recommend modifying Drawing A with your values, print hard copy,
then verify values are correct in /etc/hosts and anywhere else
you use the values in your system/LAN.

You could also change bittwister to your user account name and substitute
your values for each of the test shots. That allows you to cut from this
document and past into a terminal for testing.

If next clean install/update causes ssh to break, you just start cut/pasting
for finding what went broke.

I recommend modifying Drawing A with your values, print hard copy,
then verify values are correct in /etc/hosts and anywhere else
you use the values in your system/LAN.

You could also change bittwister to your user account name and substitute
your values for each of the test shots. That allows you to cut from this
document and past into a terminal for testing.

If next clean install/update causes ssh to break, you just start cut/pasting
for finding what went broke.

If you do not want to use passwords, you may want to read
http://burnz.wordpress.com/2007/10/1...uthentication/


The following is mainly for Mandriva, maybe Suse, Redhat/Fedora and
your install is not using SELinux/ACL's.

I assume you have:
o installed the sshd daemon/service package (OpenSSH Server) on the server.

o sshd's config file looks something like:
$ grep -i forward /etc/ssh/ssh_config
# ForwardAgent no
ForwardX11 yes
ForwardX11Trusted yes

Note: if you change /etc/ssh/ssh_config you need to restart sshd.

o enabled sshd to run On Boot in the server.

o installed ALL system updates and have rebooted.

o DNS server is not running, or you know it is and it gives out
correct values for client and server.

o Your ip routing is working using names of nodes.
ping -c1 server; ping -c1 client from server
ping -c1 server; ping -c1 client from client

o Note about ping. You may have to enable pings to work on your system.
echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all
The above setting will revert to original value on next boot.
cat /proc/sys/net/ipv4/icmp_echo_ignore_all
to see current value.

o no commands are enabled in /etc/hosts.allow and /etc/hosts.deny
man hosts.allow to understand any lines not starting with #

o You have verified that both node's ip addresses match your diagram
and config files using those values.

o You have done the following on the client and server in your user accounts
cd ~/.ssh
chmod 700 .
chmod 600 *


In this document, "server" is where you are trying to ssh
into and "client" is where you ssh from.

Client is where ssh it trying to connect to sshd on the server.

All ssh test shots will be to a user account on the server, NOT ROOT.
Where you see bittwister, or ~/, you should be in/using your user account.

Some commands need root privileges to run. To create a root terminal:
Click up a terminal,
su - root or for the k/ubuntu crowd it would be
sudo -i

Anytime I am working a problem, I will open another root terminal and do a

tail -f /var/log/messages
on each system I am working with.

I suggest you do the same.

PS: To abort tail -f command, do a Control c
To close a terminal/ssh session exit

Basically, these are the failure points we are troubleshooting.

ssh -->/etc/hosts-->client nic--->server nic-->firewall-->
/etc/xinetd.d/sshd-xinetd-->/etc/hosts.allow-->/etc/hosts.deny-->
/etc/ssh/sshd_config-->/etc/hosts --> sshd.

So, in a nutshell:
If you look at diagram A you could get to server's sshd (node2) from
two different clients (node 1 and 3).
You can also get to sshd on node3 from node3 by localhost (127.0.0.1),
eth0 (192.168.1,4) and eth1 (192.168.5.3)

Want we want to do is reduce the failure points for the first ssh test and
prove the remaining points are working. To do that, we work from the
center out, according to the diagram, and test through the above failure
points/files.

Having no commands enabled in hosts.allow/.deny removes those 2 possibilities.
Using ip address, helps rule out /etc/hosts.
Setting sshd to run on boot rules out /etc/xinetd.d/sshd-xinetd.

Running ssh on node2 to sshd on server (node2) gets us the fact that sshd is
working on the server.

The first ssh test shot, on the server, using the server's ip address,
proves the following work on the server.

ssh -->/etc/hosts.allow-->/etc/hosts.deny--> /etc/ssh/sshd_config --> sshd.

Testing using localhost, eth0, eth1 ip addresses prove
/etc/hosts.(allow,deny) and /etc/ssh/sshd_config are working. Testing
using names instead of ip addresses prove /etc/hosts is valid on the
server.

Then you move to the client to test by server ip address to rule out
client's /etc/hosts/ and have access through the server's firewall.

If you want to ssh without a password you would do a
ssh-keygen -t dsa (just hit Enter key at paraphrase question.)
ssh-copy-id -i ~/.ssh/id_dsa.pub (E-Mail Removed)


You are now ready to start testing.

================ server test shot commands follow: ================
sshd has to be running and/or enabled to run on the server so
do a permission check and see if it is running.

ls -al /usr/sbin/sshd
-rwxr-xr-x 1 root root 379292 2008-05-06 14:53 /usr/sbin/sshd

pgrep -lf sshd <===== Should return the pid and program name
3866 /usr/sbin/sshd <============ see, sshd is running and pid is 3866
on my system. Will be different on yours.

If sshd is not running, you might be able to start it with
service sshd start
or maybe
/etc/init.d/sshd start


Next, verify that only sshd On Boot is set for your run level.

chkconfig --list | grep ssh <====== on some systems
sshd 0ff 1ff 2n 3n 4n 5n 6ff <= which run level starts on boot
sshd-xinetd: off <=== on indicates to start when needed

NOTE: Do not have both set On. sshd-xinetd may not show up if xinetd package
is not installed. If not installed, it is ok and do not worry about
any *xinetd file/directory not found errors.

Current run level found with
/sbin/runlevel
N 3 <==== indicates my system is set at 3 and 3n indicates
sshd will be started on boot.


First, prove you can connect to sshd by ip address when you are on the server:

ssh bittwister@$(hostname -i)

If there is nothing in /etc/hosts.allow and /etc/hosts.deny
I expect that to work.

If it fails, make sure your user account's .ssh directory has the correct
permissions by doing:

cd ~/.ssh
chmod 700 .
chmod 600 *
cd

ssh bittwister@$(hostname --ip-address)

If no message showed up in /var/log/messages and there is nothing in
/etc/hosts.allow and /etc/hosts.deny I have no idea what to check next so
jump to the ======== unable to resolve problem============== section.

Test that X forwarding is working, run a gui application like xeyes,
xterm, kwrite, gedit, ...

If you get a open display error, try

xhost +$(hostname --ip-address)
rerun your gui application.

Next, run some server tests to prove network resolution is working.
First test is by fully qualified domain name, second test is by node name

ssh bittwister@$(hostname --fqdn)
ssh bittwister@$(hostname --alias)

Failure on those, will be a /etc/hosts, hostname, DNS, or network problem.
If so, only use the server's ip address from your client until
you get the problem resolved.

============== end of basic server test shots ===================

Once the above works, verify the hostname ip matches what the client sees.
hostname --ip-address
on the server
host servers_hostname_here on the client.

If the hostname --ip-address returns 127.0.0.1 on the server,
you need to use the ip address of the server's nic that
is connected to the client. See diagram A
Here you see where I get server's ip address (node2) for use
by the client (node3)

ifconfig to find the address. Snippet follows

eth1 Link encap:Ethernet HWaddr 00:16:17:57:66:54
inet addr:192.168.5.6 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::216:17ff:fe57:6654/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
the inet addr: field is ip4 ip address
the inet6: field is the ip6 ip address.

Verify the ip address test shot runs on the server
ssh bittwister@servers_ip_here on the server.


Once those run, only the firewall, /etc/hosts.allow, /etc/hosts.deny,
/etc/xinetd.d/sshd-xinetd and /etc/ssh/sshd_config would block
incoming ssh attempts on the server.

You open the Mandriva firewall on the server with
shorewall clear

Before doing that, get the server's ip address for the nic connected to
the client.
ifconfig should give you a list of running nics.

Use the ip address of the server's nic that is connected to the client.
See diagram A.

================ client test shot commands follow: ================

Assuming server is not blocking pings, verify connection with
ping -c1 servers_ip_here on the client, if works then
bittwister@servers_ip_here on the client.
if fails, hit up arrow on the client

and open the firewall on the server with
shorewall clear on the server (Mandriva)
hit a carriage return on the client to run the ssh client to server
test shot again on the client.

No matter what, quickly enable the firewall, with
service shorewall restart
or shorewall restart
on the server.

bittwister@servers_ip_here on the client.

Prove that /etc/hosts on the client is working,
bittwister@servers_name_here

Test that X forwarding is working, run a gui application like xeyes,
xterm, kwrite, gedit, ...


============= unable to resolve problem ============================

Another tip found in http://www.catb.org/~esr/faqs/smart-questions.html
assumes you have used something like http://groups.google.com/advanced_search
to see if there is already a solution submitted for your error
message/problem.

If you still can not resolve your problem, you will need to dump your
settings so we can see them. Some of the files may not exist, that is
ok, but do show all commands and results. Run the following commands
on server and the client. Cut the command and results and paste them into
your reply.

grep -v \# /etc/ssh/sshd_config | uniq
hostname --alias
hostname --fqdn
hostname --ip-address
cat /etc/hosts
cat /etc/sysconfig/network
grep -v \# /etc/resolv.conf
ifconfig
grep -v \# /etc/hosts.allow
grep -v \# /etc/hosts.deny
cat /etc/xinetd.d/sshd-xinetd
route -n


If you see repeatable error messages in the tail -f terminals
every time you do the ssh command, we need to see those also.

Would not hurt to provide results from doing something like
ssh -v bittwister@servers_ip_here
or ssh -vv bittwister@servers_ip_here
which will give increasing debug information with each v.
Take a look at each and decide which one might help us.

Would not hurt for you to modify the following diagram to show us what
you client/server setup is. Change ethX and ip values to match your setup.

Diagram A

.------------------------------. .--------------------.
| ISP assigned ip address | | ip 192.168.3.3 |
| ISP gw 71.171.124.1 | eth0 | gw 192.168.1.1 |
| Actiontech RI408 dmz+-----------+ dmz1 |
| router/modem | | Mandriva 2008.1 |
| ip 192.168.1.1 | | |
`-------+-------------------+--' `--------------------'
| |
| |
| eth0 | eth0
.--------+---------. .------+-----------.
| ip 192.168.1.4 | | ip 192.168.1.2 |
| gw 192.168.1.1 | | gw 192.168.1.1 |
| node1 | | node2 |
| suse 10.3 | | kubuntu 8.4 |
`------------------' | |
| ip 192.168.5.6 |
`------+-----------'
| eth1
|
| eth0
.-------+----------.
| ip 192.168.5.3 |
| gw 192.168.5.6 |
| node3 |
| Mandriva 2008.1 |
`------------------'

In the above setup, ssh from node1 (client) to node2 (server) would be
ssh bittwister@192.168.1.2
but from node3 it would be ssh bittwister@192.168.5.6


PS:
If you run with /etc/hosts.allow and hosts.deny, I found
it helpful for /etc/hosts.deny to contain


ALL: ALL:\
spawn ( \
/bin/echo -e "\n\
TCP Wrappers\: Connection Refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
\n\
User\: %u\n\
Host\: %c\n\
Date\: $(date)\n\
#
#
# After changing this file
# service nfs-server restart
" | /bin/mail -s \"$(uname -n)\" root ) & : DENY

#*********************** end host.deny ********************************

That will send an email to root any time something gets through hosts.allow
without being allowed.

I did a ssh $USER@127.0.0.0, and my hosts.allow does not allow 127.x.x.x
so root was sent the following:

TCP Wrappers: Connection Refused
By: wm81.home.test
Process: sshd (pid 11046)

User: unknown
Host: localhost.localdomain
Date: Sun Aug 17 20:50:41 CDT 2008



I have postfix installed, so I modified aliases to send any mail
to root to me.

tail -11 /etc/postfix/aliases | head -5

# Person who should get root's mail. This alias
# must exist.
# CHANGE THIS LINE to an account of a HUMAN
root: bittwister

And executed:
postalias aliases


Once postfix is restarted, all mail to root (security alerts, cron job
failures, hosts.deny, audit failures,...) automagically shows up in my
bittwister email box.

Example /etc/hosts.allow

#************ Start of hosts.allow. ***************************************
#
# hosts.allow This file describes the names of the hosts which are
# allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
#
ALL: .home.test, 127.0.0.1, 192.168.1.
#************ End of hosts.allow. ***************************************