Why would sshd daemon fail a connection that manually started /usr/sbin/sshd permits?

Question

The goal is to setup FreeNX. Following the advise from another serverfault user I was able to test various configurations of ssh and nxsetup connections to the sshd server as daemon or manually started instance of /usr/sbin/sshd.

The daemon version will not accept the connection from nxsetup but the manual instance /usr/sbin/sshd will.

The steps:

1. Start ssh-agent eval $(ssh-agent) and add root key ssh-add

2. Stop the sshd daemon,

3. Start the manual instance with:

   # /usr/sbin/sshd -d -p 22 -f /path/to/test/sshd_config_nx
   

4. The command I'm having trouble with is:

   # nxsetup --install --clean --purge
   

5. Success! However, skip 2, 3 and connection fails

The setup of the sshd daemon and the manual /usr/sbin/sshd config files:

/etc/ssh/sshd_config is of course the daemon's default config directory. Both this file and my test config, ~/sshd_config_nx, (have become) are exactly the same (diff).

Successful ssh tests include:

from client over LAN to:
    - sshd server daemon
    - manual sshd server
from ssh with loopback (127.0.0.1) to:
    - sshd server daemon
    - manual sshd server

Permissions

I read a lot of posts about ssh/sshd authentication problems involving permissions. My root user has these permissions: /root/.ssh is 700 and /root/.ssh/* is 600. The nxserver default location for authorized_keys2 is /var/lib/nxserver/home/.ssh/. I've applied the same permissions here. The only difference between /root and /var is the latter is owned nx:root. For this reason I tested the permissions the same for both owner and group with world still 0. This didn't make any difference, and it bugged ssh-add. So I changed them back to 700 and 600. I haven't heard that config permissions matter, but I made them both the same and since I'm performing these commands as root, the user:grooup is the same also.

Why would sshd daemon fail a connection that manually started /usr/sbin/sshd permits?

//EDIT: I've tried a few more things in the event I'm just stupid:

• add ssh-agent in steps.

• I made sure any changes I made to ~/.ssh and /var/lib/nxserver/home/.ssh permissions were followed by the advise from another post with a similar problem with daemon and manually started sshd: #restorecon -r -vv /root/.ssh

• The server has openssh-5.3p1-84.1.el6.i686, for this reason the authorized_key file is not what you might expect. FreeNX wants authorized_keys2 located in the /var directory. Its important to note here that ssh is working. The test sshd_config_nx uses this /var location allways, and I toggle the line in the /etc/ssh/sshd_config when I attempt the nxsetup connection through the daemon (to suit the nxsetup instructions).

• added pastebin of /etc/ssh/sshd_config

• The directories mentioned above:

  [root@mrwizard ~]# ls ~/.ssh
  drwx------.  2 root root 4096 Oct  6 17:47 .
  dr-xr-x---. 47 root root 4096 Oct  7 18:58 ..
  -rw-------.  1 root root 2761 Oct  5 18:50 authorized_keys
  -rw-------.  1 root root 1865 Oct  6 15:54 authorized_keys2
  -rw-------.  1 root root 1679 Oct  6 15:52 authorized_keys2.new
  -rw-------.  1 root root 1743 Oct  5 18:38 id_rsa
  -rw-------.  1 root root  401 Oct  5 18:38 id_rsa.pub
  -rw-------.  1 root root  391 Oct  6 17:47 known_hosts 
  
  [root@mrwizard ~]# ls -al /var/lib/nxserver/home/.ssh/
  drwx------. 2 nx root 4096 Oct 7 18:38 . 
  drwx------. 5 nx root 4096 Oct  7 18:38 ..
  -rw-------. 1 nx root  669 Oct  7 18:38 authorized_keys2
  -rw-------. 1 nx root  668 Oct  7 18:38 client.id_dsa.key
  -rw-r--r--. 1 nx root  392 Oct  7 18:38 known_hosts 
  
  [root@mrwizard ~]# ls -al /etc/ssh/
  drwxr-xr-x.   2 root root   4096 Oct  6 18:47 . 
  drwxr-xr-x. 135 root root  12288 Oct  7 18:38 ..
  -rw-------.   1 root root 125811 Feb 21  2013 moduli
  -rw-r--r--.   1 root root   2061 Sep 22 14:32 ssh_config
  -rw-------.   1 root root   4492 Oct  6 18:47 sshd_config
  -rw-------.   1 root root    668 Oct  5 16:53 ssh_host_dsa_key
  -rw-r--r--.   1 root root    590 Oct  5 16:53 ssh_host_dsa_key.pub
  -rw-------.   1 root root    963 Oct  5 16:53 ssh_host_key
  -rw-r--r--.   1 root root    627 Oct  5 16:53 ssh_host_key.pub
  -rw-------.   1 root root   1671 Oct  5 16:53 ssh_host_rsa_key
  -rw-r--r--.   1 root root    382 Oct  5 16:53 ssh_host_rsa_key.pub
  

Answer 1

You have selinux enabled. For failed connections you should see entries in /var/log/audit/audit.log. You have two options:

• Disable selinux. Go ahead, all your friends are doing it.
• Fix your selinux configuration. This may be as simple as running fixfiles with the appropriate arguments to relabel your filesystem, or it may require explicitly setting the selinux context of files or directories.

If you opt for the second -- arguably more correct but more labor intensive -- solution, you may want to open a second question containing the relevant entries from your audit.log.

You can try out the first solution by running:

# setenforce 0

This will put selinux into permissive mode, but is not persistent across a reboot. To persistently disable selinux, edit /etc/selinux/config and set:

SELINUX=disabled

Or:

SELINUX=permissive

The latter setting will leave selinux enabled but in permissive mode, so it will log violations to audit.log but will not