SSH Publication Key Authentication Fails When Home is on NFS

As the title stated, regardless how I try, I couldn't get SSH publication key authentication to work for a Linux host. It turns out that the Linux host that runs the SSH server has SELinux enabled. To make public key authnentication work for SSH, we simply need to configure SELinux, i.e.,

sudo setsebool -P use_nfs_home_dirs 1

SeLinux Setting for Mercurial Web Access

If you use the Mercurial Revision Control System or HG, you may set up a Mercurial CGI Server integrating with a HTTP server, such as the Apache HTTP server so that you can provide read and write access via HTTPS.

The Mercurial official website provides a well-written documentation for this. However, you may run into the 501 Internal Server Error when you try to browse the repository via the Web or encounter the 500 Permission Denied Error when you try to push your local changes to the remote Mercurial repository via the HTTPS protocol. These errors often occur when you have SeLinux enabled.

The following provides a simple script to set up the proper SeLinux context for Mercurial repositories.

Assume the parent directory of all your Mercurial repositories is in the environment variable HG_PARENT_DIR, the Apache HTTP server is run as user belonging to group stored in environment variable HTTP_GROUP, and you wish the user whose username's value in environment variable HG_USER to manage all your Mercurial repositories. You can set up the proper SeLinux context using the following commands on a Linux shell by initially assigning hguser, apache, and /home/hg to environment variables HG_USER, HG_GROUP, and HG_PARENT_DIR.

HG_USER=hguser
HTTP_GROUP=apache
HG_PARENT_DIR=/home/hg
chown -R ${HG_USER}:${HTTP_GROUP} $HG_PARENT_DIR$
chmod -R ug+rw  $HG_PARENT_DIR$
chcon -R -t httpd_content_t $HG_PARENT_DIR$
find $HG_PARENT_DIR$ -name .hg -exec chcon -R -t httpd_sys_content_rw_t {} \;
find $HG_PARENT_DIR$ -name \*.cgi -exec chcon -t httpd_sys_script_exec_t {} \;

The above script does not give the HTTP Web server process any more permissions than necessary, but does give and confine the required permissions to your Mercurial repositories.

Configuring SELinux to Allow HTTPD Scripts and Modules to Establish TCP Connections

In a PHP script that establishes database connection to a PostgreSQL database via TCP socket, I encountered a SELinux denial. The message in the error log is,

SELinux is preventing /usr/sbin/httpd from name_connect access on the tcp_socket.

A quick fix is to allow HTTPD scripts and modules to connect to the network using TCP, i.e., run the following,

sudo setsebool -P httpd_can_network_connect 1

By the way, the relevant system information is as follows,

• Operating System (output of uname -sr): Linux 3.12.9-201.fc19.x86_64
• SELinux Policy Module: selinux-policy.noarch, version 3.12.1-74.17.fc19

Configuring SeLinux to Allow Secure Shell Service (SSHD) on Non-Default Port

The Secure Shell Service (SSHD) by default runs on TCP port 22. We sometimes want the Secure Shell Service (SSHD) to listen on a non-default port or to listen on more than one port. When the Security-Ehanced Linux (SeLinux) is turned on, we will have to configure both the Secure Shell Service and SeLinux because SeLinux by default has a policy that allows the Secure Shell Service to listen on TCP port 22 only.

Below are the steps for a recent release of the Fedora Linux distribution in which the Secure Shell Service (SSHD) is provided by OpenSSH and services are managed by systemd to allow the Secure Shell Service to listen on both TCP ports 22 and 64422.

• Configure OpenSSH to listen on 64422.
  OpenSSH's configuration files in Fedora Linux is at /etc/ssh. Open /etc/ssh/sshd_config and add the following line to the file.

  
      Port 64422
      

• Configure SeLinux to allow the Secure Shell Service to bind to TCP port 64422. We use semanager to configure SeLinux policies. First, let us look up what ports are allowed to bind to the Secure Shell Service.

  
      $ sudo semanage port -l | grep ssh
      ssh_port_t                     tcp      22
      

  which shows that the Secure Shell Service is allowed to bind to TCP port 22. We can now add a second port, 64422, to the list of ports that are allowed to bind to the Secure Shell Service.

  
      $ sudo semanage port -a -t ssh_port_t -p tcp 64422
      

  The above step usually takes a while to run. Upcon completion, we can now verify that the Secure Shell Service can now bind to both TCP ports 22 and 64422.
  

  
      $ sudo semanage port -l | grep ssh
      ssh_port_t                     tcp      64422, 22
      

• Restart the Secure Shell Service using systemctl.

  
      $ sudo systemctl restart sshd.service
      

  Upon completion, we can verify that the service is now listenting to both TCP port 22 and 64422.
  

  
      $ sudo systemctl status sshd.service
      sshd.service - OpenSSH server daemon
            Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
            Active: active (running) 
                    since Sun, 23 Nov 2014 00:34:31 -0500; 6s ago
           Process: 2311 ExecStartPre=/usr/sbin/sshd-keygen 
                         (code=exited, status=0/SUCCESS)
          Main PID: 2312 (sshd)
            CGroup: name=systemd:/system/sshd.service
                    └ 2312 /usr/sbin/sshd -D
  
      Nov 23 00:34:31 localhost.localdomain sshd[2312]: 
                      Server listening on 0.0.0.0 port 64422.
      Nov 23 00:34:31 localhost.localdomain sshd[2312]: 
                      Server listening on :: port 64422.
      Nov 23 00:34:31 localhost.localdomain sshd[2312]: 
                      Server listening on 0.0.0.0 port 22.
      Nov 23 00:34:31 localhost.localdomain sshd[2312]: 
                      Server listening on :: port 22.