4

I have a CentOS 6.5 server with the following situation:

  • I can ssh to the root user of this server from a Mac OS X machine. It connects relatively quickly, and allows me to fire off xterm sessions.

  • I can ssh to a different account on this same server from the same Mac OS X machine, but it takes awhile to connect and does not let me fire off xterm sessions ( with the rather common "xterm Xt error: Can't open display: localhost:10.0" error ).

What I am having a hard time with is why root works perfect, but my other user does not. In other words, 1. Why is the "root" user speedy on the ssh connection, but my other user ( "wmsodbc" ) is not? 2. Why does the "root" user allow me to fire off xterm windows, but the other user does not?

Note that I connect to the machine both times in the exact same way, with the exact same ssh configuration. The only thing changes is the user ( "ssh root@server" or "ssh wmsodbc@server" ).

I imagine it is a problem with one of the following, but I don't know how to figure out which:

  1. Mac OS X setup
  2. CentOS 6.5 general server setup
  3. The setup of my other user ( the one that does not work ) is wrong somehow

Note that I copied this user ( wmsodbc ) directly from another, older, RedHat Enterprise server, and I don't have this problem at all on that server.

Also, I think I actually found the reason for the "slower connection" when I enabled -vvv debugging when doing the ssh connection: xauth is timing out when it tries to lock the file. Still would not mind help on this issue, but I am also going to search for why xauth times out - I see lots of references to that problem via Google.

Tony B
  • 254
  • 2
  • 12
  • 4
    Double check at all the files in the users home directory (like the .xauth file) are actually owned by that user, and not root, or some other userid. – Zoredache Feb 20 '14 at 17:55
  • Yes, I just checked that again ( checked it multiple times before as well ). Home folder is owned by my user ( wmsodbc ), and all the other files are also owned by my user. The only exception would be the ".." reference, which makes sense. – Tony B Feb 21 '14 at 17:03
  • Something you said made me look more closely at some of the .[xX]* files in my home directory, I see a ".xauthVP8raV" file. My current .Xauthority is empty, but my old one ( .Xauthority.bak ), from an older server, is still there. To me, the permissions and ownership look correct, like I said above. – Tony B Feb 21 '14 at 17:11
  • Compare permissions on the .Xauthority file between root and the test user. I would try rm the old one and let ssh and xauth set it up. – Fred the Magic Wonder Dog Feb 21 '14 at 17:31
  • thanks. Both have "rw" for only the owner of the file. On a hunch, I also compared the security context ( ls -Z .Xauthority ) and noticed a slight discrepency, so making sure they both have the same security context as root. Later I will try to delete the file as well ( it is empty, so I guess there is no harm in deleting it ). – Tony B Feb 21 '14 at 19:04
  • Well, neither the security context change or the deletion of .Xauthority fixed it. Was worth a try. Thanks. – Tony B Feb 21 '14 at 19:05

1 Answers1

2

Ok, I finally found the problem. It had to do with SELinux. If you ever have similar problems, a simple test would be to "setenforce 0" to turn it off temporarily. If it works when "setenforce 0", but does not work with "setenforce 1", then the problem is some SELinux related issue. In my case, I had to run the following command:

chcon 'unconfined_u:object_r:user_home_dir_t:s0' $HOME

It was hard to see because my "/home/wmsodbc" was really a link to someplace else:

lrwxrwxrwx. wmsodbc wms unconfined_u:object_r:home_root_t:s0 /home/wmsodbc -> /other/wmsodbc
drwx--x--x. wmsodbc wms unconfined_u:object_r:user_home_dir_t:s0 /other/wmsodbc

Maybe that will well someone else.

Tony B
  • 254
  • 2
  • 12