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
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
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:
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.