-4

I have a script for getting Clamav updates from another server which I run as a Cron job as root. Also, I have root login disabled for /sbin/nologin. But this has serious implications on the system as it stops the sshd service, deletes the /bin/bash login for my user. These are the steps I took to reach this state:-

  1. Create any executable script int /root/. In my case it was a script to update Clamav.
  2. Make sure root login is disabled by changing root user's shell from /bin/bash to /sbin/nologin.
  3. Manually add an entry in /etc/crontab to run this script every minute with user as root.
  4. Now restart ssh service and try sshing in after 5 mins.

Following my /etc/crontab entry.

* *  * * * root    /root/clamu.sh >/dev/null 2>&1

Following is the clamu.sh script

#this script need to run by root user

#create a folder temp
mkdir /temp

#go to the temp dir
cd /temp

#clean this folder
rm -f *

#Copying the files from server to temp dir

scp -P 2277 someuser@192.168.100.46:/var/lib/clamav/daily.* .
scp -P 2277 someuser@192.168.100.46:/var/lib/clamav/bytecode.* .

#Updating the files to actual location

rm -f /var/lib/clamav/daily.*
cp -u daily.* /var/lib/clamav/
cp -u bytecode.* /var/lib/clamav/

#do scanning & save report

cd /
clamscan --recursive=yes >> /var/log/clamav/clamd.log

# Clean the /temp folder
cd /temp
rm -f *

I am using CentOS 7 x64. Although I don't think it is related to the distribution but is a common problem.

I know the problem is caused by running this script as root in cron somehow. But why is it causing ssh failures and kernel panics is what I want to know, just to learn what is going on. I am an amateur Linux user and would certainly appreciate some explanation. Thanks.

EDIT Hi, since I have not shown any research efforts that is because this was not the initial problem. This occurred in one of my remote VMs, and I had no logs to debug it. After figuring out how to access the logs, I did try to fix the problem and I was able to fix it by using different user in the crontab entry. But the question still remains, How can a cron job cause so much destruction. That is what I need an answer to, or even a direction so that I could find out.

  • 2
    In addition to the answers below, you really should use some error handling in your script. As it is, you don't check that you're in the right folder before deleting stuff, and you are deleting log files without checking that the scp went through. – Jenny D May 6 '16 at 8:40
  • 1
    rachelbythebay.com/w/2016/03/11/bash explains error handling quite well. It should be required reading for new shell programmers. – Jenny D May 6 '16 at 8:43
  • give us the whole script. explain what effort have you made to understand or resolve the problem. – Mongrel May 6 '16 at 8:46
  • I have looked through all the log files. At first my machine just dissallowed login for my user. But later it just stopped ssh. I was able to pinpoint it using /var/log/secure logs. – xcodex May 6 '16 at 9:30
  • @JennyD Thank you for the link. I would definitely try to improve error handling in my future scripts. – xcodex May 6 '16 at 9:31
2

Does /temp really exist (didn't you mean /tmp)?

If it doesn't then your script tries to cd to /temp, fails, and then all the commands run in the starting directory.

The last two commands are particularly dangerous because you cd to /, then cd to /temp (which may not exist) and then rm everything (which could well be the root filesystem).

You should specify full paths for your rm comamnds.

I don't know why the result you're seeing occurs, but that script is dangerous enough that I'd start by fixing it and see if that resolves the issue.

  • Thanks for pointing that out. It was a silly mistake. I create the folder /temp before changing into it. I have just edited the script to reflect that. – xcodex May 6 '16 at 9:24
  • Given you didn't paste the original script, it's hard to know what other information you've not given us. – EightBitTony May 6 '16 at 10:56
  • This is the complete script. This script was written by someone else for creating a Clanav Client getting virus definition files from another Clamav instance. I made a big mistake of copying it since it I had an understanding of what it was doing and also it was working fine at the machine I copied from. – xcodex May 6 '16 at 12:19
1

In my opinion you should never ever disable the root user entirely. If you do not want to be able to login as root using ssh you should set the directive PermitRootLogin no in /etc/ssh/sshd_config.

For other applications there are mostly equivalent settings which can be made.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.