Diagnosing Packer Builder Communication Failures: SSH/WinRM Connectivity Issues

Problem: Packer stalls waiting for machine to become communicable

When a Packer build stops at the message “Waiting for machine to become communicable” or a provisioner times out, the builder cannot reach the guest OS over SSH or WinRM.

Recognizable condition

• Build output shows “Waiting for machine to become communicable…” for longer than the configured timeout.
• Provisioner steps fail with connection refused or authentication errors.

Common causes

Condition	Likely cause
SSH communicator configured but host points to wrong IP	Instance received a different address (DHCP change, NAT)
WinRM port 5985 blocked	Security group or firewall denies inbound TCP 5985
Guest OS lacks SSH server or WinRM service	Image not installed with openssh-server or Windows Management Framework
Builder communicator type mismatched to platform	Using ssh communicator for a Windows builder or winrm for Linux

Ordered checks

1. Verify communicator settings
   1. Open the Packer template and locate the communicator block.
   2. Confirm type is either ssh or winrm matching the guest OS.
   3. Check host, port, username, and password or private_key_file values.
   4. Example snippet for an SSH builder:

   {
     "type": "amazon-ebs",
     "communicator": {
       "type": "ssh",
       "host": "{{ user `instance_ip` }}",
       "port": 22,
       "username": "ubuntu",
       "private_key_file": "keys/id_rsa"
     }
   }
   

2. Confirm instance boot and network address
   1. Watch the builder console output for the line that prints the instance’s IP address (e.g., “==> amazon-ebs: Instance ID: i-0abcd1234efgh5678”).
   2. If the IP is not shown, retrieve it from the cloud provider console or via virsh domifaddr for local libvirt/QEMU builds.
   3. Compare that address to the host value used in the communicator.
3. Test reachability from the build host
   1. From the machine running Packer, run a basic connectivity test:
      • SSH: ssh -i keys/id_rsa -p 22 ubuntu@<IP> echo ok
      • WinRM: winrm quickconfig -transport:http then winrm id -r:http://<IP>:5985/wsman -u:Administrator -p:<password>
   2. If the test fails, run a port scan: nc -zv <IP> 22 or nc -zv <IP> 5985.
   3. Check inbound rules: ensure the security group, network ACL, or host firewall allows traffic on the communicator port from the builder’s IP.

Fixes tied to findings

• If the communicator type is wrong, change type to match the guest OS and adjust username/auth accordingly.
• If the host IP is outdated, either:
  • Use a dynamic lookup (e.g., {{ .Build.Name }} or cloud‑specific data source) to pull the address at runtime,
  • Configure the builder to use a static IP via DHCP reservation or cloud‑init network config.
• If the port is blocked, add an inbound rule allowing TCP 22 (SSH) or TCP 5985/5986 (WinRM) from the builder’s subnet.
• If the guest OS lacks the service, add a provisioner step to install openssh-server (Debian/Ubuntu: apt-get update && apt-get install -y openssh-server) or enable WinRM (winrm quickconfig) before the communicator is used.

Verification

After applying a fix, re‑run the Packer build and watch for the success messages:

• SSH builds: “==> amazon-ebs: SSH able to connect: …”
• WinRM builds: “==> amazon-ebs: WinRM successful: …”

If the build proceeds past the communicator stage and into provisioners, the connectivity issue is resolved.

Escalation criteria

Escalate to infrastructure or OS‑owner teams when:

• Network reachability tests succeed but authentication still fails after verifying credentials and key files.
• The guest OS boots but never starts the SSH/WinRM service despite correct installation steps.
• Repeated builds fail across multiple builder types (e.g., both AWS and VMware) suggesting a systemic template or credential management problem.