New EBS image refuses ec2-user key

[vinnielima]

Problem Description:

Once new EBS Volume is mounted as boot volume for ec2 instance, unable to login via ec2-user or any other user. Existing Private Key refused.

Expected Behavior:

Existing private key for ec2-user should be replicated to newly built LVM EBS volume

Actual Behavior:

Unable to login to instance with new LVM EBS volume

(Detailed) Steps to reproduce:

Perform the public network processes.
Swap boot EBS with LVM ebs, so that LVM EBS is new boot device (/dev/sda1)
Power on instance
Attempt to login via ec2-user with initial private key or any other user.

(Optional) Fix recommendation:

Ensure existing users and ec2-user keys are replicated on new EBS volume.

[ferricoxide]

I'm having a hard time discerning what the reported problem and/or desired end-state is?

[vinnielima]

Once the Lvm based EBS is built, and you launch an instance from it or attach it as root device, you can’t login.

Users defined on original build instance do not carry over.

Had to mount the LVM EBS volume/chroot to it so I could create new user or modify password for root (plus enable sshd root login) to be able to ssh into any instances based on the LVM EBS volume.

[ferricoxide]

Once the Lvm based EBS is built, and you launch an instance from it or attach it as root device, you can’t login.

You have to use the correct user to login. The project's default provisionoing-user is maintuser. You can override this at launch time via UserData. For example:

#cloud-config

system_info:
  default_user:
    name: ec2-user

Users defined on original build instance do not carry over.

That is by design.

Had to mount the LVM EBS volume/chroot to it so I could create new user or modify password for root (plus enable sshd root login) to be able to ssh into any instances based on the LVM EBS volume.

By design, the root account is configured to only be accessible by way of key-based login (see Line 34 of the NetSet.sh script). At launch-time, cloud-init takes the default_user's key and populates into root's ${HOME}/.ssh/authorized_keys file. Which is to say, once the instance has launched, you should be able to do a key-based login to either the root or provisioning-user's account.

Using SSH-based direct login to the root account is generally a Bad Idea™. That said, we enable it mostly for legacy reasons. We limit the login capability to key-only to mitigate some of the risk associated with allowing direct-login to the root account.

All of that said, if you run standard system hardening profiles on the launched instance (e.g., the CIS or STIG benchmarks), network-based login to the root account is typically wholly disabled.

[ferricoxide]

Closing due to lack of compelling evidence of flawed functionality.