mirror of
https://github.com/opentffoundation/opentf.git
synced 2025-12-19 17:59:05 -05:00
8a9f1587d2
The "certificate" argument in a provisioner connection block is only used when using an SSH certificate authority, but because it uses the same authorized_keys syntax that could be used to represent a public key on the remote server it's perhaps tempting to think that it's necessary to specify a plain public key here when attempting traditional keypair-based authentication. The configuration handling logic previously assumed incorrectly that the result of parsing that string would always be *ssh.Certificate if parsing succeeded at all, but the upstream library doesn't have a certificate-specific parsing function and so we're using the more general parser for the authorized_keys format and so the result could potentially be of one of the many supported public key types, which would previously have caused a type assertion panic. Now we'll handle this as a normal error. The fact that communicators still use error values directly rather than diagnostics means that we need to be more terse than I would've liked to have been in this message, since the reader of the message might not be an SSH authentication expert, but the provisioner/communicator functionality long predates our modern idea of diagnostics so I tried for a compromise here of mentioning that it's okay to omit the certificate argument when you aren't trying to use a CA in the hope that this is sufficient hint for someone who isn't yet aware of the differences between these two different authentication methods. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>