Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packer SSH Communicator Fails to Iterate Default KEX-algo list #12917

Open
ferricoxide opened this issue Apr 12, 2024 · 0 comments
Open

Packer SSH Communicator Fails to Iterate Default KEX-algo list #12917

ferricoxide opened this issue Apr 12, 2024 · 0 comments

Comments

@ferricoxide
Copy link

Community Note

  • 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

  1. Run a packer-job that attempts to provision a FIPS-enabled target
  2. Wait for Packer to hang while attempting to connect with the SSH communicator
  3. 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.

Cc'ing: @lorengordon & @eemperor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants