2
$\begingroup$

I'm trying to set up a remote cloud Linux server with multiple logins for a class in Linux basics, BASH and C programming. We want our students to be forced to work exclusively in the shell to improve their comfort and skills with terminals - they already have considerable familiarity with IDEs.

To achieve this, I want my students to be able to SSH into a shared server with unique logins. They should then work in their little sandbox and submit their work in specific directories that I will auto-grade from an admin login.

I'm currently trying AWS's basic EC2, but it's unclear if all of the following is possible:

1) Add username/passwords on TOP of a RSA keypairs. It seems clear that I can do unique keypairs OR username/password, but not yet clear if I can do both...

2) How to use just 1 RSA keypair for all student logins, rather than a different keypair for each login (to facilitate quick distribution/set-up, and to control security at-large conveniently)

3) How to let users set their own passwords - ideally initial password is universal, but on day 1 they could personalize.

I'm starting to suspect AWS may not be the best solution for what I'm trying to accomplish. I've looked briefly at CloudSigma's product but am unsure if there is a cloud service that better fits what I'm trying to do.

Has anyone done something similar? I know many universities do essentially this, though usually with their own servers rather than cloud-based ones.

$\endgroup$
  • $\begingroup$ Have you looked at repl.it? There is a way to set up a classroom in there as well and it might tick some of the boxes... $\endgroup$ – srattigan Nov 4 at 16:00
  • $\begingroup$ Security isn't always "easy" or quick. Based on that points 2 and 3 are opposed. I don't know AWS, but I suspect that as long as it accepts SSH with RSA keys that AWS is not the problem. If you can resolve the conflict between #2 and #3, I believe it can be worked out rather simply. The "quick distribution/setup" could be resolved using a BASH script. Happy to help. $\endgroup$ – Gypsy Spellweaver Nov 4 at 17:03
2
$\begingroup$

I believe that using one key for access, even with unique passwords, is inadvisable. Teaching moments aside, each student should have their own, revocable, restrict-able, key pair. However, as I understand the intentions, you should be able to achieve your goal this way.

Short answer

Point 1:

  • Edit the instance's /etc/ssh/sshd_config file and check that these lines are there:
PubkeyAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords no
  • Then add this line to require the use of both a key and password to access the instance
AuthenticationMethods publickey,password

Point 2:

  • Create the one key to rule them all with ssh-keygen or gpg

  • Copy the private key file to each local machine which will access the EC2 instance

  • Create user accounts for each student on the EC2 instance

  • For each user account on the instance add the public key to this file:

/home/$USER/.ssh/authorized_keys

Point 3:

  • At the beginning of the term/course have each student login to their assigned account on the EC2 instance and set a new password.

Explanations

During the provisioning of the EC2 instance, and probably later as well, you have the option of assigning a key for SSH access. The Amazon EC2 console, Network & Security, Key Pairs is the place to handle the key pair for your access to the EC2 instance. There you can have Amazon create the key pair for you, or import a key pair's public key which you have made locally. The default account, created when the EC2 instance is created, and the key pair you create/import for that account to access the EC2 instance, are the equivalent of root on a local machine, sometimes the username is, in fact root on the EC2 instance. That key pair should be shared with the students as often as you share your password with them. (Can anyone say "never"?).

Point 1 - Password and RSA key required to login

The first three lines control what the SSH host (EC2 instance) will accept. PubkeyAuthentication1 has to be yes (the default) or the host will not even accept keys, valid or not. PasswordAuthentication2 defaults to yes, and could be commented out, or even missing, and it would still work. The caveat here is that thigs will go very bad if it is set to no. (Bad, in this case, means destroying the EC2 instance and creating a new one, as the final settings will require a key and a password, yet no here will prevent the SSH host from asking for one.) The PermitEmptyPasswords3 setting of no just stops the students from accessing their account over SSH with an empty password. It will not prevent them from setting their password to a blank one. If they do, they'll have to get the instructor's assistance to reset the password, and maybe learn a lesson in the process. Lastly, the setting AuthenticationMethods4 specifies what methods are required for authentication.

The EC2 instances are supposed to be operationally equivalent to bare-metal Linux installs. (All be it, without the hardware acquisition and maintenance costs.) Treat yours as such. Each student should have their own, regular Linux, account on the EC2 instance, with all the normal restrictions and settings that you would use if it were a server in your lab room. As the owner of the instance, effectively if not actually root, you can access the student user directories and process/validate/censor them as needed.

The process of creating a new user on an EC2 instance is the same as any other Linux install. sudo adduser new_user_name. As I understand it, newly create user accounts on the EC2 instance will not have the needed directory structure for using SSH access. The process for creating it, and adding the public key at the same time, are fairly short.

sudo adduser new_user_name
sudo su - new_user_name
mkdir .ssh
chmod 700 .ssh
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDcsebwlu3jVUJfPunR8aENmxcRQKva00MDi7aiyeSh7cpzQpCFK/gqTRGmqZvI6H/0QImek5JfPkJDgUkPHfhlawHRKrEzsvCeiPzKuMT1UHs5wASqHuxTJrjklJeR/knFxdCZZ4kyYFFomdFKsLTR5VPLK/2H3c6APs4+XPxE2Q== gypsyspellweaver@cseducators.stackexchange.com" > .ssh/authorized_keys
chmod 0600 .ssh/authorized_keys

Where _new_user_name_ is the name of the user account you wish to create, and the long echo line contains the .pub file contents for the student access key that you've created beforehand. (Description below.) (In this example I used a 1024-bit key just to keep the sample line short. In practice it should be 2048-bit, at least. AWS EC2 does not accept DSA keys, and I don't know if they accept Ed25519 keys.)

Point 2 - One key for all

As mentioned above, the key pair you use to access the EC2 instance gives you root powers. That is not the one key you want the students using. Of course, the key + passphrase setting applies to you as well, once you have set it in the sshd_config file, so even with your key pair, the students would need to know, or guess, your password as well. Still, that's easier than getting the key should be. Making a second key for all the students to use is simple enough, and you can even make it without a passphrase. The command, on a local machine,

ssh-keygen -b 4096 -t rsa -N '' -C student_access@AWS-EC2 -f student_access

will create the key pair, saved in student_access for the private key, and student_access.pub for the public key.

The content of student_access.pub, which is a long single line, is what is quoted in the echo command in the above snippet, to be copied into each students' EC2 home directory structure.

The other file, student_access, is the file which needs to be distributed to each computer, and to each appropriate account on each computer, which is supposed to have access to the EC2 instance. In addition, if the students are expected to have access to the EC2 instance from their personal devices, that same key will have to be made available to them so that it can be imported into their devices. Home computers and laptops are expected. Mobile devices, however, are also possible. I routinely use my cheap Samsung Galaxy J1 to SSH into servers I maintain. It is possible, with more work on your end, to have a different passphrase on each of the distributed copies of the private key. The command above creates one without a passphrase. Removing the -N '' option will cause ssh-keygen to prompt for a passphrase during creation. After the private key is copied to a different computer, of different directory, the command ssh-keygen -p -f student_access will prompt for the old (if one exists) and new passphrases, re saving the private key with that passphrase. Having a passphrase on the key will prompt for it when the key is used, with some caching, causing the SSH access to be double passphrase protected. Of course, knowing the passphrase also allows the student to change it to a blank, also valid, passphrase with no way for you to enforce it having one.

No matter how it is done, with or without passphrases, you could end up having nearly a hundred copies of the private key floating around in student hands. That is per class. In addition, so that they don't loose the key, you can expect that some of the students will email it to themselves, causing it to be even more "distributed" than your original plans.

If, as I do, you prefer to use GnuPG for handling keys, the following snippet will create the key pair, in a soon to be deleted sandbox directory.

mkdir sandbox
pushd sandbox
mkdir -p .keyring/{openpgp-revocs,private-keys-v1}.d
chmod -R 0700 .keyring/
gpg --homedir .keyring --batch --pinentry-mode loopback --passphrase '' --quick-generate-key student_access@AWS-EC2 rsa4096 auth 12m
gpg --homedir .keyring/ --batch --pinentry-mode loopback --passphrase '' --output student_access.gpg --export-secret-key student_access@AWS-EC2
gpg --homedir .keyring/ --output student_access.pub --export-ssh-key student_access@AWS-EC2
popd
mv sandbox/student_access.* .
rm -rf sandbox

The student_access.pub file is, again, the one to use in each user account on the EC2 instance, and looks the same as that created by ssh-keygen above. The student_access.gpg file is copied to each local machine, and account, where the command gpg --import student_access.gpg is used from within that local account, adding it to the user's default keyring.

The option group --batch --pinentry-mode loopback --passphrase '' in two of the commands creates, or uses, a blank passphrase for the key. Removing the entire group results in prompting for the passphrase during creation, and exporting the private key. Alternatively, it is possible to include the passphrase in the commands by placing it inside the single quotes. The command to change the passphrase in this processes is gpg --change-passphrase student_access@AWS-EC2 with a prompt for both the old and new passphrases.

Point 3 - Let students pick their password

This is standard Linux behavior after creating a user for each on the EC2 instance, and takes care of itself. The only protection taken in this setup is to prevent them from making their choosen password as blank. If, as mentioned above, the make that choice, they will be locked out of their account until you issue the command: sudo passwd user_name and enter a new password, which they would be expected to change, to a non-blank version this time.


Alternative setup:

Teaching Linux basics and BASH implies the command line as well. That seems like a good time to also cover some of the aspects of security. The rollout of the provisioning for each term can be included in the corsework. This can include the command line use of ssh-keygen, or GnuPGP (gpg), as the case may be. (Both is also an option.) The inclusion of C in your couse suggests that git could also be included, in which case I would recommend the use of gpg, as that will allow creation of both an authentication key for access to the EC2 instance and a signing key to use on signed commits in the repository. Especially usefull if you have group projects planned.

Teaching about security should also imply that you are doing security with the setup of the students' system. The single RSA key pair seems contrary to that. If a student leaves the course early you would be expected to create a new key pair, and redistribute it all over again. Otherwise that student need only guess another student's password, if it wasn't already shared with them, or they didn't watch it being typed, and have access to a former classmate's account. Of course, that applies even if the student has not left. They could still have learned another's password and then have access to a fellow student's area, and work, on the EC2 instance.

Having a key pair unique to each student can be more complicated. Especially if the local computer situation is such that any student could be using any workstation. It is possible that the use of EC2 instances for the student workarea is the solution to the other problems associated with undesignated workstations in the classroom. Some of the issues can be resovled with roaming profiles for the school network. If that is not something the school has established, however, it isn't any help here either. Using USB thumb drives is also an option, and the SSH key, or GnuPG keyring, could be kept there, either by default as part of the login profile, or manually. The ssh command allows for the identity file to be explicitly named with the -i /path/to/identity/file option, and the gpg command accepts the --homedir /path/to/keyring option as well as the GNUPGHOME=/path/to/keyring environment variable. In both cases the thumbdrive could be the path used.

The other side of the complication can be significantly reduced by using shell scripts for creating and distributing the key pairs, if it is not added as lesson material for hands-on lab work in the course. The first day of class could be built around accessing the EC2 instance prior to public key authentication, where they change their password and create, import, and backup their keys. Use ssh-keygen for the first day. Later, when their corsework has progressed to that point, create, and authorize new keys using gpg, which can be expanded later by adding a signing subkey for git commits, and then an encryption key for other work.

The snippets given above (for creating the keys, and for provisioning the EC2 instance) are well suited for using shell parameters in variables and the entire class could be supplied with keys, and EC2 user accounts, using scripts you create, and cancel the majority of the work you would need to do for each class.

The security issues, in my mind, seem to outweigh the "convenience" of a single key, and scripting can greatly reduce the time and effort involved in using unique key pairs for each student, and even for each device students might have, and wish to use for the class. Android and iOS apps for SSH have either the ability to generate key pairs, or to import them. Some have both options. A few also have the ability to export their private keys for storage.

$\endgroup$
  • $\begingroup$ Thank you so much! This is what I needed and well beyond. I haven't done it yet but I will update once I do. $\endgroup$ – Matthew W. Nov 14 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.