First, why?
In small and medium-sized enterprises, different operation and maintenance personnel of the company basically use root account for server login management, lacking the audit system of account authority. If there is no problem, it is good. If there is a problem, it is difficult to find the source.
This article describes how to use compiler bash to enable different clients to log in to the server using root, record their operations, and can be combined. ELK Log Analysis System To collect login operation logs
II. Environment
Server: centos 6.5, Development tools, using key authentication, SElinux closed.
Client: Generate key pairs for login servers (2)
3. Build and deploy (server operation 192.168.30.72)
3.1 Download and compile bash
[root@open1 ~]# wget http://ftp.gnu.org/gnu/bash/bash-4.1.tar.gz[root@open1 ~]# tar xvf bash-4.1.tar.gz [root@open1 ~]# cd bash-4.1
3.2 Modify the config-top.c file first, about 94 lines and 104 lines. Since the comment in C is /**/, don't delete it incorrectly. Amend as follows:
[root@open1 bash-4.1]# vim config-top.c#define SSH_SOURCE_BASHRC#define SYSLOG_HISTORY
3.3 Modify the bashhist.c file so that the commands on the terminal are recorded in the system messages and in the specified format. The obtained variables are passed in. The revised contents are as follows:
[root@open1 bash-4.1]# vim bashhist.c
#... Elimination of some paragraphs
void
bash_syslog_history (line)
const char *line;
{ char trunc[SYSLOG_MAXLEN];
const char *p;
p = getenv("NAME_OF_KEY"); if (strlen(line) < SYSLOG_MAXLEN)
syslog (SYSLOG_FACILITY|SYSLOG_LEVEL, "HISTORY: PID=%d PPID=%d SID=%d User=%s USER=%s CMD=%s", getpid(), getppid(), getsid(getpid()), current_user.user_name, p, line); else
{
strncpy (trunc, line, SYSLOG_MAXLEN);
trunc[SYSLOG_MAXLEN - 1] = ' ';
syslog (SYSLOG_FACILITY|SYSLOG_LEVEL, "HISTORY (TRUNCATED): PID=%d PPID=%d SID=%d User=%s USER=%s CMD=%s", getpid(), getppid(), getsid(getpid()), current_user.user_name, p, trunc);
}
}
3.4 Configure installation path, compile installation, compile to / usr/local / directory.
[root@open1 bash-4.1]# ./configure --prefix=/usr/local/bash_new [root@open1 bash-4.1]# make && make install...if test "bash" = "gettext-tools"; then \ /bin/sh /root/bash-4.1/./support/mkinstalldirs /usr/local/bash_new/share/gettext/po; \ for file in Makefile.in.in remove-potcdate.sin quot.sed boldquot.sed en@quot.header en@boldquot.header insert-header.sin Rules-quot Makevars.template; do \ /usr/bin/install -c -m 644 ./$file \ /usr/local/bash_new/share/gettext/po/$file; \ done; \ for file in Makevars; do \ rm -f /usr/local/bash_new/share/gettext/po/$file; \ done; \ else \ : ; \ fimake[1]: Leaving directory `/root/bash-4.1/po'
After compilation, add the new bash to / etc/shells, and modify the login shell environment of root users to the newly compiled shell. as follows
[root@open1 bash-4.1]# echo "/usr/local/bash_new/bin/bash" >> /etc/shells [root@open1 bash-4.1]# cat /etc/shells /bin/sh/bin/bash /sbin/nologin /bin/dash /usr/local/bash_new/bin/bash
[root@open1 bash-4.1]# vim /etc/passwdroot:x:0:0:root:/root:/usr/local/bash_new/bin/bash
Log off the current root user, check / var/log/messages after re-login, and you can see that the operation commands are recorded as follows
IV. SSH Client Generating Key Section
4.1 Operates on client1 (192.168.30.99), user zhangsan
View Code
- t-encryption algorithm
- C annotation (plus this is also a key point for the final identification of server visitors)
Upload the public key to the. ssh/authorized_keys file on the server. The ssh-copy-id command automatically creates. ssh/authorized_keys files on the server, even if the directory does not exist, and automatically grants 600 privileges.
[root@rsyslog ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.30.72root@192.168.30.72's password:Now try logging into the machine, with "ssh 'root@192.168.30.72'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.
4.3 The same operation on client 2 (192.168.30.71), user lisi
View Code
Upload the public key to the server
[root@swift3 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.30.72The authenticity of host '192.168.30.72 (192.168.30.72)' can't be established.RSA key fingerprint is 8f:a7:1b:8d:e4:92:ad:ae:ea:1b:fb:67:0b:0b:7c:ac. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.30.72' (RSA) to the list of known hosts. root@192.168.30.72's password:Now try logging into the machine, with "ssh 'root@192.168.30.72'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.
4.4 Now go to the server to verify the file.
View Code
Now that the above two clients can log in keyless, go to the server to configure and create scripts.
V. Configuration of Servers
5.1 Create a keys file in the log directory to store the public key when logged in, and then take it out for judgment.
[root@open1 ~]# touch /var/log/keys
Create a detection script, which reads as follows:
View Code
5.2 Configure profile, add a line at the end of the file, as follows:
[root@open1 ~]# echo "test -f /etc/CheckUser.sh && . /etc/CheckUser.sh" >> /etc/profile
Add the following at the end of / etc/bashrc:
[root@open1 ~]# tail -1f /etc/bashrc
test -z "$BASH_EXECUTION_STRING" || { test -f /etc/CheckUser.sh && . /etc/CheckUser.sh; logger -t -bash -s "HISTORY $SSH_CLIENT USER=$NAME_OF_KEY CMD=$BASH_EXECUTION_STRING " >/dev/null 2>&1;}5.3 Modify sshd configuration file, open debug mode, and restart sshd service
[root@open1 ~]# sed -i 's/#LogLevel INFO/LogLevel DEBUG/g' /etc/ssh/sshd_config [root@open1 ~]# service sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ]
VI. Verification
6.1 Log on to client1 and delete a file (zhangsan)
6.2 Log on to client2, delete a file, and execute a restart service command (lisi)
6.3 Go to the server and check the messages log, as follows
From the above picture, we can see that the client of the non-general user can distinguish who operates what and when through the way of public key login.
(Note: In paragraph 4 above, swift1 is the host name of this server. Since I only run the host name command to modify the host name, and did not modify networks, the kernel is still the previous name: swift1.)
VII. End
In this way, the problem that multi-root user login operation can not be audited is greatly solved. In addition, the system log can be forwarded to other servers in combination with log forwarding. Even if the host is black, it can also specifically review the login time and what operations have been done.