Support for systemd, SELinux, and SUSE #99
Conversation
* Add test to determine init system for sshd restart In the install file, I've added a simple test to determine what init system is currently on the system, and to select the correct restart command for sshd that is required. This is tested on the following OSes in EC2: * Amazon Linux 2017.09 (using upstart) * Ubuntu 16.04.3 LTS (using systemd) * SUSE Enterprise Server 12 SP3 (using systemd) * RHEL 7.3 (using systemd) * Hush the stderr message when systemd doesn't exist This is to ensure that the output for a user is the same as it is when using the standard codebase. Message is successfully suppressed on Amazon Linux 2017.09 * Add useradd(1) arg to force user group creation By default on most distros, `USERGROUPS_ENAB` is set to `yes` which causes `useradd(1)` to create a group for a user that is added. There is an implicit dependency on line 179 of the `import_users.sh` script. I've altered the `useradd(1)` argument set to include `-U/--user-group` to force this on systems where `USERGROUPS_ENAB` is set to `no` This is needed to support SUSE Linux Enterprise Server on EC2.
The `install.sh` script currently checks if there is a line that reads `AuthorizedKeysCommand none` and then changes it. Old behaviour was to simply append the line on the end of the file is this line didn't exist. There is now a check to see if the correct line that we want already exists, so we don't spam the end of the configuration file.
If we have the `getenforce` command available to us, and we find that it returns the value `Enforcing` (meaning SELinux will block our access to AWS when called by `sshd`), we enable the `nis_enabled` boolean persistently in SELinux to inform SELinux that it should expect outbound access from sshd and other login programs (like PAM) to remote servers to get user account information. This allows `sshd` to call the script to get the user's public key from IAM. I also cleaned up the `systemd` conditional in the script to use the simpler way to check if commands exist.
Chaining the command check with the return value failed miserably. Reverting this to be normal again.
We use `which(1)` to determine if a command is available to us. According to the man page, `which(1)` will return a return code `1` if the command is not found. Since the script is run with `-e` as an option in the shebang, this causes the script to exit prematurely. I've wrapped the `which(1)` calls in `set +e/set -e` wrappers so that the script continues gracefully.
On systems where `which(1)` doesn't find a given command, it will return exit code `1`. This will cause the script to abort under the `-e` option in the shebang. I've changed the pipeline to capture the return value of which on the other side of a logical OR, which does work correctly, and thus the pipeline gets a 0 return code (making `-e` happy), and I get the return value which tells me whether or not the command exists. Which makes me happy.
I forgot about shortcircuit evaluation. So I've added the success code in the variable before calling `which(1)`. This means that if the command is found, the 0 retval will get used in the test. The only time that it would change that to a non-zero status would be if something wasn't found. Like before, the whole command pipeline will return success, so `-e` stays happy as a clam.
|
thanks! |
|
It looks like the changes broke the tests we have in place. I will have a look at this soon. |
|
Sorry about that! I had been testing manually on EC2 instances that I had spun up, since I was trying to get something working that I was going to deploy internally in my company's cluster via updated AMIs. I hadn't thought of running the Maven test suite with CloudFormation. If you can share the transcript, I'll do what I can to help resolve the test suite issues. |
|
So we currently have two integration tests that basically setup a CloudFortmation stack based on I setted up the stack manually, also specifying a KeyPair that AWS deploys. I can login with user ubuntu, but not with my IAM users. After running |
|
That's interesting that it wasn't reloading that. What AMI-ID are you using when you spin up those ubuntu systems? |
|
e.g. in based on this template: https://github.com/widdix/aws-ec2-ssh/blob/master/showcase.yaml |
|
OK I'll give that a try and see what happens. |
* Support Multiple init daemons and service programs (widdix#1) * Add test to determine init system for sshd restart In the install file, I've added a simple test to determine what init system is currently on the system, and to select the correct restart command for sshd that is required. This is tested on the following OSes in EC2: * Amazon Linux 2017.09 (using upstart) * Ubuntu 16.04.3 LTS (using systemd) * SUSE Enterprise Server 12 SP3 (using systemd) * RHEL 7.3 (using systemd) * Hush the stderr message when systemd doesn't exist This is to ensure that the output for a user is the same as it is when using the standard codebase. Message is successfully suppressed on Amazon Linux 2017.09 * Add useradd(1) arg to force user group creation By default on most distros, `USERGROUPS_ENAB` is set to `yes` which causes `useradd(1)` to create a group for a user that is added. There is an implicit dependency on line 179 of the `import_users.sh` script. I've altered the `useradd(1)` argument set to include `-U/--user-group` to force this on systems where `USERGROUPS_ENAB` is set to `no` This is needed to support SUSE Linux Enterprise Server on EC2. * Add check to not spam the sshd_config file The `install.sh` script currently checks if there is a line that reads `AuthorizedKeysCommand none` and then changes it. Old behaviour was to simply append the line on the end of the file is this line didn't exist. There is now a check to see if the correct line that we want already exists, so we don't spam the end of the configuration file. * Add SELinux support to install script If we have the `getenforce` command available to us, and we find that it returns the value `Enforcing` (meaning SELinux will block our access to AWS when called by `sshd`), we enable the `nis_enabled` boolean persistently in SELinux to inform SELinux that it should expect outbound access from sshd and other login programs (like PAM) to remote servers to get user account information. This allows `sshd` to call the script to get the user's public key from IAM. I also cleaned up the `systemd` conditional in the script to use the simpler way to check if commands exist. * Revert the supposedly clever way of command checks Chaining the command check with the return value failed miserably. Reverting this to be normal again. * Allow which(1) to exit and the script to continue We use `which(1)` to determine if a command is available to us. According to the man page, `which(1)` will return a return code `1` if the command is not found. Since the script is run with `-e` as an option in the shebang, this causes the script to exit prematurely. I've wrapped the `which(1)` calls in `set +e/set -e` wrappers so that the script continues gracefully. * Adjust which(1) pipelines to return valid exit codes On systems where `which(1)` doesn't find a given command, it will return exit code `1`. This will cause the script to abort under the `-e` option in the shebang. I've changed the pipeline to capture the return value of which on the other side of a logical OR, which does work correctly, and thus the pipeline gets a 0 return code (making `-e` happy), and I get the return value which tells me whether or not the command exists. Which makes me happy. * Adjust which(1) blocks to account for shortcircuit eval I forgot about shortcircuit evaluation. So I've added the success code in the variable before calling `which(1)`. This means that if the command is found, the 0 retval will get used in the test. The only time that it would change that to a non-zero status would be if something wasn't found. Like before, the whole command pipeline will return success, so `-e` stays happy as a clam.
|
Do you discovered anything? Otherwise I have to revert the change for now until we have fixed this. I want to create a new release... |
|
I will complete testing the showcase today. I will update here with the results. If a change is needed, I can likely reverse the logic to make systemd the base case. Amazon Linux LTS 2 is now on systemd, so that may be a consideration. As an aside, I am looking at seeing if a .deb package for Ubuntu is more reliable at triggering the service refresh (analogous to the RPM). |
|
Here's what I'm seeing at the moment. I can replicate the issue with the showcase (The "not restarting SSH" issue, #103 is different from this failure case), but manual installation using install.sh works correctly. (Both of these should be identical, however). Following is a transcript of the expected YAML steps of fetching the file using the URL, changing mode to 0755, executing the script, and then showing the status of the I'm going to see if I can get CF to restart the SSH service at the end of running the creation. |
|
Good news. I've found a way to add the ssh service to the CloudFormation stack, so it automatically restarts it when using the showcase on both Ubuntu and Amazon Linux. I'll run the Java test suites to confirm it. |
|
Looks good with the changes to the showcase YAML. I'll open an issue and PR for it. |
The following is an overview of the changes that are in this PR:
systemd,upstart, and legacySysVinit scripts)USERGROUPS_ENABis set tonoin/etc/login.defsinstall.shscript to stop it from spamming/etc/ssh/sshd_configwith the configuration directives when they already exist (e.g. if a user were to runinstall.shtwice)The
systemdchanges should also search for both of the styles of naming thesshdservice. On Ubuntu 16.04 LTS (and likely others in the Debian family), the service is namedssh.service. Everywhere else that I tested, it is namedsshd.service.Helpfully, Canonical puts an alias line in their unit file, but I feel it's more correct to search for the unit file and then use that to make the correct call.
For SUSE, this is just a matter of explicitly telling
useradd(8)to create a group for each user. The option has no effect on other distros (as that was default behavior), but it's probably better to be explicit with the call.For SELinux, we simply check if we have SELinux utilities installed (which are required if you use the SELinux kernel modules), and if they exist, call the
selinuxenabledcommand to get if SELinux is explicitly disabled.If it's disabled (as on Amazon Linux), we ignore setting the boolean as it would have no effect.
If it is enabled (and it doesn't matter if SELinux is in Permissive or Enforcing mode), we set the boolean so we don't clog up the audit logs (Permissive mode), or get blocked (Enforcing mode).
This has been tested on the following AMIs (All AMI IDs are for region us-east-2):
This should resolve the following open issues:
#84