Post Installation Tasks

Peter Boy, Stephen Daley, Kevin Fenzi Versi F36-F41 Last review: 2024-10-15
This guide offers a recommended checklist of tasks to ensure the safe and reliable operation of Fedora Server. System administrators may choose whether these tasks apply to their specific use case.

To perform the administrative tasks described here, you need either any Linux or any macOS desktop or laptop. On Windows computers, you need at least Windows 10 1809 or additional programs such as Putty.

1. Simplified access for the administrative account

In a default installation, the root account is locked and administrative work is delegated to a user account that is entitled to root privileges (sudo). It is convenient to make the login process as comfortabe as possible.

A key file for SSH saves the annoying and error-prone typing of the hopefully secure and sufficiently long password. Additionally, you may prepare your local desktop to use a short name instead of having to type in a complete FQN hostname.

  1. On your desktop (Linux or macOS), create a SSH keyfile if not already available. It should not be secured by password to enable automatic processing.

    […]# mkdir ~/.ssh
    […]# cd ~/.ssh
    […]# ssh-keygen -b 4096 -C <YOUR_ACCOUNT>@example.com" -f id_<outputkeyfile>
  2. Transfer the key file to your server.

    […]$ ssh-copy-id -i $outputkeyfile.pub <YOUR_ACCOUNT>@host.example.com
  3. Create a config file on your desktop with a convenient host name for your server.

    […]$ vi ~/.ssh/config
    Host <MYHOST>
            Hostname host.example.com
            User <YOUR_ACCOUNT>
            ProxyCommand none
            ForwardAgent no
            ForwardX11 no
            Port 22
            KeepAlive yes
            IdentityFile ~/.ssh/$outputkeyfile
  4. Test the configuration

    […]$ ssh <MYHOST>

2. Check Cockpit access

Open Cockpit in your desktops browser https://host.example.com:9090. Accept the security warning of your browser. Cockpit uses a self signed certificate.

If you disabled root access during installation (recommended), login as root is not possible.

Login with your administrative user account. At the top you will see a warning that the Web Console is running with limited permissions. Enable administrator access so that all administrative privileges are automatically available after login.

3. Disable SSH Login with passwords for system users

System users are a systematic weak point in defending a server against compromise attacks. This is certainly unintentional on the part of the users. It is due to lack of understanding, insecure passwords, falling for phishing attacks, and alike. On the other hand, it is precisely the users that a server is operated for.

Therefore, it is best practice to minimize the number of system users and instead use virtual accounts or offload applications that require system users to virtual machines or containers. In case of an intrusion, this is a kind of second line of defense, trying to keep the server itself from being infected even then.

In addition, it is a small effort to generally prevent password-based login and to enforce key files. An exception can be defined for individual, selected users. If a server is located in a data center and can only be remotely accessed without much additional effort, it may make sense to set up a "fallback user" if key-based authentication is no longer available for some reason.

As a side effect it saves a lot of warning messages in the log file and makes it easier to check them.

  1. On the server, create a configuration file and edit

    […]# vi /etc/ssh/sshd_config.d/60-local.conf
    
    # Local custimization: disable password login except for
    # one (optionally add some more) user as a fallback option.
    PasswordAuthentication no
    
    Match User hostmin
        PasswordAuthentication yes
    #Match User hostmin2
    #    PasswordAuthentication yes
  2. Reload the sshd daemon

    […]# systemctl reload sshd
  3. Test that everything works as expected

    • Is an authorised user able to log in?

    • Are other users rejected with the message "Permission denied (publickey,gssapi-keyex,gssapi-with-mic)"?

    • If this does not work and/or other users are able to log in with a password besides your known authorized user,

      • install the latest updates.

      • check the file /etc/ssh/sshd_config.d/50-redhat.conf to make sure that it does not include the line "PasswordAuthentication yes" (as this is already the default and should not be repeated or else it could hinder other configurations).

4. Increase security of Cockpit access

Cockpit relies on a password based login to its web interface, even for root (unless the root account is completely locked, locking the account as part of ssh does not help here). And thus it is a potential target for brute-force attacks. In most cases, it is rarely used in daily operations and it may be a good practice to remove the general accessibility in the firewall. Instead, access Cockpit in one of the three secure alternatives described below.

There are several ways to improve the security of Cockpit access. All of them are based on permanently withdrawing access to Cockpit in the firewall. So, reconfigure the firewall permanently.

[…]# firewall-cmd --permanent --remove-service=cockpit
[…]# firewall-cmd --reload

Use one of the following alternatives to access Cockpit.

  1. Access Cockpit via ssh tunnel

    • Login to the server via ssh and setup a tunnel in one go

      ssh host.example.com -L 9090:host.example.com:9090
    • While you remain logged in, open in your local browser localhost:9090

  2. Add Cockpit service temporarily on demand

    • Login to the server and reconfigure firewall

      firewall-cmd –add-service=cockpit
    • When finished remove cockpit again

      firewall-cmd –remove-service=cockpit
  3. Use a secure local proxy

    • Install Cockpit on your local Fedora workstation or on a lab server shielded by a firewall. Configure this instance to access any of your remote Cockpit instances using Cockpits remote administration capability. It uses a protected ssh connection in the public network.

    • In the upper left corner of Cockpit you will see the name of the logged in user and the desktop rsp. the (local) lab server name, along with an expand icon. This opens a box where you can switch to another server or add a new one.

    • The Add new host link opens a simple form to fill in hostname and user. Use your administrative user name on the (remote) server. And you can assign a color. Select automatic login via ssh keyfile. Cockpit will create one for you if none exists or otherwise uses an existing one. For a newly created key, Cockpit installs the public key on the remote server, too.

5. Optionally: Set up root login via key file

Even if you activated root access during installation, you have hopefully kept the default option to restrict root to key file authentification. So you have to set up a key file prior to any ssh login. But be aware! You can still log in to Cockpit’s web interface. Therefore, in this case, be sure to implement the additional security measures described in the previous chapter!

5.1. Prepare a pair of private / public keys

This step is to be performed only if a pair of keys does not already exist. It is best to create the key in the .ssh directory of the desktop user. It should not be secured by password to enable automatic processing. The naming with leading 'id_' und trailing types abbreviation, e.g. '_rsa' is just a common convention, yet helpful.

  1. Execute on the local desktop

    […]$ mkdir ~/.ssh
    […]$ cd ~/.ssh
    […]$ ssh-keygen -t rsa -b 4096  -C "root@example.com" -f <outputkeyfile>

Although the type rsa is widely used, you may adjust your key type accordingly.

5.2. Transfer and install the public key onto the server

You normally use ssh-copy-id to install the public key on the server. However, this requires a password login, which was disabled for root during installation. Therefore, a detour is now required.

  1. Log in to your server via sftp using the unprivileged administration account and transfer the public key file

    […]$ sftp hostmin@example.com
    sftp> put ~/.ssh/<outputkeyfile>.pub
    sftp> quit
  2. Log in to your server via ssh using the unprivileged administration account again

    […]$ ssh  hostmin@example.com
  3. On the server acquire root permissions, move the key file and adjust permissions

    […]$ sudo su -
    […]# mkdir /root/.ssh
    […]# cd  /root/.ssh
    […]# mv /home/hostmin/<outputkeyfile>.pub /root/.ssh/authorized_keys
    […]# chown  -R  root:root  /root/.ssh
    […]# chmod 700 /root/.ssh
    […]# chmod 600 ~/.ssh/*
    […]# restorecon  -R  -vF  /root/.ssh

5.3. Test and Simplify Access

  1. On your local workstation test key file based access:

    […]# ssh -i ~/.ssh/<outputkeyfile>  root@example.com

    adjust file, file type, and domain name as appropriate.

  2. To simplify access create a configuration file on your desktop and define a short name for the connection:

    […]# vi ~/.ssh/config
    #  ###########################################################
    #  my remote server, root account
    #  ###########################################################
    Host myhost
            Hostname myhost.example.com
            User root
            ProxyCommand none
            ForwardAgent no
            ForwardX11 no
            Port 22
            KeepAlive yes
            IdentityFile ~/.ssh/<outputkeyfile>

    again, replace names accordingly.

  3. Check if everything works:

    […]# ssh myhost

6. Double check hostname and time synchronisation

Both are important for trouble-free server operation. Just in case you missed its configuration during installation or it is incorrect, now is the opportunity to fix it.

  1. Check for correct hostname

    […]# hostnamectl
    • Set hostname if required:

      […]# hostnamectl  set-hostname  <YourFQDN>
  2. Control of time zone, time synchronisation, time

    […]# timedatectl
    • Correct time zone if necessary:

      […]# timedatectl set-timezone  <ZONE>
    • If necessary, activate time synchronisation:

      timedatectl set-ntp true
    • Correct time if necessary:

      […]# timedatectl set-time  <TIME>

7. Consolidate network configuration

Depending on installation efforts, network configuration consolidation may be required.

It sounds trivial, but before any change of the network configuration make sure that the entries in the DNS are correct. If you change from DHCP to fixed addresses, you may need to adjust the DNS and vice versa!

  1. Check IP addresses, interface and which protocol stack is used

    […]# ip a
    1:  lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc n
             ...
    2:  enp3s0: <BROADCAST,MULTICAST,UP,LOWER
             ...
    
    […]# nmcli con
    NAME    UUID                                  TYPE      DEVICE
    enp3s0  dabaa33b-25b0-3bfd-8a74-b6b40847a7a4  ethernet  enp3s0
    
    […]# who am i
    root     pts/5        2021-04-09 21:07 (2003:ca:7f05:xx00:yyyy:zzzz:479a:b36e)
    
    […]# nmcli -p -f ipv4.method,ipv6.method con show 'enp3s0'
    =====================================================================
                        Connection details (enp3s0)
    =====================================================================
    ipv4.method:              manual
    ---------------------------------------------------------------------
    ipv6.method:              manual
    ---------------------------------------------------------------------
    Adjust interface names to your custom config
  2. Just in case IPv6 is configured as local only (fe80::…​.) or not static, you may set up a fixed IPv6

    […]# nmcli con mod 'enp3s0' ipv6.method manual \
      ipv6.addresses <YOUR_IPv6_PREFIX>::2/64 \
      ipv6.gateway fe80::1 \
      ipv6.dns "2a01:4f8:xx:yy::zzz:8888 2a01:4f8:xx:yy::zzz:9999"
    […]# nmcli con up 'enp3s0'
    […]# nmcli con reload

    Again, don’t forget to adjust names, prefix, and DNS IP addresses. Pay special attention to the gateway. Using a local address of 1 (fe80::1) is a widely used convention.Another is the IPV6 prefix with the address 1. But each provider may have an even different approach.

    Check connectivity from your local workstation. If that fails, the gateway configuration is the first suspected culprit.

    […]# ping6 <YOUR_IPv6_PREFIX>::2
    […]# # e.g. ping6  2a01:xxx:yyy:zzz::2
  3. Optionally reconfigure IPv4 as static. But make sure the IPv6 address works and don’t change both protocol stacks at the same time (and in the worst case drop connectivity at all):

    […]# nmcli con mod 'enp3s0' ipv4.method manual \
      ipv4.addresses <YOUR_IPv4>/27 \
      ipv4.gateway <GATEWAY> \
      ipv6.dns "<DNS1_IPv4> <DNS2_IPv4>"
    […]# nmcli con up'enp3s0'
    […]# nmcli con reload

    Again, don’t forget to adjust names, prefix, and DNS IP addresses and check connectivity from your local workstation:

    […]# ping <YOUR_IPv4>
  4. Optionally you may have a look at the NetworkManager configuration file

    […]# less /etc/NetworkManager/system-connections/enp3s0.nmconnection

Finally reboot now to check everything from ground up

8. Check LVM storage devices

With Fedora 39 the default LVM configuration has changed. The various LVM management commands now only process registered, 'legitimate' block devices connected to the system. It is essential to check the correctness of the devices file list.

Listing the registered devices

Check the list to see whether all expected devices are included, but also whether each device should actually be part of the current system.

[…]$ sudo lvmdevices
  Device /dev/sda3 IDTYPE=sys_wwid IDNAME=naa.5000000000000000 DEVNAME=/dev/sda3 PVID=IoUGXYfv74B3YrmCoPfh9ZsWZsDrVKAN PART=3
Adding a device (permanently)

This modifies the devices file in /etc/lvm/devices

[…]$ sudo lvmdevices --adddev /dev/<PART>
Removing a device (permanently)

This modifies the devices file in /etc/lvm/devices

[…]$ sudo lvmdevices --deldev /dev/<PART>

9. Consolidate storage configuration

Depending on how you decided on data storage during installation, different supplementary configuration may be required.

  1. If you have chosen the Default partitioning and are content with the basic principle of creating logical volumes for user and any other payload data, there is nothing to do at the moment. The creation of these logical volumes happens in the context of the installation of the corresponding application software.

    You may ensure that the volume group – default name fedora – fills the complete disk. Using Cockpit, in the section Devices choose the volume group. At the top of the new window it shows its total capacity.

  2. If you have chosen the Default partitioning but are not content with the basic principle of creating Logical volumes for user and any other payload data you have now to extend the existing root logical volume to accomodate your data. Cockpit provides an easy way for this. Choose Grow. Determine the new size as needed.

    This is not a recommended procedure! Don’t complain in case of issues.

  3. If you have decided for a stricter separation of system and payload data and created a small Volume Group for system data, you may have already created an additional partition and Volume Group in Anaconda. Otherwise you have to create it here.

    Select Storage in Cockpit’s main menu and then your drive in the right column. Select Create new partition and fill in the upcomming form accordingly. In the box "Devices" select from the Menu "Create LVM2 volume group" and fill in the upcomming form accordingly.

10. Install fail2ban

If a general disabling of the password login is not an option, the installation of fail2ban is worth considering.

The software monitors the log files for authentication errors. In case of multiple retries from the same IP address, it reconfigures the firewall on the fly to block the source IP This is to prevent brute force methods for cracking passwords and bots checking for weak passwords. However, a system administrator may also lock himself out, if if they happen to make a mistake. Therefore, you can exclude destinct IP addresses, e.g. the administrators desktop, from blocking.

  1. Installation of the software and the required Postfix

    […]# dnf install fail2ban
  2. Create and fill configuration file

    […]# vi /etc/fail2ban/jail.local
    # Jail configuration additions for local installation
    
    # Adjust the default configuration's default values
    [DEFAULT]
    # Optional enter an trusted IP never to ban
    #ignoreip = www.xxx.yyy.zzz/32
    bantime  = 6600
    backend = auto
    
    # The main configuration file defines all services but
    # deactivates them by default. We have to activate those neeeded
    [sshd]
    enabled = true
  3. Activate software

    […]# systemctl  enable  fail2ban  --now
  4. Control in the log

    […]# tail -f /var/log/fail2ban.log

11. Install and configure Logwatch

The software checks log files for anomalies and compiles a daily report that can optionally be sent to system administrators via email. It is something like a minimal defensive effort. More powerful, but much more involved would be the installation of a monitor software.

  1. Install software

    […]# dnf install  logwatch
  2. The only configuration required is to enter a real email address for root, the recipient of the report. It is added at the end of the file.

    […]# vi /etc/aliases
    ...
    # Person who should get root's mail
    #root:          marc
    root:		   real@address.for.root
    
    […]# newaliases

12. Manage system updates

It is common sense among system administrators,that regular installation of bug fixes and closing of security vulnerabilities is essential, i.e. applying updates in a systremtatic way. An important step is to automate the process as much as it is reasonable.

Fedora includes a tool, dnf-automatic, which supports several modes of update automation: do not apply, notify admin, apply and notify admin, apply without notification. In particular, alternatives 2 and 3 are definitely worth considering. A general principle might be: Alternative 2 is the minimum choice for almost any system, alternative 3 is not at all suitable for critical systems that must not fail under any circumstances.

We recommend to install at least alternative 2:

[…]# dnf install dnf-automatic

[…]# vi /etc/dnf/automatic.conf
##emit_via = stdio
emit_via = email
##email_from = root@example.com
email_from = root@host.example.com
##

[…]# vi /etc/aliases
...
# Person who should get root's mail
#root:        marc
root:         real@address.for.root

[…]# newaliases
[…]# systemctl enable --now dnf-automatic-notifyonly.timer

If you want to automatically install, activate the corresponding timer instead.

[…]# systemctl enable --now dnf-automatic-install.timer

13. Finally update system and install additional software

Now that secure administrative access is in place, it’s time to update the system and install some useful software. Of course, 'useful software' varies depending on the use case or applications that will be run on Fedora Server. Anyway, a good choice might be vim. With vimdiff e.g. a comparison of updates of configuration files (*.rpmnew) is very comfortable and straightforward.

[…]# dnf install vim-default-editor  --allowerasing
[…]# dnf update

Add to the software list as needed.

Finally reboot the server.