attack_range

attack_range copied to clipboard

UNIX-based deployment script uses the private key to login and execute Ansible playbooks through --private-key ${var.aws.private_key_path}; however, the lack of single quotes (') to close the key up led to errors when using paths with spaces:

module.linux-server.aws_instance.linux_server[0] (local-exec): Executing: ["/bin/sh" "-c" "ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook -u ubuntu --private-key /Users/user/Desktop/Attack Range/attack_range/05907.key -i 'PUBLIC-IP,' linux_server.yml -e [REDACTED]

This caused the script to fail since it took the 'Range/attack_range/05907.key' as the playbook (due to the space in the folder name) and therefore it used the 'linux_server.yml ' as another parameter which of course is not valid:

module.linux-server.aws_instance.linux_server[0] (local-exec): ansible-playbook: error: unrecognized arguments: linux_server.yml

The attack_range.py build output:

│ Error: Invalid function argument │ │ on modules/kali-server/resources.tf line 39, in resource "aws_instance" "linux_server": │ 39: private_key = file(var.aws.private_key_path) │ ├──────────────── │ │ while calling file(path) │ │ var.aws.private_key_path is "/Users/user/Desktop/Attack Range/attack_range/05907.key" │ │ Invalid value for "path" parameter: no file exists at "/Users/user/Desktop/Attack Range/attack_range/05907.key"; this function works only with files that are distributed as part of the configuration source code, so if this file will be created by a │ resource in this configuration you must instead obtain this result from an attribute of that resource. ╵

To solve this simply quote the private key (and preferably do not use folder names with spaces).