Thanks for clarifying. Yes , I also saw the possibility of extending role based IAM to add on-premise image (that could be interesting for VyOS).

@fernando

1. In order to apply SSM auto-configuration of the CloudWatch agent, an SSM agent must be installed that installs the CloudWatch agent with the necessary configuration. Currently, there is no SSM agent inside VyOS AWS images, and I haven't heard anything about willingness to include it.
2. The amazon-cloudwatch-agent package has only one dependency, libc6. Therefore, it does not need the aws-cli to be configured or set up at all.
3. Granting access to the CloudWatch service from an EC2 instance is done by applying the corresponding IAM role to the instance. While it is possible to do this via manual credential input, it is an unwanted practice inside AWS.
4. The possible scenario of sending data to CloudWatch out of AWS is unique and requires another Phorge task, I think.

@unity when you need AWS credential , will they be automatically deployed from SSM or will we have to add those credentials in the virtual machine? ? shouldn't aws-cli be integrated?

I've created the PR https://github.com/vyos/vyos-documentation/pull/987 as a temporary explanation for users on how to preserve CloudWatch Agent configuration in a semi-automated way, using the SSM Parameter Store.

Notice. Initially this task was about monitoring scripts but they were deprecated. Then aws-cloudwatch-agent emerged.
aws-cloudwatch-agent was successfully added to vyos-build:equuleus. But cloudwatch configuration preservation between image updates is not.
This task was closed mistakenly prematurely thus should be reopen.

Requires some additional work
we need to preserve configuration between upgrade
alternatively, we need to investigate if default config can be used with VM role

PR for VyOS 1.3 https://github.com/vyos/vyos-build/pull/330

https://dev.packages.vyos.net/repositories/current/pool/main/a/amazon-cloudwatch-agent/amazon-cloudwatch-agent_1.247358.0b252413-1_amd64.deb
https://dev.packages.vyos.net/repositories/equuleus/pool/main/a/amazon-cloudwatch-agent/amazon-cloudwatch-agent_1.247358.0b252413-1_amd64.deb

Building from source always results in:

This works as expected

I'm still having an issue with using build-ami to create an AMI in us-gov-west-1.

All you need for ssh keys to work for AMI is to add cloud-init package in configure step:

build-ami is working for me if I remove disable-password-authentication from the config template and add in a password into the config template. I have come across another issue though. I was able to get it to work in us-east-1 and us-east-2, but I can't deploy into us-gov-west-1. First problem was it couldn't find a debian-jessie image but that was solved by changing the owner from 379101102735 to 256493402735. Now it's throwing an 401 when attempting to list all subnets. I'm guessing that the python code pulled from ansible is configured for a specific region or the cli command used in GovCloud is slightly different. Either way it's not working.

I wasn't aware that there was an aws target for the vyos-build scripts.

@spectre3500 Now that I think of it, did you build it with build-ami or the AWS target of the vyos-build scripts?

...oh, and remove "disable-password-authentication" from the SSH settings of course.

I wonder if this issue will ever stop re-occuring. Every time it happens, it's for some new reason. I think this time it may be related to ongoing work of @Unicron.

I'm also experiencing the same issue with vyos-1.2.0-rolling-201904190439. I was able to create the ami using the build-ami playbooks, but when launched I could not login using the keypair. Is there a fix for this or a workaround?

added the patch! thanks

I found an AMI I had built from 1.1.8 back on July 7th. I can create functional 1.1.8 instances from that, so it looks to be something unique to 1.2.0, but I can't say for sure because I don't have a working way to build 1.1.8 AMIs currently. The 1.1.8 playbooks rely on modules that have been removed from Ansible, so I would have to rewrite them or downgrade my ansible install.

Also tried 1.2.0-rolling-201812080337. My best guess is that its not copying the SSH key into the system properly to allow the vyos user to login, as the system responds, accepts the username, rejects the key then disconnects with no further auth method.

I tried the build with 1.2.0-rc9 and rc10 with the same results. The instance boots up without issue, but rejects any login attempts with the SSH key the instance was launched with. The error it gets back suggests its not configured for key or password login, or any other method for some reason.

I forgot to fetch commits for the latest build-ami version when submitted report.
Now I confirms that problem exists in the latest version with the last commit:

@UnicronNL can you explain right way to create 1.2 ami

This is great an very important feature for AWS since they introduced very cheap and advanced t3 instances.

Thank you!

@m.tremer added the patch, thanks... was under the impression cloud-init added the user as it is stated as default user, but clearly it does not.

Isn't that how Open Source is supposed to work? :)

Good idea, thanks! I've applied the patch and will push it shortly.

Okay, that is good to know. Unfortunately documentation is heavily outdated. However, I found a fix for this problem which I attached to this message as a patch.

build-ami is obsolete and never was intended for 1.2 but 1.1
therefore it will not start work and will be removed at some point in favor of aws target

Just to confirm, I tested this with RC8 and unfortunately, it still does not work.

In T1003#26043, @oliko wrote:

Same problem, but at the bare metal server with VyOS 1.2-rc7 from repo.

Same problem, but at the bare metal server with VyOS 1.2-rc7 from repo.

Thanks for your reply.

Do you also create the iso yourself or dowload it?
In 1.2 we will be using cloud-init and the ec2 init script was removed.

This is part of T792

VyOS 1.2 is currently missing the kernel module. However, enabling it and marking the AMI as "Supports ENA" is sufficient. ENA is running stable and fast in the stock Linux kernel for me.

https://github.com/vyos/vyos-vm-images

https://github.com/vyos/build-ami/pull/6

The AMI builds and boots now.