Many thanks Blackhole54 !!!!! I can't wait to test the script tomorrow at school, on my new server setup! I'll get back to you tomorrow with the results. Love the way you thought it through,... the logic!

I thought you might have a true appreciation for my classroom environment and the "education server project" I'm working on.
SETTING: 25 new Dells(replacing old Dells as of 2 weeks ago) w/17in flat panels. The computers are password bios protected and have the hard drive disabled(MS XP) and the boot order is set to CD/DVD-rom, first. The rest of the school is on MS XP. My students boot a Linux Live CD of my re-writing. NO-games, etc. just business. I keep control. Students boot this CD and open a shell. They ssh(-X) onto my local server. I have 2 servers, one active/live now and the other is testing the new improved "project". The project is Ubuntu 8.0.4.2 LTS. I have "lshell" in place. I got the author to make some mods and it works great! Students are limited by the commands I give them and it has a list of forbidden commands. The forbidden commands are like: `, su, sudo, and etc. I can set the number of attempts of forbidden commands to, usually 3, then the user's session is killed and I get a log of these users forbidden commands. The current accepted list of commands are: --help, ls, pwd, cd, mkdir, rm, cp, mv, vim, ./ , g++, java, javac, firefox, and more can be added. Firefox, on the server, is a rewrite, securing it down.

Students log in, open vim and code, compile, and execute C++ or Java. I have 3 C++ classes, 2 Java-I classes, and 1 Java-II class. Natural attrition I suppose. Lessons, APIs, and other important info is available through Firefox on the local IP address of the server. Firefox openly defaults there and students cannot access the Internet(having 'toasted' the proxy settings in the FF conf). I cannot let THESE students on the Internet on my watch. Too many legal issues "in there" for a public educator.

This whole server project is based on utilization of as many open source "pieces" as possible. The goal is to provide the AP and IB Computer Science community an educational environment that is very close to "real world" working environment. Perhaps provide a free and complete server setup for the world's prospective coders to learn their skills sets. The "ReadMe" installation files, etc. are written in such a way that newbies to linux can follow and set their server up with some ease and confidence. I'd like to add you in the credits with the others that have contributed to this project.

Once again, many thanks!!!

Hello to all and many thanks again to Blackhole54. I ran the script on both my old/current setup(Mepis 7.0) and the output is called Output1 below. I ran it on this box just out of curiosity.

The new server version, one I'm most interest in, is the Ubuntu 8.04.2 LTS. It's output is namely called, Output2 below. There are 3 different users on the same IP address.

Both outputs are basically the same. NO user got dropped!

Output1 -> under "debug=true"

jim@server:~/Documents$ ./blackhole54
Table of (in order) IP address, username, PID

1022 13149
1027 11090
1028 13223
1031 11285
1034 13319
1038 13104
1041 13162
1042 13380
1043 13074
1046 13310
1049 13037
daydak 10588
egantim 13128
gemajos 13457
haganjoh 13442
jooyalay 13375
sshd 13435
sshd 13513
willtyl 10495

egrep filter: ""

If $debug had not been true, the following processes
would have been killed:

UID PID PPID C STIME TTY TIME CMD
jim@server:~/Documents$
jim@server:~/Documents$

===============================================================

Output1 -> under "debug=false"

jim@server:~/Documents$ ./blackhole54
jim@server:~/Documents$

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
End of #1 and start of #2
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Output2 -> under "debug=true"

root@jim-testbox:/home/jim/tmp# ./blackhole54
Table of (in order) IP address, username, PID

192.168.2.7 buddy 7030
192.168.2.7 jim 6969
192.168.2.7 testuser 6999

egrep filter: "^[^ ]* *6969 |^[^ ]* *7030 |^[^ ]* *6999"

If $debug had not been true, the following processes
would have been killed:

UID PID PPID C STIME TTY TIME CMD
jim 6969 6964 0 21:55 ? 00:00:00 sshd: jim@pts/1
testuser 6999 6994 0 21:56 ? 00:00:00 sshd: testuser@pts/2
buddy 7030 7025 0 21:56 ? 00:00:00 sshd: buddy@pts/3
root@jim-testbox:/home/jim/tmp#
root@jim-testbox:/home/jim/tmp#

===============================================================

Output2 -> under "debug=false"

root@jim-testbox:/home/jim/tmp# ./blackhole54
root@jim-testbox:/home/jim/tmp#

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It might be noted that in both cases, "debug=false" DID NOT kill any term session of the violators! All users were still actively logged on. Why is that?

Also, for what its worth, linux commands 'w' and 'who' and their options provide interesting data.

I hope this feedback helps "tweak" the code!

Thanks again!

Hi Tuxhats,

First, the script, as posted, should produce no output with debug=false unless there is an error message (which there shouldn't be -- one hopes.)

For the record, to the extent I tested the script, it was on a machine running Ubuntu 6.10.

With debug=true, I don't understand Output1 at all. It looks like some or all of the usernames got mangled and that none of the PIDs got matched to an entry in the output of netstat. The script does depend on the format of the output from ps and netstat; if the format is different, then the script is not going to be picking up the proper info. (The info might be able to be dug out of /proc such that format of commands' output would not matter, but that would definitely be more work.) With the info presented from the debug run, I would not expect anything to be killed even if there were no other problems. If you want to look into the misbehavior on the Mepis system, post the output of the debug run along with the output of

definitely with the netstat command running as root. Also, I think it would be a good idea if you try to understand this script. I don't expect you to become either a bash expert or a regular expression (for the grep and sed commands) expert overnight, but with a little effort and consulting the bash man page I would think you could largely figure out the script. Hmmm. After reviewing this, I am wondering if you were running as root when you did Output1. The prompt looks like a regular user prompt to me. That would account for not picking up the IP addresses from netstat. (Although I've always seen netstat print out a warning message when a non-root user uses the -p option.) But I am still baffled about usernames that are numbers and user "sshd". (If there actually is a user called sshd you might need to modify the script to exclude it from consideration, just as root was excluded.)

The debug Output2 is what I would expect. W/o debug, I would expect it to kill processes 6969, 6999, and 7030, which I would expect to kill everything else associated with those logins. I am not sure why this is not happening. I didn't bother testing with debug off, because I was testing on a headless machine where I didn't *want* to be killing processes! When I get some time (probably not tonight) I can modify the script to except the things I don't want to kill and try to figure out what is going on. You might want to try (temporarilly, for debugging) adding the highlighted line as shown in the following script fragment (and running with debug=false):

The set -x statement will cause the script to start printing out commands as they are executed so you can see if the expected kill commands are actually executing and with what arguments. You can also try manually killing the processes the script indicates from debug mode and see if that produces the expected result. (And use ps to verify the processes were actually killed.) FYI, after xtrace is turned on with a set -x command, it can be turned off with set +x.

Also, you might want to look at the comment about "code tags" in my signature so that computer output you post looks like it did on the screen.

OK. I got a chance to test the script w/o debug. The test machine was starting from a fresh boot so I didn't have to worry about killing processes I didn't want to. So I ran the script unmodified. It behaved as I expected (results below) so I don't know why you are having problems killing the processes. Again, my test machine is running pretty much a stock Ubuntu 6.10. The only thing I am doing that I am aware is substantially different from what you are doing is I am logging into bash rather than lshell. While my client machine has ForwardX11 set to yes, I didn't actually use that capability in this test.

I suggest you run the script with debug and then (as root) try manually killing te indicated processes with kill. Something like the following. Make sure you substitute in the new PIDs:

If the processes don't die or if their death doesn't produce the expected logoff (!!!) you will have to investigate why.

Obviously, the pressing issue is why the kills aren't working as expected. But be sure to keep in mind that the current version of that script is not guaranteed to (attempt to!) shut down all offending processes if there are more than two normal user logins from a given IP address. (The "oops" documented in the comments.)



TEST RESULTS

From several screen sessions on the client machine I sshed into the test machine once each as root, jim, somebody, and compile. From the root account I ran

both before and after the script. /tmp/junk.real is the script with debug=false. While I didn't time it, the 5 second delay between the kill commands caused the execution time of the script to be noticeable.


Output from root account:

Here are the results for the three normal user accounts. On all of them, the output starts from the client machine, shows the ssh login (all via keys if you are wondering about absense of password prompts) and then shows the results of the script running.

What is missing in this thread, if I read it well enough, is a motivation by the OP for wanting to limit things this way. What I mean is that it wouldn't be the first time somebody tries to solve a problem on different plane (say user behaviour) using technology. I also have my doubts about this script for two reasons: it does not stop people at the door (meaning prevent users from SSH'ing in) plus it tries to do too much on its own (re-inventing the wheel instead of utilising any existing authentication mechanisms). For instance the SSH daemon already logs logins, therefore it should be trivial to have any log-watching application watch the log for logins, dump the username to a logfile and use that in a SSH PAM stack (pam_listfile, sense=deny).

@tuxhats,

Does your server use SELinux?

@unspawn,

I had wondered whether it might make sense to write a PAM module for this. (Or possibly combine ability already in PAM to achieve this goal, although I am not sure that is possible.) Unfortunately my understanding of PAM is not much beyond I know it exists and sort of what it does. I had also considered parsing /var/log/auth.log for this information, but I was suspecting that it was going to be more difficult to get the desired information that way than the way so far pursued on this thread. (Certainly it is not a task that I would be motivated to pursue.) Also, while ssh login info is in auth.log, it looks to me like logout info isn't so info from that log would have to be combined with other sources to find out who is *currently* logged in via ssh. Unless there are sshd options the would cause the missing info to be logged. Perhaps you could give some more guidance on how to go about your plan of attack?

I *had* wondered whether Linux-Security was the appropriate thread for this. This seems more like a policy issue than what I generally think of as security, but maybe I am just being too myopic.

Many, many thanks to Blackhole 54 and others! Blackhole54, I tested the script today at school and found it to run perfectly(on Ubuntu 8.04.2 LTS)!!!!!!! ON Mepis, not so. I don't care about that(Mepis) setup, as I will make the transition to this "new" server as soon as I get the jail environment configured.

Yes, the script must be run as root. sudo will not work. Fantastic!!! Yeehaw!!!! I love it!

It passed all tests today, and the students are aware and on notice. No more cheating.

Just think, they(students) may actually be forced to write all of their own work, in class, on and only on these computers. This, as opposed to students dividing the assignment/work, each building a piece, and then jointly sharing each others work through copy-paste. Let's see; a custom, tightly controlled, Linux live CD for students to boot from, Ubuntu LTS with jailed users on the lshell. A locked-in, rebuild Firefox browser for XForwarding, and a locked down localhost with ALL the development and instructional material they desire. Whoa, I'm happy. Almost there...

I just need to find the right "working" jail for this version of Ubuntu(8.04.2LTS). "lshell" only controls and limits the users commands by design.

Real "jails" are either one of two issues for me. 1) the logged user can't log in, 2) if they can log in, ... they aren't locked in. I must have, or I'm doing something wrong here. I'm wondering about this version of openssh-server. Any thoughts on a simple ssh jail?

Once again,... many thanks!!!

With access restrictions I think it's better to see if there's any off the shelf stuff first. If not for efficiency and compatibility reasons, then from a vulns point of view there'll be a lot of debugging done already...


Maybe I'm overlooking something but with PAM session logout info is written to the logs as well. Since I think it's a nice exercise I'll post an example setup later today for you to shoot at, OK?


Taxonomy-wise access restrictions are Linux Security as well so it definately is appropriate. Given the OP's reply though the problem isn't you but making him understand. The fact the man's a teacher doesn't mean he's right always, heh.

Bingo! The machine I was using as a reference doesn't authenticate SSH with PAM. (PAM was causing a $LANG problem with an older machine on my LAN.)

I still have hopes of sometime figuring out PAM. I've made several passes at it as articles have come my way, but somehow I've never really been able to get my mind around it. (Kind of like the first time I encountered propagation of error. I could plug-n-chug but it wasn't really gelling in my mind. A few years later it was all obvious to me. Unfortunately, unlike then, now my mind is on the downside of that curve! )

@tuxhats,

I am glad the script is working to your satisfaction. It's not clear to me why it wouldn't work under sudo, but that's not how you were planning on using it anyway. Maybe I'll probe that mystery sometime when I have some time on my hands. Good luck ...

I've tried it and it seemed to work fine for me when run with sudo. But I did discover a bug while playing with it:

The line

should be replaced with