CentOS 7 Initial Server Setup: A Legacy Checklist for Modern Linux

Publication date: December 8, 2020

Updated: July 29, 2026

Overview

This historical walkthrough records the initial configuration used for CentOS 7.6 (1810). For a new system, translate each goal to the supported distribution’s current tooling and security guidance.

1. Legacy initial-setup walkthrough

This section describes the basic settings required immediately after CentOS installation.

1-1. Identify the operating system

Confirm the installed distribution and release before applying distribution-specific commands.

[root@hostname ~]# cat /etc/redhat-release

CentOS Linux release 7.6.1810 (Core)

This output identifies CentOS Linux 7.6.1810. That release is now historical and unsupported.

1-2. Install diagnostic tools

A minimal installation may omit legacy networking and diagnostic utilities. The original walkthrough installed the following packages with yum.

On a supported system, update through the distribution's current package manager and install only tools required by the operating runbook.

[root@hostname ~]# yum install -y net-tools

[root@hostname ~]# yum install -y wget

[root@hostname ~]# yum install -y tcpdump

[root@hostname ~]# yum install -y traceroute

Installing net-tools makes legacy commands such as ifconfig available.

wget retrieves resources over protocols such as HTTP and HTTPS.

tcpdump captures and inspects network packets; packet captures can contain sensitive data and require appropriate access controls.

traceroute probes the network path toward a destination, although filtering can make its output incomplete.

1-3. Historical SELinux setting

The original walkthrough disabled SELinux. That weakens host protection and is not recommended for a current deployment; keep SELinux enforcing and fix labels or policy rules instead.

If a controlled diagnostic requires permissive mode, make the change temporary, record the relevant denials, and restore enforcing mode. SELinux is a preventive mandatory-access-control layer as well as a way to limit the impact of a compromise. The commands below remain only to document the original CentOS 7 procedure.

The historical deactivation procedure was:

[username@hostname ~]$ getenforce

Disabled

The original procedure edited the configuration when the result was not Disabled:

[username@hostname ~]$ vi /etc/selinux/config

SELINUX=enforcing

SELINUX=disabled

The historical change modified SELINUX, not SELINUXTYPE, and required a restart. Do not apply it to a current build; diagnose denials and maintain enforcing mode.

1-4. Create an administrative user

Routine work should use a named account with only the required privileges. This provides attribution, reduces accidental system-wide changes, and allows access to be removed per person or role. Direct root login is unnecessary when approved administrative elevation is available.

The historical example created a local user and password:

[root@hostname ~]# useradd xxxxxx

[root@hostname ~]# passwd xxxxxx

Replace xxxxxx with the account name and use the current password and privilege-management policy.

1-5. Change the root password

The original walkthrough switched to root and changed its password:

[username@hostname ~]$ su -

[root@hostname ~]# passwd

Do not use a default or predictable password. Follow the supported distribution's authentication policy, prefer centrally managed credentials where available, and do not treat an eight-character minimum as a current recommendation.

1-6. Restrict SSH login users

The historical configuration disabled direct root SSH login and allowed only the named operational account. Apply SSH access changes only with an existing recovery path and a second session available for testing.

[username@hostname ~]$ su -

[root@hostname ~]# vi /etc/ssh/sshd_config

#LoginGraceTime 2m

#PermitRootLogin yes

#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10

#LoginGraceTime 2m

PermitRootLogin no

AllowUsers xxxxxx

#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10

Replace xxxxxx with the exact operational account name.

An incorrect AllowUsers value can lock out every remote administrator. Validate the name, syntax, and recovery procedure before reloading SSH.

Check the syntax and restart sshd.

[root@hostname ~]# /usr/sbin/sshd -t

[root@hostname ~]# systemctl restart sshd

Keep the current session open while confirming in a second session that the operational user can log in and elevate privileges. Only then verify that direct root login is denied.

1-7. Time synchronization

Accurate system time is required for reliable logs, certificates, authentication, and incident analysis. The original CentOS 7 check looked for chronyd and inspected timedatectl.

[root@hostname ~]# ps aux | grep chronyd

chrony     567  0.0  1.3 117804 13664 ?        SL    May 04   0:04 /usr/sbin/chronyd

root     32489  0.0  0.0 112732   972 pts/1    S+   16:30   0:00 grep --color=auto chronyd

[root@hostname ~]# timedatectl

      Local time: day 2020-11-29 16:30:43 JST

  Universal time: day 2020-11-29 07:30:43 UTC

        RTC time: day 2020-11-29 07:30:43

       Time zone: Asia/Tokyo (JST, +0900)

     NTP enabled: yes

NTP synchronized: yes

 RTC in local TZ: no

      DST active: n/a

Verify the configured time zone, the displayed local time, and the synchronization status. Field names differ between systemd versions.

1-8. Historical SSH key setup

SSH public-key authentication reduces exposure to password guessing when keys and server access are managed correctly.

The original example generates an RSA-2048 private key on the server without a passphrase and then copies it to the client. For a current setup, generate an Ed25519 key on the trusted client, protect it with a passphrase where practical, install only the public key on the server, and test a second session before disabling password authentication.

The commands below are retained as the original historical procedure.

[username@hostname ~]$ su - xxxxxx

[xxxxxx@hostname ~]$ ssh-keygen -t rsa -b 2048

Here, xxxxxx is the additional account. In this obsolete server-side flow, accepting every default also created an unencrypted private key. A key passphrase encrypts the private key at rest; it does not turn public-key login into server password authentication. Current setups should generate the key on the trusted client and keep the private key there.

Then confirm that the key has been created.

[xxxxxx@hostname ~]$ ll /home/xxxxxx/.ssh

The original check expected the private key id_rsa and public key id_rsa.pub. It then renamed the public key and moved the private key for download:

[xxxxxx@hostname ~]$ mv /home/xxxxxx/.ssh/id_rsa.pub /home/xxxxxx/.ssh/authorized_keys

[xxxxxx@hostname ~]$ mv /home/xxxxxx/.ssh/id_rsa /home/xxxxxx/id_rsa

This transfer of a server-generated private key is retained only as historical context. Do not reproduce it for a new installation. The original procedure deleted the server copy after the transfer:

[xxxxxx@hostname ~]$ rm /home/xxxxxx/id_rsa

Before disabling password authentication, test public-key login in a second session and verify an independent recovery path.

[username@hostname ~]$ su -

[root@hostname ~]# vi /etc/ssh/sshd_config

PasswordAuthentication yes

PasswordAuthentication no

Check the syntax and restart sshd.

[root@hostname ~]# /usr/sbin/sshd -t

[root@hostname ~]# systemctl restart sshd

Recheck public-key login after the SSH daemon reload and monitor authentication logs for unexpected failures.

2. Conclusion

The original checklist covered OS identification, tools, administrative users, SSH access, and time synchronization.

Do not use it as a current production baseline. Start from the security guidance for a supported distribution, keep SELinux and the firewall enabled, and test access changes with a rollback path.

Official references

• CentOS Linux lifecycle information
• Red Hat SELinux states and modes
• Red Hat DNF administration