SIFT AMI Default User Issue (with Fix)

[ekristen]

The current AMIs have a problem with the default user (ubuntu) not existing, but it not being set to sansforensics either properly.

To work around this simply add this to your user-data when using the AMI.

#cloud-config
system_info:
  default_user:
    name: sansforensics

Note: if this issue is closed, that means the LATEST AMI has been fixed to default the user to sansforensics.

[RobinUndermost]

This doesn't seem to work unfortunately. Tried with key pair authentication and without, no success. Using ami-0b9d5c33ff8f8ca7d (sift-2022-03-02-1717)

[aarislarsen]

This still appears to be broken, and the suggested workaround does not appear to work. Using ami-0c444654c3cb65700, resulting in Permission denied (publickey) when attempting to SSH with the sansforensics user.

[ekristen]

odd, it was working, but I can confirm it doesn't now. I'll do some debugging.

[mpilking]

This workaround worked for me. Should we put a note on the main README page?

[RobinUndermost]

Interesting. After seeing this message I just gave it another shot to test and it still didn't work for me.

The steps I followed

• Launch Instance
• Search for ami-0b9d5c33ff8f8ca7d (I'm using us-west-2)
• Select instance type t3.2xlarge
• Copy/paste from the first message in this thread, into Advanced Options -> User Data

Then trying to SSH to the system I get the same error

[RobinUndermost]

I did some more testing because I had a feeling that it had something to do with whitespace.

a) I stopped the instance I had created, then I modified the user data and used the base64 encoded string and checked the box "Input is already base64-encoded", started it again, and SSHed and it worked! I could login I2Nsb3VkLWNvbmZpZwpzeXN0ZW1faW5mbzoKICBkZWZhdWx0X3VzZXI6CiAgICBuYW1lOiBzYW5zZm9yZW5zaWNz

b) Just to double check, I made a second instance, copy-pasted from Github, couldn't log in, stopped the instance, modified the user data, used the base64 encoded string and checked the "already base64" box, restarted the instance, and could login!

c) I made a third instance, and I used the base64 encoded string with the "already base64" checkbox on the initial creation of the instance. It did not work!

So, my initial theory that maybe there was an issue in the whitespace seems incorrect.

However, here's where it gets weird. I stopped the instance, and started it again, and then I could login successfully. So it looks like, even if the instance is created with the user data set accurately, it always requires a stop/start to take effect.

I don't understand why, but I thought I'd share my findings. This workaround works, but requires a start/stop to take effect!

[mpilking]

Thanks for testing more and posting your results @RobinUndermost. We'll try to get it sorted, but at least we have a reasonably easy workaround for now.

[ekristen]

That helps me. I'll take a deeper loop.

[mpilking]

I just created an AWS SIFT instance again for the first time in a while. I used the User Data fix above and it worked fine. Maybe there are edge cases where it doesn't work, but it's been consistent for me. @ekristen will you put a note in the main README.md so people who install in AWS will know about this?

[ekristen]

This has been fixed and a whole new set of SIFT AMIs have been published.

Account ID: 469658012540
Name: sans-sift-workstation-server-20240214124249
Regions:
  - eu-west-1 -> ami-02b8801c5dd864319
  - ap-southeast-1 -> ami-0a89fcec3f0d654f9
  - us-west-1 -> ami-0443a8664211c05f0
  - us-east-2 -> ami-04d0b46b95f792b67
  - ap-northeast-3 -> ami-049c6d359a6b056cc
  - eu-north-1 -> ami-00c969795f1510155
  - ap-northeast-2 -> ami-0d87d93a9fa3793e2
  - ca-central-1 -> ami-075fc1cf4efb61867
  - eu-west-3 -> ami-073eaa4931bcd39eb
  - eu-west-2 -> ami-0c494a1b9f9e341b1
  - eu-central-1 -> ami-0a50e71994d4ec832
  - ap-southeast-2 -> ami-0a52aae3e9bb5ff98
  - us-west-2 -> ami-0a6077f47a38022b7
  - us-east-1 -> ami-033658932fa06b1e6
  - ap-northeast-1 -> ami-09176a630354099ad