Hi,

Refer line in setup_logs() function :
curl "https://amazoncloudwatch-agent-${REGION}.s3.${REGION}.${URL_SUFFIX}/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm"

In sydney region this results in error and I am sure it will error out in other regions.
curl: (6) Could not resolve host: amazoncloudwatch-agent-ap-southeast-2.s3.ap-southeast-2

New URL in Sydney will be curl https://s3.ap-southeast-2.amazonaws.com/amazoncloudwatch-agent-ap-southeast-2/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm

So in the script it should be :
curl
https://s3.${REGION}/amazoncloudwatch-agent-${REGION}/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm"

When I am using my own S3 url and try to run quickstart confluence template that time bastion template autoscaling going to fail

In an effort to turn the bastion hosts into truely ephemeral instances, EIP assignment logic needs to be decoupled.

Currently thinking lambda + CWEvents (ASG) + SSM Parameter Store.

Hello there,
I just tried launching a new Bastion on the Ubuntu 16.04 AMI (region: us-east-1) defined in the latest CFN template in this repo. I have been using a slightly modified version of the template/script provided here to get custom Banner text to download properly from S3.

The Problem:
Cloudformation create-stack fails when deploying the AutoScalingGroup.
Cloudformation error: "Received 1 FAILURE signal(s) out of 1. Unable to satisfy 100% MinSuccessfulInstancesPercent requirement"

EC2 Instance System log:
"[ 89.696286] cloud-init[1339]: Finished processing dependencies for aws-cfn-bootstrap==1.4
[ 90.109857] cloud-init[1339]: Error occurred during build: Command b-bootstrap failed
"

Internet connectivity is not an issue as the instance was able to download all the dependencies and the aws-cfn-boostrap lib itself.

The Fix: Re-launching with the Ubuntu 14.04 AMI.

I have reproduced the issue several times. I have not dug into the instance logs to investigate why it is failing. My previous CFN Stack was launched on March 31st with no issues using 16.04 LTS AMI. It was only today that I encountered this issue.

Thanks for the robust Bastion templates/scripts, I love using them and I learned alot from reading through the code. Hopefully this helps anyone else trying to launch with the Ubuntu 16.04 LTS AMI.

Hi,

I tried to use this CF template to setup linux bastion in existing VPC.
Unfortunately template times out on "AWS::AutoScaling::AutoScalingGroup" step each time I tried.
When it failed I see that EC2 and EIP resources created successfully but EIP is not associated with EC2 instance. If I associate it manually I'm able to SSH to EC2 instance without any issues. I also checked that instance have access to internet. But I don't see the "bastion_bootstrap.sh" in temp folder. Any idea whats wrong? Is something wrong with "AWS::CloudFormation::Init" step so "bastion_bootstrap.sh" failed to download on instance?

thanks

Currently sending logs to CloudWatch is not working at all on CentOS.

Can anybody have a look at following pull requests to fix it:
#53
#54
#55

I came across Nicolas Malaval's How to Record SSH Sessions Established Through a Bastion Host 14 Jun 2016 post in the AWS Security Blog, which provides a CloudFormation template for bootstrapping a bastion host. It seems that there's significant overlap between that blog post and this QuickStart solution, leading to some confusion as to which of the two solutions is the recommended approach, and what are the strengths/drawbacks or recommended use-cases for each.

Would it be possible to reconcile the two bastion-host bootstrap scripts, whether this involves deprecating one in favor of the other, or merging the features of both into a single unified and well-maintained solution?

Specifically, I'm interested in the specific set of commands contained within each approach's bootstrap shell script, which seem to be using completely different methods of locking down the bastion server. I'm wondering if a direct comparison can be made between them, and which approach is more secure, maintainable and/or battle-tested than the other.

The recent change to accept the URL_SUFFIX used in setting up logs does not have a default value and is not a backwards compatible change. A default value should be set to avoid breaking any existing scripts

Downstream dependencies have indicated Tags on Volumes would be nice to have.

We need to add support for these regions.

Custom ssh banner config has a leading space which prevents the correct configuration of the featgure. PR following.

echo -e "\n Banner ${BANNER_FILE}" >>/etc/ssh/sshd_config <~~ Space between \n and Banner

on changing the bucket name in the template, the stack launch fails with the error message
"Received 1 FAILURE signal(s) out of 1. Unable to satisfy 100% MinSuccessfulInstancesPercent requirement".
I have also tried changing each and every field related to the bucket(IAM policy, refernces etc) but it does not seem to work.
according to the logs the command which runs the bastion_bootstrap script fails each time and i have no idea why.
cfn-init.log

I have a use case to use this template on dedicated hardware, can you please support

PlacementTenancy: 
        Ref: PlacementTenancy

on https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-launchconfig.html#cfn-as-launchconfig-placementtenancy

🙏 thanks for this!

Hi there,
It seems I'm hitting an old issue that was reported on #43:
Cloning into '/tmp/quickstart-atlassian-jira/submodules/quickstart-atlassian-services/submodules/quickstart-amazon-aurora/submodules/quickstart-linux-bastion'... [email protected]: Permission denied (publickey).
fatal: Could not read from remote repository

The above was triggered with the following command:
git clone --recurse-submodules https://github.com/aws-quickstart/quickstart-atlassian-jira.git

Is there any workaround?
Thank you.

In the harden_ssh_security function you touch /tmp/messages which is only called when tcp_forwarding param is false. However your ubuntu_os // amazon_os functions assume the availability of this dir and chown it. This results in a critical failure.

I'm happy to PR if you could give me some contribution guidelines.

Thanks,
Dom

Begin dump of /var/log/cfn-init.log

2017-04-24 04:46:43,790 [DEBUG] CloudFormation client initialized with endpoint https://cloudformation.ap-southeast-2.amazonaws.com
2017-04-24 04:46:43,791 [DEBUG] Describing resource BastionLaunchConfiguration in stack Bastion
2017-04-24 04:46:44,256 [INFO] -----------------------Starting build-----------------------
2017-04-24 04:46:44,299 [DEBUG] Not setting a reboot trigger as scheduling support is not available
2017-04-24 04:46:44,300 [INFO] Running configSets: default
2017-04-24 04:46:44,301 [INFO] Running configSet default
2017-04-24 04:46:44,301 [INFO] Running config config
2017-04-24 04:46:44,301 [DEBUG] No packages specified
2017-04-24 04:46:44,301 [DEBUG] No groups specified
2017-04-24 04:46:44,301 [DEBUG] No users specified
2017-04-24 04:46:44,302 [DEBUG] No sources specified
2017-04-24 04:46:44,302 [DEBUG] Writing content to /tmp/bastion_bootstrap.sh
2017-04-24 04:46:44,302 [DEBUG] Retrieving contents from https://redacted.s3.amazonaws.com/linux/bastion/bastion_bootstrap.sh
2017-04-24 04:46:44,443 [DEBUG] Setting mode for /tmp/bastion_bootstrap.sh to 000550
2017-04-24 04:46:44,443 [DEBUG] Setting owner 0 and group 0 for /tmp/bastion_bootstrap.sh
2017-04-24 04:46:44,443 [DEBUG] Running command b-bootstrap
2017-04-24 04:46:44,443 [DEBUG] No test for command b-bootstrap
osrelease Ended
2017-04-24 04:46:44,713 [ERROR] Command b-bootstrap (./tmp/bastion_bootstrap.sh --banner https://redacted.s3.amazonaws.com/linux/bastion/banner_message.txt --enable true --tcp-forwarding true --x11-forwarding false) failed
2017-04-24 04:46:44,714 [DEBUG] Command b-bootstrap output: checkos Ended
BANNER_PATH = https://redacted.s3.amazonaws.com/linux/bastion/banner_message.txt
Creating Banner in /etc/ssh_banner
curl  -s https://redacted.s3.amazonaws.com/linux/bastion/banner_message.txt > /etc/ssh_banner
[INFO] Installing banner ... 
Setting up bastion session log in /var/log/bastion/bastion.log
Value of TCP_FORWARDING - true
Value of X11_FORWARDING - false
chown: cannot access '/tmp/messages': No such file or directory

2017-04-24 04:46:44,714 [ERROR] Error encountered during build of config: Command b-bootstrap failed
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/aws_cfn_bootstrap-1.4-py2.7.egg/cfnbootstrap/construction.py", line 517, in run_config
    CloudFormationCarpenter(config, self._auth_config).build(worklog)
  File "/usr/local/lib/python2.7/dist-packages/aws_cfn_bootstrap-1.4-py2.7.egg/cfnbootstrap/construction.py", line 248, in build
    changes['commands'] = CommandTool().apply(self._config.commands)
  File "/usr/local/lib/python2.7/dist-packages/aws_cfn_bootstrap-1.4-py2.7.egg/cfnbootstrap/command_tool.py", line 117, in apply
    raise ToolError(u"Command %s failed" % name)
ToolError: Command b-bootstrap failed
2017-04-24 04:46:44,714 [ERROR] -----------------------BUILD FAILED!------------------------
2017-04-24 04:46:44,718 [ERROR] Unhandled exception during build: Command b-bootstrap failed
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/aws_cfn_bootstrap-1.4-py2.7.egg/EGG-INFO/scripts/cfn-init", line 171, in <module>
    worklog.build(metadata, configSets)
  File "/usr/local/lib/python2.7/dist-packages/aws_cfn_bootstrap-1.4-py2.7.egg/cfnbootstrap/construction.py", line 118, in build
    Contractor(metadata).build(configSets, self)
  File "/usr/local/lib/python2.7/dist-packages/aws_cfn_bootstrap-1.4-py2.7.egg/cfnbootstrap/construction.py", line 505, in build
    self.run_config(config, worklog)
  File "/usr/local/lib/python2.7/dist-packages/aws_cfn_bootstrap-1.4-py2.7.egg/cfnbootstrap/construction.py", line 517, in run_config
    CloudFormationCarpenter(config, self._auth_config).build(worklog)
  File "/usr/local/lib/python2.7/dist-packages/aws_cfn_bootstrap-1.4-py2.7.egg/cfnbootstrap/construction.py", line 248, in build
    changes['commands'] = CommandTool().apply(self._config.commands)
  File "/usr/local/lib/python2.7/dist-packages/aws_cfn_bootstrap-1.4-py2.7.egg/cfnbootstrap/command_tool.py", line 117, in apply
    raise ToolError(u"Command %s failed" % name)
ToolError: Command b-bootstrap failed
2017-04-24 04:46:44,854 [DEBUG] CloudFormation client initialized with endpoint https://cloudformation.ap-southeast-2.amazonaws.com
2017-04-24 04:46:44,854 [DEBUG] Signaling resource BastionAutoScalingGroup in stack Bastion with unique ID i-00c594757dd394312 and status FAILURE

The current way to force logging to bastion.log can be easily circumvented:

1. The PROMPT_COMMAND variable is set in /etc/bashrc, which is sourced by .bashrc in the user's home and which is under the user's control. A user can modify that file to prevent sourcing /etc/bashrc, logout and re-login, and escape logging. /etc/profile.d/ would be a better place for setting this variable.

2. Even if set in /etc/profile.d/, /etc/profile and /etc/profile.d/ files are only sourced if the shell is a login shell, or spawned with the --login option. Choosing /etc/profile.d/ would mean adding that option to the bash spawned in the ForceCommand script.

3. Even if the prompt command is forced correctly upon login, it would be enough for the user to spawn a non-login bash, to avoid sourcing /etc/profile. The PROMPT_COMMAND variable is then no longer readonly in the subshell, and can be unset. And logging is no longer performed.

I know a version 2 is being worked on currently. But are there thoughts on how to correct this?

Thank you!

If the launchconfiguration parameters modifies, the old bastion host shloud be deatach EIP and be terminated. After the termination the autoscaling group with the new launch config should initialize a new bastion host with the new parameters.
Please add this support to the template.

Hey,
I got an error "Template format error: Rules block references undeclared parameters: [VPCTenancy]" during the stack process.

The RemoteAccessCIDR parameter only supports a single CIDR block. In practice, one may desire to specify multiple disjoint ranges. Perhaps if it were defined as a CommaDelimitedList?

Would be great to be able to get some key-value pairs to this script, so that bootstrapping can be tailored to a deployment.

A stack parameter that allows a comma separated list of key=value that then get exported as environment variables, which the initialization script can consume should do the trick.

In my use case I want to pre-configure the kubernetes cli for the environment. to do this I need to create a config file with several environment specific values. With the current static file my only option is to dynamically write the values into the AlternativeInitializationScript file before executing the bastion stack, which seems like a lot more effort than necessary.

As Ubuntu 20.04 is out as LTS version it would be good to add support for it.

Deployed this quickstart with the Amazon-Linux2-HVM AMI. The BastionAutoScalingGroup failed to deploy with:

Received 1 FAILURE signal(s) out of 1. Unable to satisfy 100% MinSuccessfulInstancesPercent requirement

Disabled rollback and checked the instance and in cfn-init.log I see:

2020-07-27 15:29:15,275 [ERROR] Error encountered during build of config: Command b-bootstrap failed
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/cfnbootstrap/construction.py", line 542, in run_config
    CloudFormationCarpenter(config, self._auth_config).build(worklog)
  File "/usr/lib/python2.7/site-packages/cfnbootstrap/construction.py", line 260, in build
    changes['commands'] = CommandTool().apply(self._config.commands)
  File "/usr/lib/python2.7/site-packages/cfnbootstrap/command_tool.py", line 117, in apply
    raise ToolError(u"Command %s failed" % name)
ToolError: Command b-bootstrap failed
2020-07-27 15:29:15,278 [ERROR] -----------------------BUILD FAILED!------------------------
2020-07-27 15:29:15,283 [ERROR] Unhandled exception during build: Command b-bootstrap failed
Traceback (most recent call last):
  File "/usr/bin/cfn-init", line 171, in <module>
    worklog.build(metadata, configSets)
  File "/usr/lib/python2.7/site-packages/cfnbootstrap/construction.py", line 129, in build
    Contractor(metadata).build(configSets, self)
  File "/usr/lib/python2.7/site-packages/cfnbootstrap/construction.py", line 530, in build
    self.run_config(config, worklog)
  File "/usr/lib/python2.7/site-packages/cfnbootstrap/construction.py", line 542, in run_config
    CloudFormationCarpenter(config, self._auth_config).build(worklog)
  File "/usr/lib/python2.7/site-packages/cfnbootstrap/construction.py", line 260, in build
    changes['commands'] = CommandTool().apply(self._config.commands)
  File "/usr/lib/python2.7/site-packages/cfnbootstrap/command_tool.py", line 117, in apply
    raise ToolError(u"Command %s failed" % name)
ToolError: Command b-bootstrap failed

In cfn-init-cmd.log we can see the problem:

2020-07-27 15:29:15,275 P22238 [INFO]           package amazon-cloudwatch-agent-1.246396.0-1.x86_64 is already installed
2020-07-27 15:29:15,275 P22238 [INFO] ------------------------------------------------------------
2020-07-27 15:29:15,275 P22238 [ERROR] Exited with error code 1

It appears as though the cloudwatch agent is already installed and RPM treats this as an error.
Here are the relevant commands in bastion_bootstrap.sh:

        curl "https://amazoncloudwatch-agent-${REGION}.s3.${REGION}.${URL_SUFFIX}/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm" -O
        rpm -U ./amazon-cloudwatch-agent.rpm
        rm ./amazon-cloudwatch-agent.rpm

Testing this manually:

[ec2-user@ip-10-0-20-47 tmp]$ ls
amazon-cloudwatch-agent.rpm  bastion_bootstrap.sh  messages  motd.partTNFWF  motd.WpB9E  systemd-private-6577bb784a8f4db2bbe72e33a87868e3-chronyd.service-aYia7U
[ec2-user@ip-10-0-20-47 tmp]$ sudo rpm -U ./amazon-cloudwatch-agent.rpm
	package amazon-cloudwatch-agent-1.246396.0-1.x86_64 is already installed
[ec2-user@ip-10-0-20-47 tmp]$ echo $?
1

Note that adding --force works around the issue, but perhaps not the best solution.

[ec2-user@ip-10-0-20-47 tmp]$ sudo rpm -U --force ./amazon-cloudwatch-agent.rpm
Redirecting to /bin/systemctl stop amazon-cloudwatch-agent.service
[ec2-user@ip-10-0-20-47 tmp]$ echo $?
0

I'm interested in using the EKS quickstart as a starting point for a new EKS deployment. While the Bastion setup is really cool, I was wondering: would the newer AWS Client VPN SaaS offering be a valid replacement? https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/what-is.html
It would make these kind of deployments even less complex than they already are :-)

It seems that a separate team at AWS has published a separate CloudFormation template to create a bastion host at aws-samples/startup-kit-templates.

The Quick Start template in this project and this newer Startup Kit template offer different implementations of the same type of solution, leading to some confusion as to which of the two solutions is the approach recommended by AWS, or if both are still current, what are the strengths/drawbacks or recommended use-cases for each.

Would it be possible to reconcile the two bastion-host templates, whether this involves deprecating one in favor of the other, or merging the features of both into a single unified and well-maintained solution?

I'm wondering if a direct comparison can be made between them, and which approach is more secure, maintainable and/or battle-tested than the other.

(Note that this is a repeat of issue #1 - this is the third time AWS has published a bastion host CloudFormation template I'm aware of.)

Hi,

I am running the stack for existing VPC in eu-central-1. Unfortunately every time it fails when creating the autoscaling group with the message:

BastionAutoScalingGroup Received 1 FAILURE signal(s) out of 1. Unable to satisfy 100% MinSuccessfulInstancesPercent requirement

I am using all the default values apart from the QSS3KeyPrefix value.
Thanks.

Expand GovCloudCondition to include us-gov-east-1.
Change URLs to refer to us-gov-east-1 buckets when running in us-gov-east-1.

We are using aws-quickstart/quickstart-linux-bastion repository to deploy bastion host. The bastion host deployment fails as cfn-init script is not able to access bastion_bootstrap.sh from s3 bucket. It looks like signature version not being compatible is the root cause of the problem. PFA cfn-init.log
cfn-init.log

We observed in cfn-init.log that Signature Version 2 is used as no region was specified in S3 URL. It looks like issue occurred due to signature version incompatibility.

We are deploying cloud formation stack using taskcat with QSS3BucketName: $[taskcat_autobucket]

Hi, we have noticed that launching a new bastion host (adding one more in the auto scaling group config), the new bastion host allows copy files with SCP, so it seems that the SSH and hardening configuration is not the same as the first instance.

I am using this template as a submodule and also working with EKS. For some reason it seems the AWS cli is outdated on the bastion host. I see the AMI's changed, does anyone know what version the AWS cli should be on the host? I tried updating both pip and aws and now I get this error.

To get the aws cli to support the latest EKS features I did:

easy_install pip
/usr/local/bin/pip3 install awscli --upgrade --user

then my bootstrap finishes with no errors except one error at end:

2019-11-07 13:40:12,492 P2811 [ERROR] Exited with error code 6

and:

[root@ip-10-180-17-136 log]# cfn-init -v --stack stack123-BastionStack-12345--resource BastionLaunchConfiguration --region us-east-1
Error occurred during build: Command b-bootstrap failed

My working theory that updating pip and cli during init is causing this issue. or by updating pip or cli in cfn-init emits some error.

I am guessing it would better to have the latest cli on the bastion regardless, any advice is much appreciated.

Hey,

please can you set explicit versions in the linux-bastion-master.template where you reference to the submodules?

In the file for
"ParameterKey": "QSS3KeyPrefix",
"ParameterValue": "linux/bastion/latest"

is set linux/latest. That relates to the fact that if you want to setup an environtment you end up using this

"https://${QSS3BucketName}.${S3Region}.amazonaws.com/${QSS3KeyPrefix}submodules/quickstart-aws-vpc/templates/aws-vpc.template",
url. If you want to setup this stack again in a few weeks you may be broken because the linux/bastion/latest submodules has changed.

I don't want to modify the AWS provided example. I just want to use it as it is.

Thanks.

This isn't really an issue, but I'm curious what the proposed way is to allow access for multiple users to the bastion.

Would be great to be able to define multiple name/public-key pairs in the template.

Thanks for some tips about how handling this best within this quickstart.
I hope the answer is not to manually ssh into the machine and create the users.

Whichever BastionAMIOS we use on Stockholm region, we always get an error:

Template error: Unable to get mapping for AWSAMIRegionMap::eu-north-1::AMZNLINUXHVM

Template error: Unable to get mapping for AWSAMIRegionMap::eu-north-1::CENTOS7HVM

Template error: Unable to get mapping for AWSAMIRegionMap::eu-north-1::US1604HVM

Template error: Unable to get mapping for AWSAMIRegionMap::eu-north-1::US1404HVM

Hi, are there any plans to add support for af-south-1 Africa (Cape Town) region in AWSAMIRegionMap? We would like to add this region in aws-quickstart/quickstart-bitnami-wordpress but we noticed that the bastion AMI mapping doesn't include it yet.

When the 2nd user tries to use th bastion he get the message:

script: cannot open /tmp/messages: Permission denied

the /tmp/messages file is created for the user/group of the first user.

• Bastion Banner.

Received 1 FAILURE signal(s) out of 1.
Unable to satisfy 100% MinSuccessfulInstancesPercent requirement

Support to deploy with Amazon Linux 2 AMI.

Hi,

FYI
Not all commands are logged using the method in these templates. For example, if a user runs the command:

ls; history -c
ls; history -r

then the command above will not be logged in /var/log/bastion/bastion.log

The above has been tested on a Centos machine, but mechanism is the same on the Amazon/Ubuntu/Centos AMIs.

Paul

Is it possible override LinuxBastion as the name of the host to better match parent stack names?

Refresh architecture diagram

cfn-init.log shows that the parameters was passed with no issues [1], however, the /etc/ssh/sshd_config file is not updating the value of "TCP_FORWARDING" to be considered (It is kept as Yes, but by default it is commented). A workaround was to append the value through the userdata manually.

===========
cfn-init.log

[INFO] Installing banner ...
Value of TCP_FORWARDING - true
Value of X11_FORWARDING - true
setup_os Started
setup_os Ended
setup_logs Started
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 58.3M 100 58.3M 0 0 91.1M 0 --:--:-- --:--:-- --:--:-- 91.0M
create group cwagent, result: 0
create user cwagent, result: 0
Created symlink from /etc/systemd/system/multi-user.target.wants/amazon-cloudwatch-agent.service to /etc/systemd/system/amazon-cloudwatch-agent.service.
prevent_process_snooping Ended
Querying the assigned public IP
Determining EIP Association Status for [<?xml]
Determining EIP Association Status for [34.192.111.204]
Elastic IP [34.192.111.204] already has an association. Moving on.
Determining EIP Association Status for [54.210.64.20]
Elastic IP [54.210.64.20] already has an association. Moving on.
Detected a NULL Value, moving on.
Detected a NULL Value, moving on.
request_eip Ended
Bootstrap complete.

===========
/etc/ssh/sshd_config

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes

[1]

In the .gitmodules file there is URL to the aws-quickstart submodule
url = [email protected]:aws-quickstart/quickstart-aws-vpc.git

Both this and that repo are public, so it should be possible to pull them even without GitHub account and SSH keys. However they are not. It makes quite a big problem e.g. for working with this repo with Jenkins. Could you change the URL to
url = https://github.com/aws-quickstart/quickstart-aws-vpc
please?

It would make our CD process much simpler (less needless dependencies like SSH keys that have to be copied to GitHub).

Would it be possible to consider providing AMIs which are more immutable where appropriate with less of the setup on instance init? We've seen several occurrences using this project where new bastion instances don't start correctly due to point in time failures or outside changes breaking the setup. The last occurrence, one bastion has to be replaced and some problem with the AWS CLI install caused it to not boot and attach the correct EIP. I'm assuming #15 is a similar issue.

Internally we're in the process of taking the nice work here and converting some of it into Packer, leaving things like EIP attachment etc in the init scripts. We already have some of that if it would be useful upstream. If that was provided here it could be the Packer setup run through CI or the project could provide the AMIs (in which case we'd need to consider how to rebuild when the base AMI rebuilds).

I get the following error when i run this template:

The requested configuration is currently not supported. Please check the documentation for supported configurations. Launching EC2 instance failed.

Any ideas what might be wrong?

In AWSAMIRegionMap it misses the Milan region (eu-south-1)

In the following bootstrap script segment, there is a newline sequence followed by an arbitrary whitespace character. I don't know that it will cause any issues for anyone, but it's worth making a quick change.

When using the bastion template as a submodule it would be useful to be able to define the instance profile in my stack, granting whatever permissions are needed for the particular use-case, and pass the arn to the bastion, instead of having a static role assigned as it is done today.

Alternatively, pass the role ARN back to the parent as an output, then i can attach the additional policies to the role.

I believe the while loop within request_eip() is broken. It pulls the list of eligible IP's from the user data, finds two, and the first server races to assign both, resulting in an error.

A simple fix may be calling break after aws ec2 associate-address --instance-id $INSTANCE_ID --allocation-id $EIPALLOC --region $Region

Have I debugged this correctly?

Running associate_eip_now
EIP: 0
NAME: ADDRESSES eipalloc-62cebb55               vpc                                     34.234.121.9
EIP: 34.234.121.9
EIPALLOC: eipalloc-62cebb55
{
    "AssociationId": "eipassoc-edb0c2e5"
}
EIP: 0
NAME: ADDRESSES eipalloc-2ac8bd1d               vpc                                     34.239.67.50
EIP: 34.239.67.50
EIPALLOC: eipalloc-2ac8bd1d

An error occurred (Resource.AlreadyAssociated) when calling the AssociateAddress operation: resource eni-eca15657 and 10.2.41.95 is already associated with public address 34.234.121.9

2018-01-09 18:49:03,912 [ERROR] Error encountered during build of config: Command b-bootstrap failed