Post Installation Tasks

It is convenient to additionally set up a key file for the administrative account and configure easy access on the local (Fedora) desktop. Create a key file and a ssh client config file. Leave the password field empty for easy access on a secure desktop and choose a descriptive name for the generated key file.

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.

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 (hostmin here). 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.

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.

Reconfigure firewall permanently

Use one of the following alternatives.

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!

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.

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!

Finally reboot now to check everything from ground up

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

The software monitors the log files for authentication errors. In case of multiple retries from the same IP address, the source IP gets blocked by the firewall. This is to prevent brute force methods for cracking passwords and bots checking for weak passwords. However, if an error occurs in the authentication process, a system administrator may also lock himself out.

If you disabled system users password Login in the previous step so sshd only allows keys, you may skip this section. There will be nothing to log in this regard anymore.

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.

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:

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

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.

Add to the software list as needed.

Finally reboot the server.