In this review, you will configure SSH key-based authentication, change firewall settings, adjust the SELinux mode and an SELinux Boolean, and troubleshoot SELinux issues.
Outcomes
You should be able to:
Configure SSH keys for key-based authentication.
Configure firewall settings.
Adjust the SELinux mode and SELinux Booleans.
Troubleshoot SELinux issues.
Log in to workstation as student using student as the password.
On workstation, run lab rhcsa-compreview3 start to start the comprehensive review.
This script creates the necessary files to set up the environment correctly.
[student@workstation ~]$lab rhcsa-compreview3 start
Instructions
Perform the following tasks to complete the comprehensive review:
Generate SSH keys for the student user on serverb.
Do not protect the private key with a passphrase.
On servera, configure the student user to accept login authentication using the SSH key pair created for student on serverb.
The student user on serverb should be able to log in to servera using SSH without entering a password.
Use student as the password of the student user, if required.
On servera, change the default SELinux mode to permissive.
Configure serverb to automatically mount the home directory of the production5 user when the user logs in, using the network file system /home-directories/production5.
This network file system is exported from servera.lab.example.com.
Adjust the appropriate SELinux Boolean so that production5 can use the NFS-mounted home directory on serverb after authenticating via SSH key-based authentication.
The production5 user's password is redhat.
On serverb, adjust the firewall settings so that the SSH connections originating from servera are rejected.
On serverb, investigate and fix the issue with the Apache HTTPD daemon, which is configured to listen on port 30080/TCP, but which fails to start.
Adjust the firewall settings appropriately so that the port 30080/TCP is open for incoming connections.
From workstation, open an SSH session to serverb as student.
Generate SSH keys for the student user on serverb using the ssh-keygen command.
Do not protect the private key with a passphrase.
[student@serverb ~]$ssh-keygenGenerating public/private rsa key pair.Enter file in which to save the key (/home/student/.ssh/id_rsa):EnterCreated directory '/home/student/.ssh'.Enter passphrase (empty for no passphrase):EnterEnter same passphrase again:EnterYour identification has been saved in /home/student/.ssh/id_rsa. Your public key has been saved in /home/student/.ssh/id_rsa.pub. The key fingerprint is: SHA256:1TPZ4TXYwiGWfExUGtRTHgfKQbF9hVuLa+VmH4vgkFY student@serverb.lab.example.com The key's randomart image is: +---[RSA 2048]----+ | .+@BO**| | .=.#+B*| | . X.*o=| | . E +.+ | | S o + | | + . o = | | . o o + +| | . . ..| | | +----[SHA256]-----+
On servera, configure the student user to accept login authentication using the SSH key pair you created for student on serverb.
The student user on serverb should be able to log in to servera using SSH without entering a password.
Use student as the password of the student user, when required.
Use the ssh-copy-id command to transfer the public key of the SSH key pair of student on serverb to student on servera.
Use student as the password of the student user, if prompted.
[student@serverb ~]$ssh-copy-id student@servera/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/student/.ssh/id_rsa.pub" The authenticity of host 'servera (172.25.250.10)' can't be established. ECDSA key fingerprint is SHA256:g/fIMtVzDWTbTi1l0OwC30sL6cHmro9Tf563NxmeyyE.Are you sure you want to continue connecting (yes/no)?yes/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keysstudent@servera's password:studentNumber of key(s) added: 1 Now try logging into the machine, with: "ssh 'student@servera'" and check to make sure that only the key(s) you wanted were added.
Use the ssh command to verify that the student user can log in to servera from serverb without entering a password.
[student@serverb ~]$ssh student@servera...output omitted...[student@servera ~]$
On servera, change the default SELinux mode to permissive.
Edit /etc/sysconfig/selinux to set the value of the parameter SELINUX to permissive.
You can use the sudo vi /etc/sysconfig/selinux command to edit the configuration file as the superuser.
Use the password student, if prompted.
...output omitted... #SELINUX=enforcing SELINUX=permissive ...output omitted...
Use the sudo systemctl reboot command to reboot the system as the superuser.
[student@servera ~]$sudo systemctl rebootConnection to servera closed by remote host. Connection to servera closed.[student@serverb ~]$
Configure serverb to automatically mount the home directory of the production5 user when the user logs in, using the network file system /home-directories/production5.
This network file system is exported from servera.lab.example.com.
Adjust the appropriate SELinux Boolean so that production5 can use the NFS-mounted home directory on serverb after authenticating via SSH key-based authentication.
The production5 user's password is redhat.
On serverb, use the sudo -i command to switch to the root user account.
[student@serverb ~]$sudo -i[sudo] password for student:student[root@serverb ~]#
Install the autofs package.
[root@serverb ~]#yum install autofs...output omitted...Is this ok [y/N]:y...output omitted... Installed: autofs-1:5.1.4-29.el8.x86_64 Complete!
Create the autofs master map file called /etc/auto.master.d/production5.autofs with the following content.
/- /etc/auto.production5
Retrieve the details of the production5 user to get the home directory path.
[root@serverb ~]#getent passwd production5production5:x:5001:5001::/localhome/production5:/bin/bash
Create the /etc/auto.production5 file with the following content.
/localhome/production5 -rw servera.lab.example.com:/home-directories/production5
Restart the autofs service.
[root@serverb ~]#systemctl restart autofs
On servera, verify that the production5 user is not able to log in to serverb using SSH public-key authentication.
An SELinux Boolean causes this issue which you will fix in the following steps.
From workstation, open an SSH session to servera as student.
[student@workstation ~]$ssh student@servera...output omitted...[student@servera ~]$
Switch to the production5 user using the password redhat.
[student@servera ~]$su - production5Password:redhat[production5@servera ~]$
Use the ssh-keygen command to generate the SSH keys as production5.
[production5@servera ~]$ssh-keygenGenerating public/private rsa key pair.Enter file in which to save the key (/home/production5/.ssh/id_rsa):EnterCreated directory '/home/production5/.ssh'.Enter passphrase (empty for no passphrase):EnterEnter same passphrase again:EnterYour identification has been saved in /home/production5/.ssh/id_rsa. Your public key has been saved in /home/production5/.ssh/id_rsa.pub. The key fingerprint is: SHA256:zmin1nmCt4H8LA+4FPimtdg81nl7ATbInUFW3HSPxk4 production5@servera.lab.example.com The key's randomart image is: +---[RSA 2048]----+ | .oo.o. . | | .. . .o o | | . o o E .| | . o * + | | . . .So . | | . + = . | | *.*+=. . | | Oo+***.o | | o.=o.=** | +----[SHA256]-----+
Use the ssh-copy-id command to transfer the public key of the SSH key pair of production5 on servera to production5 on serverb.
Use redhat as the password of the production5 user, if prompted.
[production5@servera ~]$ssh-copy-id production5@serverb/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/production5/.ssh/id_rsa.pub" The authenticity of host 'serverb (172.25.250.11)' can't be established. ECDSA key fingerprint is SHA256:ciCkaRWF4g6eR9nSdPxQ7KL8czpViXal6BousK544TY.Are you sure you want to continue connecting (yes/no)?yes/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keysproduction5@serverb's password:redhatNumber of key(s) added: 1 Now try logging into the machine, with: "ssh 'production5@serverb'" and check to make sure that only the key(s) you wanted were added.
Use the SSH public key-based authentication instead of password-based authentication to log in to serverb as production5.
This command should fail.
[production5@servera ~]$ssh -o pubkeyauthentication=yes \-o passwordauthentication=no production5@serverbproduction5@serverb: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
Set the appropriate SELinux Boolean setting on serverb, so that production5 can log in to serverb using the SSH public key-based authentication and use the home directory.
On serverb as root, set the use_nfs_home_dirs SELinux Boolean to true.
[root@serverb ~]#setsebool -P use_nfs_home_dirs true
Use the SSH public key-based authentication instead of password-based authentication to log in to serverb as production5.
This command should succeed.
[production5@servera ~]$ssh -o pubkeyauthentication=yes \-o passwordauthentication=no production5@serverb...output omitted...[production5@serverb ~]$
On serverb, adjust the firewall settings so that SSH connections originating from servera are rejected.
The servera system uses the IPv4 address 172.25.250.10.
Use the firewall-cmd command to add the IPv4 address of servera to the firewalld zone called block.
[root@serverb ~]#firewall-cmd --add-source=172.25.250.10/32 \--zone=block --permanentsuccess
Use the firewall-cmd --reload command to reload the changes in the firewall settings.
[root@serverb ~]#firewall-cmd --reloadsuccess
On serverb, investigate and fix the issue with the Apache HTTPD daemon, which is configured to listen on port 30080/TCP, but which fails to start.
Adjust the firewall settings appropriately so that port 30080/TCP is open for incoming connections.
Use the systemctl command to restart the httpd service.
This command fails to restart the service.
[root@serverb ~]#systemctl restart httpd.serviceJob for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.
Use the systemctl status command to investigate the reason for the failure of the httpd service.
[root@serverb ~]#systemctl status httpd.service● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Mon 2019-04-15 06:42:41 EDT; 5min ago Docs: man:httpd.service(8) Process: 27313 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE) Main PID: 27313 (code=exited, status=1/FAILURE) Status: "Reading configuration..." Apr 15 06:42:41 serverb.lab.example.com systemd[1]: Starting The Apache HTTP Server...Apr 15 06:42:41 serverb.lab.example.com httpd[27313]: (13)Permission denied: AH00072: make_sock: could not bind to address [::]:30080Apr 15 06:42:41 serverb.lab.example.com httpd[27313]: (13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:30080Apr 15 06:42:41 serverb.lab.example.com httpd[27313]: no listening sockets available, shutting down Apr 15 06:42:41 serverb.lab.example.com httpd[27313]: AH00015: Unable to open logs Apr 15 06:42:41 serverb.lab.example.com systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE Apr 15 06:42:41 serverb.lab.example.com systemd[1]: httpd.service: Failed with result 'exit-code'. Apr 15 06:42:41 serverb.lab.example.com systemd[1]: Failed to start The Apache HTTP Server.
Notice the permission error in the preceding output, which signifies that the httpd daemon failed to bind to port 30080/TCP.
The SELinux policy can be a potential restriction for an application to bind to a port.
Press q to quit the preceding systemctl command.
Use the sealert command to determine if an SELinux policy is preventing httpd from binding to port 30080/TCP.
[root@serverb ~]#sealert -a /var/log/audit/audit.log100% done found 1 alerts in /var/log/audit/audit.log -------------------------------------------------------------------------------- SELinux is preventing /usr/sbin/httpd from name_bind access on the tcp_socket port 30080. ***** Plugin bind_ports (92.2 confidence) suggests ************************ If you want to allow /usr/sbin/httpd to bind to network port 30080 Then you need to modify the port type. Do # semanage port -a -t PORT_TYPE -p tcp 30080 where PORT_TYPE is one of the following: http_cache_port_t, http_port_t, jboss_management_port_t, jboss_messaging_port_t, ntop_port_t, puppet_port_t. ...output omitted...
The preceding log message reveals that the port 30080/TCP does not have the appropriate SELinux context http_port_t, causing SELinux to prevent httpd to bind to this port.
The log message also produces the syntax of the semanage port command so that you can easily fix the issue.
Use the semanage port command to set the appropriate SELinux context on the port 30080/TCP for httpd to bind to it.
[root@serverb ~]#semanage port -a -t http_port_t -p tcp 30080
Use the systemctl command to restart httpd.
This command should successfully restart the service.
[root@serverb ~]#systemctl restart httpd
Add the port 30080/TCP to the default firewalld zone called public.
[root@serverb ~]#firewall-cmd --add-port=30080/tcp --permanentsuccess[root@serverb ~]#firewall-cmd --reloadsuccess
Exit the root user's shell.
[root@serverb ~]#exitlogout
Log off from serverb.
[student@serverb ~]$exitlogout Connection to serverb closed.