missing aws_secret_access_key causes quiet timeout

[huntertj]

when specifying an invalid aws_secret_access_key file the kitchen-ec2 driver continues trying to connect not recognizing the SSH::AuthenticationFailed error. Same quiet on any Authentication error I believe.

       Waiting for SSH service on 10.227.53.87:22, retrying in 3 seconds
D      [SSH] opening connection to cloud@10.227.53.87<{:user_known_hosts_file=>"/dev/null", :paranoid=>false, :port=>22, :compression=>"zlib", :compression_level=>6, :keepalive=>true, :keepalive_interval=>60, :timeout=>10, :keys_only=>true, :keys=>["c:/dev/local-preprod-keypair-does-not-exist.pem"], :user=>"cloud"}>
D      [SSH] connection failed (#<Net::SSH::AuthenticationFailed: Authentication failed for user cloud@10.227.53.87>)
       Waiting for SSH service on 10.227.53.87:22, retrying in 3 seconds

[tyler-ball]

@fnichol Is there a valid reason we're catching AuthenticationFailed and retrying on that? I thought that was the exception we got if SSH wasn't finished starting up...

[tyler-ball]

@huntertj I think you're talking about the aws_ssh_key_id config - the aws_secret_access_key is used to authenticate the API requests for creating and destroying the EC2 instance.

aws_ssh_key_id is a required field and I believe that AWS will reject the instance request if that key does not exist on the AWS side.

Your example seems to indicate that your transport ssh_key config either doesn't exist, is invalid or does not correspond to the key stored on the AWS side.

Can you validate that your aws_ssh_key_id config is correct and that you have the correct key stored on your side? You should be able to ssh -i C:\path\to\key cloud@10.227.53.87 when you have the correct keys.

Or were you only showing c:/dev/local-preprod-keypair-does-not-exist.pem as an example, and your real request is that you don't want to be retrying login when you have an invalid key?

[tyler-ball]

We also purposefully retry on the Net::SSH::AuthenticationFailed error from your debug log because sometimes the SSH service starts before the login key is written to the EC2 instance.

You can specify

transport:
  max_wait_until_ready: 60 # default is 600

In your .kitchen.yml to make that timeout less. But if we fix your key issue logins should start working.

[huntertj]

I was incorrect in my original description, I'm talking about if I make a mistake and set ssh_key to something that does not exist kitchen-ec2 doesn't tell me its missing and I just get this on the screen. It would be nice to see somewhere that my file c:/dev/local-preprod-keypair-does-not-exist.pem

Waiting for SSH service on 10.227.53.87:22, retrying in 3 seconds
Waiting for SSH service on 10.227.53.87:22, retrying in 3 seconds

transport:
  ssh_key: c:/dev/local-preprod-keypair-does-not-exist.pem

[tyler-ball]

@huntertj Okay, I understand now - I refiled this issue under Test Kitchen (which is where the base SSH transport is configured) because I think the fix will occur there. Thanks for the report!