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
- basic setting
- 1-1. Check OS
- 1-2. Tool Installation
- 1-3. Disabling selinux
- 1-4. Additional Operational Users
- 1-5. Change root user password
- 1-6. Configuration to prohibit login by users other than the operational user (prohibit login by root user and other users)
- 1-7. Time synchronization
- 1-8. key authentication setup
- 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
SELINUX=enforcing
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
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#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
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
PasswordAuthentication yes
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