- Newest
- Most votes
- Most comments
In spite of what every other bit of AWS documentation says about the User Data script only ever being run when the instance is created, you can actually force an ad-hoc invocation of a User Data script, the steps are here https://repost.aws/knowledge-center/execute-user-data-ec2
Follow the steps and amend the sample User Data and replace /bin/echo "Hello World" >> /tmp/testfile.txt with whatever the command is to open port 22 (or just disable the service and open up every port to get it back working) then it may be enable you to pick up where you left off.
Unfortunately, i can't see a way to gain access as the hosts firewall is now blocking your access via SSH. I am completely unfamiliar with NoMachine, so no idea if there is any way to leverage that access to some sort of a shell prompt.
Likely the simplest way would be to shut down the host. Detach the drive and attach it to another temporary host. Mount the drive and edit your firewall configuration to remove it, then reattach to the original machine and boot.
Best of luck Craig
im reviewing every option possible but thankyou so much Craig, good luck to you too and thank you for your time!!
Relevant content
- Accepted Answerasked a year ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
turns out directory /var/lib/cloud/scripts/per-boot/ is the directory that Cloud-Init uses and runs it in User Data upon first boot, and it`ll run any scripts after every boot!!
source.: https://repost.aws/knowledge-center/execute-user-data-ec2#CORbGO9TMvTVeC1g5nP3DMTA
p.s.: too scared to make the changes, already did the shell script #!/bin/bash
"
Disable UFW
ufw disable
Allow incoming SSH traffic on port 22
ufw allow 22
Reload UFW rules
ufw reload "
That script looks okay, did you try it and did it work? If it did work then please could you accept the answer, so that other people that come across the same problem later know that this is what to do.
If you're hesitant to try it then you could snapshot the current VM, create an AMI out of the snap, and use that to spin up a copy of your current EC2 that you can play with. Or even just provision a fresh EC2 from the Ubuntu AMI and make the same mistake so that it's unreachable, and then confirm you can rescue it.
#!/bin/bash sudo tee /var/lib/cloud/scripts/per-boot/firewall-fix.sh #!/bin/bash ufw disable ufw allow 22 ufw reload
sudo chmod +x /var/lib/cloud/scripts/per-boot/firewall-fix.sh
added these commands but didnt seem to do the trick or i didnt deploy it the proper way, do you think theres still hope in all this