SSH Access Limiting By IP Address During Certain Times

jordo2323 · 11-20-2008, 10:38 AM

Please forgive my ignorance on certain topics including IPTABLES and such....

I have a client who runs a Red Hat server which runs their billing application. Once a day a user (accountant) needs to perform maintenance on this software by connecting to the box via SSH.

The other users around the company also use SSH to connect to this box. I want to

1. Allow the user to connect via SSH
2. Allow the user to kill SSH connections to the other IP addresses - this user will be connecting internally from either 192.168.0.61 or 192.168.0.109 so I want to retain these IP's so he doesn't cut himself off
3. Allow the user to perform the maintenance on the billing application
4. Allow the user to open the connections back up when finished so the clients can connect

Note: This user isn't the most savy user out there, but can trigger bash scripts if needed.

Any ideas on this scenario would be completely appreciated. Please reply to the thread if you have any questions.

I have heard that this can be accomplished via IP tables but I run into issue as the user would have to perform these actions. I am also not the best with IPTABLES but can learn quickly.

Thanks.

TB0ne · 11-20-2008, 10:50 AM

Quote:

Originally Posted by jordo2323

Please forgive my ignorance on certain topics including IPTABLES and such....

I have a client who runs a Red Hat server which runs their billing application. Once a day a user (accountant) needs to perform maintenance on this software by connecting to the box via SSH.

The other users around the company also use SSH to connect to this box. I want to

1. Allow the user to connect via SSH
2. Allow the user to kill SSH connections to the other IP addresses - this user will be connecting internally from either 192.168.0.61 or 192.168.0.109 so I want to retain these IP's so he doesn't cut himself off
3. Allow the user to perform the maintenance on the billing application
4. Allow the user to open the connections back up when finished so the clients can connect

Note: This user isn't the most savy user out there, but can trigger bash scripts if needed.

Any ideas on this scenario would be completely appreciated. Please reply to the thread if you have any questions.

I have heard that this can be accomplished via IP tables but I run into issue as the user would have to perform these actions. I am also not the best with IPTABLES but can learn quickly.

Thanks.

May be overkill for this application. Check out the allow_users/deny_users directives for the sshd_config file. You can have rules set up to allow/deny based on IP address(es)/ranges, and just un-comment those rules when needed. Bounce the ssh service, and the rules are in place.

You can also use hosts.deny, with the sshd protocol, to block ranges from coming in, but that would need root access to edit a file.

If you don't have the most savvy user, you can write a bash script to have a different sshd_config file, with the appropriate rules in place. Running the script as SUDO will let the files be moved/copied, and the service be bounced.

mrclisdue · 11-20-2008, 11:06 AM

I'm thinking out loud here, but there would be a way to accomplish this without using iptables.

Create an sshd_config file with AllowUsers <accountant's user name>, call it whatever ssh_config_A

Have the accountant ssh to the machine and run a script which would kill the existing sshd instance, and restart sshd with the ssh_config_A configuration file. Stopping sshd would boot everyone who's connected, including him, so he would have to reconnect. When he's done, he can run another script which would restart the normal sshd.

something along the lines of:

Code:

#!/bin/bash
#accountant maintenance
sudo /etc/rc.d/rc.sshd stop 
sudo /usr/sbin/sshd -f /etc/ssh/sshd_config_A

When he's done:

Code:

#!/bin/bash
#back to normal
sudo killall sshd
sudo /etc/rc.d/rc.sshd start

I haven't tried this myself to ensure it works (I'm about to....)

Edit: I see another poster has offered up some similar ideas...

hth,

mrclisdue · 11-20-2008, 11:43 AM

Okay, neither of those scripts ^^^^^^^ will work (I had *suspected* such), for the simple reason that once sshd is killed outright, the user who invoked the script is disconnected, and the script stops running. The problem with simply issuing a restart command to rc.sshd is that it won't boot existing users, even if the config file has changed.

I considered starting a second sshd process with the altered sshd_config, but issuing the command 'sudo /etc/rc.d/sshd stop' kills both processes.

The second script wouldn't even be necessary, as issuing the command 'sudo /etc/rc.d/rc.sshd restart' would do the trick.

At least you've managed to get my rusty gears churning - I'll stay on it....

Autocross.US · 11-20-2008, 12:24 PM

On a Redhat server, stopping the sshd process will NOT terminate existing sshd connections.

You will have to kill the other existing sshd PIDs individually.

Here's something i tested to do this:

Code:

#! /bin/bash

### Run this option after finished
start() {
   /sbin/service sshd start
}

### Run this option before starting
stop() {
   # Stop new ssh connections
   /sbin/service sshd stop

   # Determine my IP address or hostname
   MY_IP=$(who am i | awk '{print $NF}' | tr -d ')''(' )

   # Kill all sshd processes except for mine
   kill `netstat -tuap|grep sshd|egrep -v "grep|$MY_IP"|awk '{print $7}'|awk -F/ '{print $1}'`
}


# See how we were called.
case "$1" in
    start) start ;;
     stop) stop ;;
        *) echo $"Usage: $0 {start|stop)" ;;
esac

Give the user sudo access to this script. Run as follows:

scriptname stop (logoff all other users)
scriptname start (start sshd)

mrclisdue · 11-20-2008, 01:23 PM

Quote:

Originally Posted by Autocross.US

On a Redhat server, stopping the sshd process will NOT terminate existing sshd connections.

You will have to kill the existing sshd PIDs individually.

Seems strange to me - if 200 users are connected to your server, as admin, you couldn't simply stop the ssh daemon, you'd have to kill 200 pids. But there must be reasons, so it is what it is.

Anyway, on slackware, telling the daemon to stop boots everyone.

As to the op's original query, picking up on my original reply, your accountant can ssh in, boot everyone, do his maintenance, exit and restore original accessibility thusly:

Go ahead and create a script that stops the daemon and restarts it with a new config that allows only him to reconnect.

When he's done, the daemon can then be restarted with it's normal config.

So, the script that changes config resides on the remote machine, and it can be similar to the script in my first post. Let's call it 'ssh_new':

Code:

#!/bin/bash
#reset sshd config
sudo /etc/rc.d/rc.sshd stop 
sudo /usr/sbin/sshd -f /etc/ssh/sshd_config_A

Now, on your accountant's machine, create a script which will ssh to the remote, stop the daemon, start the daemon with the new config, allow the accountant to do his thing, then restart the daemon when he logs off.

Code:

#!/bin/bash
#accountant maintenance
ssh <remote_machine> ssh_new
#next command gives remote machine time to reset with new config
sleep 10
#now the accountant will ssh to remote
ssh <remote_machine>
#when the accountant is done, he exits, and remote machine needs to return to original config
ssh <remote_machine> sudo /etc/rc.d/rc.sshd restart

I've tested it, and it works on Slackware 12.1

Obviously, the user can invoke the 'sudo /etc/rc.d/rc.sshd restart' whilst still connected, but by putting it in the script it saves him this step, and resets the config in case he forgets.

cheers,

Autocross.US · 11-20-2008, 01:38 PM

Quote:

Originally Posted by mrclisdue

Seems strange to me - if 200 users are connected to your server, as admin, you couldn't simply stop the ssh daemon, you'd have to kill 200 pids. But there must be reasons, so it is what it is.

Anyway, on slackware, telling the daemon to stop boots everyone.

Yeah, most Unix platforms i've worked on are the same way. To kill all sshd processes (including your own) in Red Hat, run 'pkill sshd'.

mrclisdue · 11-20-2008, 02:01 PM

Thank you for the info. I often get caught *assuming* that the main differences in distros are cosmetic, rather than functional.

cheers,