You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please vote on this issue by adding a 馃憤 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Overview of the Issue
When using the ssh-communicator to provision a FIPS-enabled target, the SSH communicator hangs and eventually times out. If one logs into the target systems and reviews the system logs, one finds errors about:
Apr 9 18:52:43 ip-172-31-47-57 sshd[1460]: input_kex_gen_init: Key exchange type c25519 is not allowed in FIPS mode [preauth]
Apr 9 18:52:43 ip-172-31-47-57 sshd[1460]: ssh_dispatch_run_fatal: Connection from 217.114.38.123 port 51540: invalid argument [preauth]
In /var/log/secure.
The problem may be worked around by using the ssh_key_exchange_algorithms parameter to specify an algorithm-list that omits curve25519-sha256@libssh.org. However, this seems like it shouldn't be necessary. Since the documentation indicates that there's already a list of algorithms to try, Packer notionally should attempt to iteratively renegotiate the connection to use one of the other ones in the list. This seems to not be the actual behavior.
Would request that any of:
Packer attempts to iterate the default list to negotiate its connection
Packer doesn't attempt to use weak KEX algorithms
Packer's default algorithm list is ordered by algorithm, strongest to weakest
Be implemented.
While I did notice there were other communicator issues around FIPS-enabled systems, the nature/focus of those tickets seemed to be different.
Reproduction Steps
Steps to reproduce this issue
Run a packer-job that attempts to provision a FIPS-enabled target
Wait for Packer to hang while attempting to connect with the SSH communicator
Login to the target and view the /var/log/secure file: messages similar to the above will be found
Packer version
1.8.7 (yes, I know that this is elderly but a few of our older job-defs won't work with newer versions: we're planning to remove them when Red Hat deprecates RHEL 7 in early summer)
Simplified Packer Template
If the file is longer than a few dozen lines, please include the URL to the gist of the log or use the Github detailed
format
instead of posting it directly in the issue.
Operating system and Environment details
OS, Architecture, and any other information you can provide about the
environment.
Packer-executor host(s):
Amazon CodeBuild
Windows 11
Oracle Linux 9
OSX 14.4
Packer target(s):
Red Hat 9 (FIPS-enabled)
Oracle Linux 9 (FIPS-enabled)
CentOS Stream 9 (FIPS-enabled)
Log Fragments and crash.log files
2024-04-09T07:00:34.812-07:00 amazon-ebs.minimal-ol-9-hvm: + pkill --signal HUP sshd
2024-04-09T07:15:36.926-07:00 ==> amazon-ebs.minimal-ol-9-hvm: Provisioning step had errors: Running the cleanup provisioner, if present...
[鈥lided鈥
2024-04-09T07:55:35.990-07:00 Build 'amazon-ebs.minimal-centos-9stream-hvm' errored after 1 hour 1 minute: Timeout waiting for SSH.
Community Note
Overview of the Issue
When using the ssh-communicator to provision a FIPS-enabled target, the SSH communicator hangs and eventually times out. If one logs into the target systems and reviews the system logs, one finds errors about:
In
/var/log/secure
.The problem may be worked around by using the
ssh_key_exchange_algorithms
parameter to specify an algorithm-list that omitscurve25519-sha256@libssh.org
. However, this seems like it shouldn't be necessary. Since the documentation indicates that there's already a list of algorithms to try, Packer notionally should attempt to iteratively renegotiate the connection to use one of the other ones in the list. This seems to not be the actual behavior.Would request that any of:
Be implemented.
While I did notice there were other communicator issues around FIPS-enabled systems, the nature/focus of those tickets seemed to be different.
Reproduction Steps
Steps to reproduce this issue
/var/log/secure
file: messages similar to the above will be foundPacker version
1.8.7 (yes, I know that this is elderly but a few of our older job-defs won't work with newer versions: we're planning to remove them when Red Hat deprecates RHEL 7 in early summer)
Simplified Packer Template
If the file is longer than a few dozen lines, please include the URL to the
gist of the log or use the Github detailed
format
instead of posting it directly in the issue.
Operating system and Environment details
OS, Architecture, and any other information you can provide about the
environment.
Packer-executor host(s):
Packer target(s):
Log Fragments and crash.log files
Cc'ing: @lorengordon & @eemperor
The text was updated successfully, but these errors were encountered: