Answers.Body: <p>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.</p>
  
  <h2>Short answer</h2>
  
  <h3>Point 1:</h3>
  
  <ul>
  <li>Edit the instance's <code>/etc/ssh/sshd_config</code> file and check that these lines are there:</li>
  </ul>
  
  <pre><code>PubkeyAuthentication yes
  PasswordAuthentication yes
  PermitEmptyPasswords no
  </code></pre>
  
  <ul>
  <li>Then add this line to require the use of <strong>both</strong> a key and password to access the instance</li>
  </ul>
  
  <pre><code>AuthenticationMethods publickey,password
  </code></pre>
  
  <h3>Point 2:</h3>
  
  <ul>
  <li><p>Create the <em>one key to rule them all</em> with <code>ssh-keygen</code> or <code>gpg</code></p></li>
  <li><p>Copy the private key file to each local machine which will access the EC2 instance</p></li>
  <li><p>Create user accounts for each student on the EC2 instance</p></li>
  <li><p>For each user account on the instance add the public key to this file:</p></li>
  </ul>
  
  <pre><code>/home/$USER/.ssh/authorized_keys
  </code></pre>
  
  <h3>Point 3:</h3>
  
  <ul>
  <li>At the beginning of the term/course have each student login to their assigned account on the EC2 instance and set a new password.</li>
  </ul>
  
  <h2>Explanations</h2>
  
  <p>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 &amp; Security, Key Pairs is the place to handle the key pair for <em>your</em> 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 <code>root</code> on a local machine, sometimes the username is, in fact <code>root</code> 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 "<em>never</em>"?).</p>
  
  <h3>Point 1 - Password <em>and</em> RSA key required to login</h3>
  
  <p>The first three lines control what the SSH host (EC2 instance) will accept. <code>PubkeyAuthentication</code><sup><a href="https://man.openbsd.org/sshd_config#PubkeyAuthentication" rel="nofollow noreferrer">1</a></sup> has to be <code>yes</code> (the default) or the host will not even accept keys, valid or not. <code>PasswordAuthentication</code><sup><a href="https://man.openbsd.org/sshd_config#PasswordAuthentication" rel="nofollow noreferrer">2</a></sup> defaults to <code>yes</code>, 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 <code>no</code>. (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 <code>no</code> here will prevent the SSH host from asking for one.) The <code>PermitEmptyPasswords</code><sup><a href="https://man.openbsd.org/sshd_config#PermitEmptyPasswords" rel="nofollow noreferrer">3</a></sup> setting of <code>no</code> just stops the students from accessing their account over SSH with an empty password. It <em>will not</em> 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 <code>AuthenticationMethods</code><sup><a href="https://man.openbsd.org/sshd_config#AuthenticationMethods" rel="nofollow noreferrer">4</a></sup> specifies what methods are required for authentication.</p>
  
  <p>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 <code>root</code>, you can access the student user directories and process/validate/censor them as needed.</p>
  
  <p>The process of creating a new user on an EC2 instance is the same as any other Linux install. <code>sudo adduser new_user_name</code>. 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.</p>
  
  <pre><code>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" &gt; .ssh/authorized_keys
  chmod 0600 .ssh/authorized_keys
  </code></pre>
  
  <p>Where _new_user_name_ is the name of the user account you wish to create, and the long <code>echo</code> line contains the <code>.pub</code> 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.)</p>
  
  <h3>Point 2 - One key for all</h3>
  
  <p>As mentioned above, the key pair <em>you</em> use to access the EC2 instance gives you root powers. That is not the <em>one</em> key you want the students using. Of course, the key <strong>+</strong> passphrase setting applies to you as well, once you have set it in the <code>sshd_config</code> 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,</p>
  
  <pre><code>ssh-keygen -b 4096 -t rsa -N '' -C student_access@AWS-EC2 -f student_access
  </code></pre>
  
  <p>will create the key pair, saved in <code>student_access</code> for the private key, and <code>student_access.pub</code> for the public key.</p>
  
  <p>The content of <code>student_access.pub</code>, which is a long single line, is what is quoted in the <code>echo</code> command in the above snippet, to be copied into each students' EC2 home directory structure.</p>
  
  <p>The other file, <code>student_access</code>, 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 <code>-N ''</code> option will cause <code>ssh-keygen</code> to prompt for a passphrase during creation. After the private key is copied to a different computer, of different directory, the command <code>ssh-keygen -p -f student_access</code> 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.</p>
  
  <p>No matter how it is done, with or without passphrases, you could end up having nearly a hundred copies of the <strong>private</strong> key floating around in student hands. That is per class. In addition, so that they don't <em>loose</em> 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.</p>
  
  <p>If, as I do, you prefer to use <a href="https://gnupg.org/" rel="nofollow noreferrer">GnuPG</a> for handling keys, the following snippet will create the key pair, in a soon to be deleted sandbox directory.</p>
  
  <pre><code>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
  </code></pre>
  
  <p>The <code>student_access.pub</code> file is, again, the one to use in each user account on the EC2 instance, and looks the same as that created by <code>ssh-keygen</code> above. The <code>student_access.gpg</code> file is copied to each local machine, and account, where the command <code>gpg --import student_access.gpg</code> is used from within that local account, adding it to the user's default keyring.</p>
  
  <p>The option group <code>--batch --pinentry-mode loopback --passphrase ''</code> 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 <code>gpg --change-passphrase student_access@AWS-EC2</code> with a prompt for both the old and new passphrases.</p>
  
  <h3>Point 3 - Let students pick their password</h3>
  
  <p>This is standard Linux behavior after creating a user for each on the EC2 instance, and takes care of itself. The only <em>protection</em> 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: <code>sudo passwd user_name</code> and enter a new password, which they would be expected to change, to a non-blank version this time.</p>
  
  <hr>
  
  <h2>Alternative setup:</h2>
  
  <p>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 <code>ssh-keygen</code>, or GnuPGP (<code>gpg</code>), as the case may be. (Both is also an option.) The inclusion of C in your couse suggests that <code>git</code> could also be included, in which case I would recommend the use of <code>gpg</code>, 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.</p>
  
  <p>Teaching about security should also imply that you are <em>doing</em> 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.</p>
  
  <p>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 <code>ssh</code> command allows for the identity file to be explicitly named with the <code>-i /path/to/identity/file</code> option, and the <code>gpg</code> command accepts the <code>--homedir /path/to/keyring</code> option as well as the <code>GNUPGHOME=/path/to/keyring</code> environment variable. In both cases the thumbdrive could be the path used.</p>
  
  <p>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 <code>ssh-keygen</code> for the first day. Later, when their corsework has progressed to that point, create, and authorize new keys using <code>gpg</code>, which can be expanded later by adding a signing subkey for git commits, and then an encryption key for other work.</p>
  
  <p>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 <em>work</em> you would need to do for each class.</p>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-11-14T21:32:30.447Z
Answers.Text: 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.
Answers.UserDisplayName: Matthew W.
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-11-06T08:30:08.993Z
Answers.LastActivityDate: 2019-11-06T08:30:08.993Z
Answers.UserDisplayName: Gypsy Spellweaver
Body: <p>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. </p>
  
  <p>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.</p>
  
  <p>I'm currently trying AWS's basic EC2, but it's unclear if all of the following is possible: </p>
  
  <p>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...</p>
  
  <p>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)</p>
  
  <p>3) How to let users set their own passwords - ideally initial password is universal, but on day 1 they could personalize.</p>
  
  <p>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.</p>
  
  <p>Has anyone done something similar? I know many universities do essentially this, though usually with their own servers rather than cloud-based ones.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-11-04T16:00:11.230Z
Comments.Text: 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...
Comments.UserDisplayName: srattigan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-11-04T17:03:56.600Z
Comments.Text: 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.
Comments.UserDisplayName: Gypsy Spellweaver
Tags: <resource-request><classroom-infrastructure>
Title: Setting up a cloud-server SSH login procedure for a class? (AWS)
ThreadText: # Setting up a cloud-server SSH login procedure for a class? (AWS)
  
  (Asked by: username_0 on 2019-11-04)
  
  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.
  
  **Tags:** resource-request, classroom-infrastructure
  
  > **Comments:**
  > **username_1**: 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...  
  > **username_2**: 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.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-11-06. Score: 2 | Accepted answer
  
  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. `PubkeyAuthentication`[1](https://man.openbsd.org/sshd_config#PubkeyAuthentication) has to be `yes` (the default) or the host will not even accept keys, valid or not. `PasswordAuthentication`[2](https://man.openbsd.org/sshd_config#PasswordAuthentication) 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 `PermitEmptyPasswords`[3](https://man.openbsd.org/sshd_config#PermitEmptyPasswords) 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 `AuthenticationMethods`[4](https://man.openbsd.org/sshd_config#AuthenticationMethods) 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== username_2@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](https://gnupg.org/) 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.
  
  > **Comments:**
  > **username_0**: 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.  
  
  ---
  
  