Initial configuration required when CentOS is installed


Publication date:December 8, 2020



INFOMARTION > Initial configuration required when CentOS is installed

summary

This is about the first configuration you need to do after installing CentOS, and we will build it using CentOS 7.6 (1810).

Table of Contents

  1. basic setting
  2. summary

1. basic setting

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

1-1. Check OS

First, make sure you have the correct OS installed.

[root@hostname ~]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)

"CentOS Linux release 7.6.1810 (Core)" is the installed OS. Please check if it is correct.

1-2. Tool Installation

Immediately after installation, basic commands such as ifconfig cannot be executed. Therefore, the installation is performed so that basic networking and other commands can be executed by yum commands.

Please execute "yum -y update" as necessary since it is possible to modernize what has already been installed.

[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

net-tools・・・The ifconifg command and other commands can be used after installation.

wget・・・Literally, it allows you to use the wget command. Simply explained, it is a command to send a http request.

tcpdump・・・Literally, you can use the tcpdump command. Simply put, it allows you to monitor requests sent to the server.

traceroute・・・Literally, you can use the traceroute command. Briefly, it shows the route of the destination IP.

1-3. Disabling selinux

Disable selinux as it is enabled and may behave unexpectedly.

To begin with, selinux is a security setting. If you are familiar with it, there is no problem to enable it, but if it is difficult, disable it. Disabling selinux does not necessarily make security vulnerable.I personally don't understand it well, but it is more likely to cause trouble if it is enabled. Simply explained, since selinux is a security measure after the server has been broken into (configured to minimize damage in the event of a break-in), it is rather more important to take security measures to prevent the server from being broken into.

Below is the procedure for deactivation.

[username@hostname ~]$ getenforce
Disabled

If it is not "Disabled", you can change it by the following procedure.

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


config【Before change】


SELINUX=enforcing


config【After change】


SELINUX=disabled

There are "SELINUX" and "SELINUXTYPE", but it is the "SELINUX" that is to be changed. Note that if "SELINUXTYPE" is changed by mistake, the server will not start.

Restart the server and the settings will take effect.

1-4. Additional Operational Users

It is dangerous to work with a root user logged in, so add a user to log in. In a subsequent step, disable the root user login.

The risk of logging in as the root user is that you can do anything you want. The risk of doing anything is that you could accidentally change or delete important changes related to the OS. If you are using the server for personal hobby or study, and you do not make such ordinary mistakes, I personally do not see any problem with logging in as the root user. I think the number one reason for not letting the root user log in is separation of privileges. The application development team uses a user who can only access the directory for application development. The batch development team uses a user who can only access the batch development directory. It is better to divide users so that necessary teams can access necessary directories.

Below are the steps for adding a user.

[root@hostname ~]# useradd xxxxxx
[root@hostname ~]# passwd xxxxxx

※xxxxxxxx is the user name to be added. Set any password.

1-5. Change root user password

If you are not the root user, switch to the root user with su - and execute the following command

[username@hostname ~]$ su -
[root@hostname ~]# passwd

※Set a password of your choice.

Never quit using the initial password. The password "root" is the worst. Passwords such as "password" and "1234" are also quite dangerous. A minimum of 8 digits, including alphanumeric symbols, is good.

This password setting is quite important for security measures and should be set with the utmost care. Changing the root user password is fairly basic, but be aware that we have heard many stories of security incidents caused by this. Don't assume that no one will attack your server because it is small. The attacker accesses a random server with the username "root" and password "root".

1-6. Configuration to prohibit login by users other than the operational user (prohibit login by root user and other users)

Restrict who can log in. In particular, root users should not be allowed to log in, as root logging in equals disabling all security measures.

The following is the procedure for disabling root user login and adding users who can log in. (It is possible to switch to the root user with "su-" just to disable login.)

[username@hostname ~]$ su -
[root@hostname ~]# vi /etc/ssh/sshd_config


sshd_config【Before change】


#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10


sshd_config【After change】


#LoginGraceTime 2m
PermitRootLogin no
AllowUsers xxxxxx
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

※xxxxxxxx is the operational user name you just added


Note that if you use the wrong AllowUsers name, no one will be able to log in, so be sure to check the user names carefully.

Check the syntax and restart sshd.

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

Once you have logged out and confirmed that you cannot log in as root and that you can log in as the added operational user, you are done.


1-7. Time synchronization

Check to see if the time is synchronized. Sometimes, the server time is not synchronized, so the log output date and time is different from the expected time, and it takes a long time to analyze the problem.

Check the startup of the time synchronization process (chronyd). Check the time synchronization status: CentOS7 uses "chronyd", but earlier versions use "ntpd", so be careful if you are using CentOS6 or earlier.

[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

It is OK if "Local time" matches the current time, "NTP enabled" is yes, and "NTP synchronized" is yes.

1-8. key authentication setup

For the operational users you just added, allow them to log in only with key authentication.

Simply disabling password authentication will increase security considerably. In the case of password authentication, if you use a complex password, you will not be logged in, but the possibility is not zero. However, in the case of key authentication, if you do not have the key, you cannot log in, so as long as you manage your key properly, you will not be logged in.

Below is the procedure for setting up key authentication.

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

※xxxxxxxx is the added operational user name

※After executing the command "ssh-keygen -t rsa -b 2048", you will be prompted for a response, but press "Enter" with all default values. No password is also set. (If you enter a password, it will be key authentication + password authentication, which provides even more security, but for this example, no password will be used.)


Then confirm that the key has been created.

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

※xxxxxxxx is the added operational user name

Confirm that the private key "id_rsa" and public key "id_rsa.pub" are stored.

Rename the public key and move the directory to download the private key.

[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

※xxxxxxxx is the added operational user name

Delete the private key (id_rsa) from the server after moving it locally.

Move /home/xxxxxxxx/id_rsa to local. (Move it by WinSCP, etc.)

After moving, execute the delete command.

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

※xxxxxxxx is the user name added in ③.

This completes the key authentication setup. Check that you can log in with the private key you created.

Once you have confirmed that you can log in, the last step is to change the settings so that you cannot log in using password authentication.

[username@hostname ~]$ su -
[root@hostname ~]# vi /etc/ssh/sshd_config


sshd_config【Before change】


PasswordAuthentication yes


sshd_config【After change】


PasswordAuthentication no

Check the syntax and restart sshd.

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

This completes the key authentication setup.


2. summary

We have described the initial configuration required when CentOS is installed.

The information in this article is the minimum that should be implemented when installing CentOS, so if you feel that there is something missing after reading this article, please try to set it up.

Thank you for taking the time to read this to the end.




■INFORMATION

Please click here to go to the top page of INFORMATION.


■PROFILE

Please click here to view the profile.


■For inquiries, please contact

For inquiries about the article, please contact us here.