cisagov / skeleton-packer

A skeleton project for quickly getting a new cisagov packer project started.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

"admin" user exists and maybe shouldn't

dav3r opened this issue · comments

commented

After a fresh AMI is built, there is an "admin" user with an authorized SSH key for packer. Let's clean this up!

Verified this is still the case:

root@vpn:~# getent passwd admin
admin:x:1000:1000:Debian:/home/admin:/bin/bash

See:

We also want to clean up 90-cloud-init-users:

root@vpn:/etc/sudoers.d# cat 90-cloud-init-users 
# Created by cloud-init v. 18.3 on Thu, 17 Oct 2019 17:12:30 +0000

# User rules for admin
admin ALL=(ALL) NOPASSWD:ALL

# User rules for admin
admin ALL=(ALL) NOPASSWD:ALL

So it looks like the shell provisioner removed the admin user but upon booting the AMI it is still there, as well as /etc/sudoers.d/90-cloud-init-users. Did the amazon amazon-ebs builder re-create them?

https://github.com/cisagov/skeleton-packer/commit/882e81ee6c28f079b068791167ea774953598ef0/checks?check_suite_id=280041042#step:10:129

Also, the authorized_keys files in ~root and ~admin haven't been cleaned up. Docs seem to show that they should have been: https://www.packer.io/docs/builders/amazon-ebs.html#ssh_clear_authorized_keys

Adding ssh_clear_authorized_keys did confirm the user was deleted by the shell provisioner.

But upon logging into the system we see the admin user is there. But ~admin/.ssh/authorized_keys was empty. ~root/.ssh/authorized_keys still has a key.
/etc/sudoers.d/90-cloud-init-users still exists as well.

Interestingly, the admin user has moved from uid 1000 to 1006:

admin@ip-172-31-19-90:~$ id
uid=1006(admin) gid=1007(admin) groups=1007(admin),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),110(netdev)

So it looks like the admin user was re-created after it was deleted, but before the system shutdown.

See: https://github.com/cisagov/skeleton-packer/commit/15c30c0c691b88187ad330b2ddc53fd916a63943/checks?check_suite_id=280107656#step:10:129

2019-10-24T18:04:28Z: ==> amazon-ebs: Provisioning with shell script: /tmp/packer-shell326890403
129
2019-10-24T18:04:29Z: ==> amazon-ebs: userdel: user admin is currently used by process 566
130
2019-10-24T18:04:29Z: ==> amazon-ebs: userdel: admin mail spool (/var/mail/admin) not found
131
2019-10-24T18:04:29Z: ==> amazon-ebs: Trying to remove ephemeral keys from authorized_keys files
132
2019-10-24T18:04:29Z: ==> amazon-ebs: Could not chdir to home directory /home/admin: No such file or directory
133
2019-10-24T18:04:29Z: ==> amazon-ebs: sed: can't read /home/admin/.ssh/authorized_keys: No such file or directory
134
2019-10-24T18:04:29Z: ==> amazon-ebs: rm: cannot remove '/home/admin/.ssh/authorized_keys.bak': No such file or directory
135
2019-10-24T18:04:29Z: ==> amazon-ebs: Could not chdir to home directory /home/admin: No such file or directory
136
2019-10-24T18:04:29Z: ==> amazon-ebs: sudo: you do not exist in the passwd database
137
2019-10-24T18:04:29Z: ==> amazon-ebs: sudo: you do not exist in the passwd database
138
2019-10-24T18:04:29Z: ==> amazon-ebs: Stopping the source instance...
139
2019-10-24T18:04:29Z:     amazon-ebs: Stopping instance
140
2```

Confirmed. The admin user is created by cloud-init in the Debian AMI. It is the "default-user"

More specifically it is created by the file: /etc/cloud/cloud.cfg.d/01_debian_cloud.cfg

If we delete this file, the user will not be recreated! (on reboot).

We got a debian user in its place. Crikey!

Edit: /etc/cloud/cloud.ymland comment out the line like below.

users: []

Then run to test:

rm /var/lib/cloud/instance/sem/config_users_groups
userdel -r -f admin
rm /etc/sudoers.d/90-cloud-init-users
cloud-init single --name users-groups --report

Success!

Added a sed command to the shell provisioner to do this replacement. This could become an ansible role.

sed -i '/^users:/ {N; s/users:.*/users: []/g}' /etc/cloud/cloud.cfg

Closed by PR #20