4

I would like to disable the ssh server for certain times of the day. I would like to do this because I recently experienced a brute force compromise via ssh. Can crontab be used to enable/disable SSH?

If not, is there another way to disable ssh at certain times of the day?

Improve this question
6
  • Do you mean you want to control the ssh server? Or did you really mean control of a client?
    – Chris Davies
    Oct 7, 2015 at 17:58
  • What flavor of Unix are you wanting to do this on?
    – Don Simon
    Oct 7, 2015 at 17:59
  • @DonSimon RHEL - But, I also have some Ubuntu servers as well.
    – Roy Hinkley
    Oct 7, 2015 at 18:01
  • @roaima I want to prevent bots from constantly attacking. If SSH is only available at certain times in the day, I can minimize the attack vector.
    – Roy Hinkley
    Oct 7, 2015 at 18:02
  • 5
    See the below answer, but the real recommendation would be to set your sshd to only allow public-key access at a bare minimum.
    – Don Simon
    Oct 7, 2015 at 18:10

5 Answers 5

Reset to default
16

Sure, just run whatever init scripts there are to stop and start ssh daemon (e.g. /etc/init.d/ssh stop and /etc/init.d/ssh start) at appropriate times.

However, I'd suggest looking into fail2ban, portknocking, disabling password authentication and using only ssh keys, and the most secure way, two factor authentication with one time passwords.

Improve this answer
6
  • 1
    Does this work with systemd, as used on RHEL, too?
    – Chris Davies
    Oct 7, 2015 at 20:02
  • @roaima No, use systemctl [start|stop] sshd instead
    – nanny
    Oct 7, 2015 at 21:01
  • 1
    @nanny that's what I thought. So this answer won't work for the situation the OP is in?
    – Chris Davies
    Oct 7, 2015 at 21:55
  • @roaima RHEL? You can easily do service sshd restart
    – Hanky Panky
    Oct 8, 2015 at 6:08
  • @HankyPanky good to know, but that's not what this answer offers, either. (Perhaps RadovanGarabik will update their answer to handle the more general case.)
    – Chris Davies
    Oct 8, 2015 at 6:54
6

Instead of shutting down the SSH server during certain hours, consider using the pam_time module instead to deny authentication during certain times of the week. It's less of a hack, doesn't depend on cron, and also gives you more flexibility to define your authentication ruleset.

  • Set UsePAM yes in your sshd_config
  • Edit /etc/pam.d/sshd to insert the pam_time module
  • Write your time-restriction rules in /etc/security/time.conf.
Improve this answer
4

There are a number of options available to you

  1. You can use cron to switch the ssh server on and off
  2. You can use iptables to block and unblock the ssh port
  3. You can sidestep all of this by running ssh on different port
  4. You can implement port knocking
  5. You can disable external access to ssh entirely and mandate use of a VPN

I'm sure other solutions are available, but I've stopped at five.

Improve this answer
1
  • 1
    +1 for #3. Never run ssh on port 22, always change it. That will stop almost 100% of automated attacks.
    – Arielle Lewis
    Oct 8, 2015 at 13:12
2

Look at the "fail2ban" log monitoring dæmon. It will use iptables to block access to your sshd from a specific IP address. if there are more than 5 incorrect log-ins within a few minutes. However, it is IPv4 only.

Also, disable root logins; always use a bounce account.

Improve this answer
1
  • If it's IPv4 only I'd better tell it to stop working for my IPv6 networking layer. (fail2ban can be used to run pretty much any command when a pattern is matches in a log file.)
    – Chris Davies
    Oct 7, 2015 at 21:54
2

There is the time module for iptables:

iptables ... -m time --timestart TIME --timestop TIME --days DAYS -j ACTION

Use -p tcp -j REJECT --reject-with tcp-rst to pretend the port is closed (the default action for REJECT is an ICMP packet).

I'd also add another rule in front, allowing ESTABLISHED connections through if I wanted open connections to remain working.

Compared to solutions using scripting to perform certain actions at certain times it has the great advantage that this is static configuration, and there are unlikely to be any failure modes that would e.g. permanently block access.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .