AWS adds an SSH key on every EC2 instance creation, either by adding a new key-pair or using the existing one based on the user’s choice. This gets a bit annoying while distributing a sealed (content-protected) AMI. Any user who has access to this AMI for deployment could create an instance by adding their key, thus gets access to the protected content residing inside the instance.
How EC2 instance gets user’s SSH key?
During the instance creation, a systemd service named cloud-init gets invoked by multi-user.target. This service appends user-input SSH key into ~/.ssh/allowed_keys.
Files responsible for this service are cloud-init.service, cloud-init-local.service, cloud-config.service & cloud-final.service, which can be located under /etc/systemd/system/cloud-init.target/.
Prevention method - systemd for the rescue!
The easiest way to fix this is by removing user’s SSH key as soon as the instance boot up, instead override allowed_keys with owner’s key. This can be performed by writing a custom systemd service.
(If you are using tools such as Packer to build AMI, this can be included in provisioning scripts.)
STEP 1: Script to override allowed_keys
|
|
STEP 2: Service to execute the above script
|
|
Typeisoneshotbecause the service should just execute an action without keeping active processes.- This
customsshis executed bycloud-init.targetas soon ascloud-final.serviceis completed. - After the
allowed_keysoverride,sshd(SSH Daemon) restart is also required.
STEP 3: Enabling the service
$ systemctl enable customssh.service
Created symlink from /etc/systemd/system/cloud-init.target.wants/customssh.service to /etc/systemd/system/customssh.service.
enable will hook the specified unit into relevant places, so that it will automatically start on boot.
Check status:
$ systemctl status customssh.service
That’s it. Our customssh service would be executed whenever an instance is created from the AMI. This always overrides with owner’s SSH public key, thus removes any key auto added by AWS.