Cannot SSH to builder machine using ssh_private_key_file

[dtan4]

What

packer-builder-sakuracloud never use ssh_private_key_file to execute SSH or SCP command (shell and file provisioners). It always use temporary SSH keypair even if ssh_private_key_file is specified.

Version

packer-builder-sakuracloud 0.2.2

Packer log

Around waiting SSH becomes available

current

``` ==> sakuracloud-is1a: Waiting for SSH to become available... 2018/11/20 22:02:49 packer-builder-sakuracloud: 2018/11/20 22:02:49 [INFO] Waiting for SSH, up to timeout: 5m0s 2018/11/20 22:02:52 packer-builder-sakuracloud: 2018/11/20 22:02:52 [DEBUG] TCP connection to SSH ip/port failed: dial tcp xxx:22: connect: connection refused 2018/11/20 22:02:58 packer-builder-sakuracloud: 2018/11/20 22:02:58 [DEBUG] TCP connection to SSH ip/port failed: dial tcp xxx:22: connect: connection refused 2018/11/20 22:03:03 packer-builder-sakuracloud: 2018/11/20 22:03:03 [INFO] Attempting SSH connection... 2018/11/20 22:03:03 packer-builder-sakuracloud: 2018/11/20 22:03:03 [DEBUG] reconnecting to TCP connection for SSH 2018/11/20 22:03:03 packer-builder-sakuracloud: 2018/11/20 22:03:03 [DEBUG] handshaking with SSH 2018/11/20 22:03:03 packer-builder-sakuracloud: 2018/11/20 22:03:03 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain 2018/11/20 22:03:03 packer-builder-sakuracloud: 2018/11/20 22:03:03 [DEBUG] Detected authentication error. Increasing handshake attempts. ```

expected

``` ==> sakuracloud-is1a: Waiting for SSH to become available... 2018/11/20 21:38:09 packer-builder-sakuracloud: 2018/11/20 21:38:09 [DEBUG] TCP connection to SSH ip/port failed: dial tcp xxx:22: connect: connection refused 2018/11/20 21:38:14 packer-builder-sakuracloud: 2018/11/20 21:38:14 [DEBUG] TCP connection to SSH ip/port failed: dial tcp xxx:22: connect: connection refused 2018/11/20 21:38:19 packer-builder-sakuracloud: 2018/11/20 21:38:19 [INFO] Attempting SSH connection... 2018/11/20 21:38:19 packer-builder-sakuracloud: 2018/11/20 21:38:19 [DEBUG] reconnecting to TCP connection for SSH 2018/11/20 21:38:19 packer-builder-sakuracloud: 2018/11/20 21:38:19 [DEBUG] handshaking with SSH 2018/11/20 21:38:19 packer-builder-sakuracloud: 2018/11/20 21:38:19 [DEBUG] handshake complete! 2018/11/20 21:38:19 packer-builder-sakuracloud: 2018/11/20 21:38:19 [DEBUG] Opening new ssh session 2018/11/20 21:38:19 packer-builder-sakuracloud: 2018/11/20 21:38:19 [INFO] agent forwarding enabled ==> sakuracloud-is1a: Connected to SSH! ```

Suggested solution

I made a patch on my local environment, and it works well.

diff --git a/sakuracloud/builder.go b/sakuracloud/builder.go
index 526ee69..9191edc 100644
--- a/sakuracloud/builder.go
+++ b/sakuracloud/builder.go
@@ -72,7 +72,7 @@ func (b *Builder) Run(ui packer.Ui, hook packer.Hook, cache packer.Cache) (packe
        communicateStep = &communicator.StepConnectSSH{
            Config:    &b.config.Comm,
            Host:      commHost,
-           SSHConfig: sshConfig,
+           SSHConfig: b.config.Comm.SSHConfigFunc(),
        }
    }

This change follows the preset provider implementations. SSHConfigFunc reads ssh_private_key_file and store it for SSH login (ref). Instead, sshConfig in the current implementation stores temporary SSH key only.

However, this patch discards current sshConfig() implementation as you can see, so I think this change will break backward compatibility.

How about this?

Why

I'd like to use prepared SSH keypair instead of a temporary one. Currently, temporary keypair is provisioned in the machine default user (Container Linux: core). I'd like to use the another user instead.

[yamamoto-febc]

Hi @dtan4, Thank you for report and suggestion!

I inspected the suggested SSHConfigFunc() func. I think we can replace the existing sshConfig method to that. We want to replace, but we don't want to do the breaking changes.

So for introducing this suggestion with keeping backward compatibility, I think that is better to do as follows:

• if specified ssh_private_key_file, we use it.
• else, we generate temporary key(file) and store it to ssh_private_key_file

and

• if user desired to register public-key to server via SakuraCloud API, we generate public-key from ssh_private_key_file and register it. (This is necessary to keep backward compatibility.)

• To make possible to toggle to register public-key via SakuraCloud API, we add register_public_key config to sakuracloud builder. (default: true)

• Finally, we replace existing sshConfig method.

What do you think about this? If there is no problem, I will implement this.

[dtan4]

Agree to your direction. Looks good!

[yamamoto-febc]

I merged #30 to fix this issue. The spec were a bit changed from my previous comment. For detail, please see #30.

[dtan4]

Sorry for the late reply 🙇 The builder v0.3.0 works well with our template! We can build with the custom user and the custom SSH private key.

Thank you for your quick fix ❗️