PEM file is not able to validate and decrypt for login


We have been using Packer to create a Windows Golden AMI. We are able to launch an EC2 instance using this AMI, but we are unable to log in to the instance. This is because PEM is not able to decrypt the instance. We can only log in to the instance using the default password in the script.

Every time we launch an instance using the Golden AMI, we need a new key. I have attached the script below for your reference.

“variables”: {
“aws_access_key”: “xxxxxxxx”,
“aws_secret_key”: “xxxxxxxx”
“builders”: [
“type”: “amazon-ebs”,
“assume_role”: {
“role_arn”: “arn:aws:iam::7xxxxxxxxx:role/PackerRole”,
“session_name”: “Packer_Session”
“access_key”: “{{user aws_access_key}}”,
“secret_key”: “{{user aws_secret_key}}”,
“vpc_id”: “vpc-077xxxxxxxx”,
“subnet_id”: “subnet-05xxxxxxxxx”,
“security_group_id”: “sg-05xxxxxx”,
“associate_public_ip_address”: “false”,
“region”: “eu-central-1”,
“source_ami_filter”: {
“filters”: {
“virtualization-type”: “hvm”,
“name”: “Windows_Server-2022-English-Full-Base-*”,
“root-device-type”: “ebs”
“owners”: [
“most_recent”: “true”
“instance_type”: “t2.micro”,
“ami_name”: “windows-golden-ami-{{timestamp}}”,
“user_data_file”: “./user_data.txt”,
“communicator”: “winrm”,
“force_deregister”: “true”,
“winrm_username”: “Administrator”,
“winrm_use_ssl”: “true”,
“winrm_insecure”: “true”,
“iam_instance_profile”: “PackerRole”,
“ami_description”: “Windows Server 2022 Base Golden AMI”,
“tags”: {
“OS”: “Windows Server 2022”,
“Application”: “Golden AMI”
“provisioners”: [
“type”: “powershell”,
“inline”: [
“Enable-PSRemoting -Force”,
“New-NetFirewallRule -Name ‘ssh HTTPS’ -DisplayName ‘ssh HTTPS’ -Enabled True -Profile ‘Any’ -Action ‘Allow’ -Direction ‘Inbound’ -LocalPort 5986 -Protocol ‘TCP’”
“type”: “powershell”,
“inline”: [
“Write-Host ‘Running Sysprep…’”,
“& $env:SystemRoot\system32\Sysprep\Sysprep.exe /generalize /oobe /shutdown /quiet”
“post-processors”: [
“type”: “manifest”,
“output”: “packer-manifest.json”,
“strip_path”: true

user data powershell script


“winrm_username”: “Administrator”,

“winrm_password”: “SuperS3cr3t!!!”,

“winrm_insecure”: true,

“winrm_use_ssl”: true,

Create username and password

write-output “Running User Data Script”
write-host “(host) Running User Data Script”

Set-ExecutionPolicy Unrestricted -Scope LocalMachine -Force -ErrorAction Ignore

Don’t set this before Set-ExecutionPolicy as it throws an error

$ErrorActionPreference = “stop”

Remove HTTP listener

Remove-Item -Path WSMan:\Localhost\listener\listener* -Recurse

Create a self-signed certificate to let ssl work

$Cert = New-SelfSignedCertificate -CertstoreLocation Cert:\LocalMachine\My -DnsName “packer”
New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $Cert.Thumbprint -Force


write-output “Setting up WinRM”
write-host “(host) setting up WinRM”

cmd.exe /c winrm quickconfig -q
cmd.exe /c winrm set “winrm/config” ‘@{MaxTimeoutms=“1800000”}’
cmd.exe /c winrm set “winrm/config/winrs” ‘@{MaxMemoryPerShellMB=“1024”}’
cmd.exe /c winrm set “winrm/config/service” ‘@{AllowUnencrypted=“true”}’
cmd.exe /c winrm set “winrm/config/client” ‘@{AllowUnencrypted=“true”}’
cmd.exe /c winrm set “winrm/config/service/auth” ‘@{Basic=“true”}’
cmd.exe /c winrm set “winrm/config/client/auth” ‘@{Basic=“true”}’
cmd.exe /c winrm set “winrm/config/service/auth” ‘@{CredSSP=“true”}’
cmd.exe /c winrm set “winrm/config/listener?Address=*+Transport=HTTPS” “@{Port="5986”;Hostname="packer";CertificateThumbprint="$($Cert.Thumbprint)“}”
cmd.exe /c netsh advfirewall firewall set rule group=“remote administration” new enable=yes
cmd.exe /c netsh firewall add portopening TCP 5986 “Port 5986”
cmd.exe /c net stop winrm
cmd.exe /c sc config winrm start= auto
cmd.exe /c net start winrm

Thank you.

It seems like the core of the problem lies in the decryption and validation process for the login, which is a common snag point when working with AMIs, especially with custom ones.

Firstly, for Windows AMIs, AWS uses a key pair to encrypt the administrator password and you can use the private key of that pair to decrypt the password. This is slightly different from logging into Linux instances where you can use the key pair for SSH access directly. Since you’re able to log in with the default password, it sounds like the instance is set up correctly, but there’s an issue with how the key pair is being handled.