Category Archives: Unix

Server Management for Middle Schoolers Part 3: Ease of Use

I may be crazy, but I know there are some Middle Schoolers who can run a server. So I’m teaching them headless shell management and scripting, all so they can play Minecraft (the carrot, in this case.) They are learning surprisingly well, but then, so am I. I’ve never had to create a fully group setting on Linux, and didn’t anticipate all the issues I’d run in to. Wanting to have 17 kids in an ssh group, with access to a games folder that consistently outputs files they can all use, and allows them to run an instance of Minecraft they can all access… It is a lot to figure out. This series is going to cover the settings I came up with.

Bash Script Startup and Ease of Use

The biggest problem that I knew I was going to have dealt with the running of scripts. Most of these kids had never been exposed to a Linux environment, much less actually dealt with a command line. We were secure shelling in, so there wasn’t a GUI for them to learn and play with, but they had dealt with all of that issue like a champ. Some of them were getting taxed on the amount of commands they had to use, so I didn’t want to burn them out.

The tmux script that I was working with basically did three things. It set up the temp folder for the tmux instance, made sure that the group managed it, and then dropped in to the instance to operate it. The problem was the amount of typing each of these commands took. Individually, they look like this:

tmux -S /tmp/tmuxDirectory new-session -d -s Minecraft
chgrp MyGroupName /tmp/tmuxDirectory
tmux -S /tmp/tmuxDirectory attach-session -t Minecraft

which is a lot to remember for newly minted shell users. So I opted for scripts. Fortunately, these things are easy to write, and simple to use when you teach them.

Taking those commands and working them into a new serverstart.sh file looks nearly identical. I just commented what was happening with each line before I wrote it, for clarity, and threw a hash-bang /bin/bash on the top. Then I noticed I might want a little more abstraction, so I altered the file to pull the directory, the session name, and the group (incase it needed to change for some reason) out of this file. They are represented here by the $CONSTANTS

#! /bin/bash

# Import server configuration
source config.sh

# Abstract tmux code start $CONSTANTS in config.sh
tmux -S $DIR new-session -d -s $SESSION

# Change the group setting of the $DIR
chgrp $GROUP $DIR

# Start the server
echo Starting $SESSION Server Now

And at this point using the tmux ability to pass along keys is important.

tmux -S $DIR send-keys “java -Xmx2048M -Xms1024M -jar minecraft.jar nogui” C-m

obviously, even this code could (and should) be abstracted a little bit.

With all of this set, the only command the kids will need to remember to start the server is the executable ‘./startserver.sh’. So make it executable.

chmod +x startserver.sh

Other Useful Bash Scripts

Besides starting the server, there may be a time your team will need to manage the server, or stop it. Here are those scripts

serveraccess.sh

#! /bin/bash

# load the configuration
source config.sh

# Attach to shared server instance
tmux -S $DIR attach-session -t $SESSION

serverstop.sh

#! /bin/bash

# Load the configuration
source config.sh

# Stop the server
echo Stopping $SESSION Server
tmux -S $DIR send-keys “/stop” C-m

# Wait 5, then kill the Session folder
sleep 5
tmux -S $DIR kill-session -t $SESSION

You could, of course, be much nicer in this script and give players time to log out, but the flavor of that is up to you.

Wrap Up

I’ll be writing an update soon to tell about how these lessons have been received, how they are progressing, and some interesting difficulties with this situation that have arisen.

 

Server Management for Middle Schoolers Part 2: The Group Folder

I may be crazy, but I know there are some Middle Schoolers who can run a server. So I’m teaching them headless shell management and scripting, all so they can play Minecraft (the carrot, in this case.) They are learning surprisingly well, but then, so am I. I’ve never had to create a fully group setting on Linux, and didn’t anticipate all the issues I’d run in to. Wanting to have 17 kids in an ssh group, with access to a games folder that consistently outputs files they can all use, and allows them to run an instance of Minecraft they can all access… It is a lot to figure out. This series is going to cover the settings I came up with.

Setting up the Group Folder

The plan here, was to have all the group with ssh access have a united home folder that we could work from for our game instances. The top level folder, and everything underneath it, would need to be accessible to the group, not just to the creator, so I played around with some settings, and came up with a solution that worked.

Setting the Permissions right

The first thing I did was create a ‘games’ folder in the ‘home’ directory. I knew I wanted this folder to be a group folder, so I ran the chgrp command for it:

$ chgrp myGroupName games/

Then, when you run the $ ls -la, you’ll notice that the creator is still listed as your user, but the group is switched to myGroupName. That way everyone in the group will have access to that file. So I copied the Minecraftserver.jar in there and thought that would be it. Since we were planning multiple instances of Minecraft, I also added a folder for this first, vanilla version. The tree looks something like this:

/home/
|-> games/
|-> vanilla_minecraft/
|-> minecraftserver.jar

When I ran the minecraftserver.jar so I could edit the EULA, I noticed a problem. The file (even though I had changed its permissions as well) ran as if all the files were being produced by, and for, just my user. This was a problem. I could go back and change it often enough, but that wouldn’t work for times where I wanted the kids to handle things. I needed the new files to have the same group setting.

Setting the GID on the folder

So I emptied out the ‘vanilla_minecraft’ folder and got ready to try again. I made sure all the files had the right permissions, then did one more step on the ‘games’ folder. I set the GID for the folder. This is a handy trick, because it allows all the files created within the directory to inherit that same level of permission for the group use. Here’s the command:

$ chmod g+s /home/games

to make it apply to all subdirectories as well, simply add the -r flag. This way, whenever any group user runs an executable, any files created will be created with the group permissions of the top folder.

Security Note

This can be a dangerous procedure if you aren’t careful where you apply this type of thinking. It is useful as a shorthand to give a group permission to run files, but you have to be careful what type of files are put in there, and what other things those files touch. I tested it out a couple of times, and was able to create some files in other directories that I didn’t have access to normally because of the group setting. So be careful here, your group needs to know that this is a potential danger on a server, but it’s probably the best balance of security and ease that I was able to strike.

Actually Starting the Server

At this point, I created an open port for the minecraft server, and then ran the server to get the files setup, but that created other problems. I used screen to start the instance the first time, but then realized that we were going to have a problem when the kids tried to attach to that screen, that they weren’t going to be able to. After a bit of searching, I found out that screen wasn’t going to work for what I needed, so I switched over to tmux and found some nifty hackarounds that would work. Namely, creating a specific /tmp folder for the tmux instance and setting its group permissions. This solution, however, was going to be a headache for the kids (it already was taxing me to write out all those commands every time) so I knew what had to be done next. Time for some Bash scripts!

Server Management for Middle Schoolers Part 1: sshd_config

I may be crazy, but I know there are some Middle Schoolers who can run a server. So I’m teaching them headless shell management and scripting, all so they can play Minecraft (the carrot, in this case.) They are learning surprisingly well, but then, so am I. I’ve never had to create a fully group setting on Linux, and didn’t anticipate all the issues I’d run in to. Wanting to have 17 kids in an ssh group, with access to a games folder that consistently outputs files they can all use, and allows them to run an instance of Minecraft they can all access… It is a lot to figure out. This series is going to cover the settings I came up with.

Setting up a good sshd_config

There are some really great settings in the sshd_config script (/etc/ssh/sshd_config) that shouldn’t be overlooked. Options like changing the default port, assigning an approved group, and, optimally, using RSA keys are a must here, at least eventually.

Changing the Default Port

Because I need this server to be secure, it is attached to our school network after all, and because I want a group of lively administrators to have a sandbox to work on, I need a way to lock out unwanted access. The first step, which a student in the group duly noted, is to change the port number away from the default 22. That’s a simple fix, just look for the line and change it:

 # What ports, IPs, and protocols we listen for
Port 22

You can’t pick arbitrarily, but you can assume that most numbers below 1000 will be useful here. Settle on a port that isn’t used by another popular program as a default and you should be okay on traffic issues. Just as a point of reference, I got 2200 hits against Port 22 in the weekend before I could get our network admin to change the routing table to our new Port. They ranged from attempts to login using every possible username from ‘root’ to ‘techhelp’, to attempting to negotiate RSA keys. The saving grace from these attacks was the next step I took.

Setting Up an SSH Group

I’d prefer to use RSA keys for login, but haven’t had a chance to fully explain that process to the students yet, so we’re using passwords for now. Getting away from port 22, which is often attacked by bots as a pre-trial for an actual attack, was the first step. The next step is a bit of an extra measure. I knew I was going to need a group for these kids with special privileges, but I certainly wasn’t about to give them su. Inside the sshd_config there’s a setting to grant ssh privileges to a group of users, you can change it like this:

# Allow only certain UserGroups to access the ssh
AllowGroups myGroupName

This way, all of the random tries for usernames (even for root) will result in a failure, but it won’t tell the attempter why. This also accounts for attempts to attach with an RSA key, so bonus there. Only users in this group will be allowed to remote shell, however, so be sure to add yourself to the group. I speak from experience here.

Creating a Banner for Good Measure

It’s a good idea to also set up a banner for good measure. There should be a commented line in the sshd_config file that looks a bit like this one:

Banner /etc/issue.net

That gets printed out on an attempted login, say someone guesses a name that is in the userGroup approved to remote ssh. This may happen, and this file will, at the very least, show that you are paying attention to details. Most hackers won’t actually care, honestly, but amateurs might get a moment of pause. You can make yours funny for the added measure of giving a potential hacker a chuckle, may save you some time down the line. Currently, mine’s a mix of legal disclaimer, and boring threat. I’m working on something snappy.

Conclusions for SSH Access

This was a good lesson in the config files for ssh for me. I knew about some options, but not others. I think the real gem here is the setup of an allowed group. Keeping in mind that each user typically has their own group in a UNIX setup is a valuable thought for a broader sense of server management, and the idea that you could set multiple allowed groups through this setting is also quite useful. Next time I’ll talk about the Group ID and setting the group bit on a folder so that the whole group can access files and run services that are interoperable.