Knife ec2 create fails SSH auth

Chef Infra (archive)
1

Hello,

I’m trying to create an EC2 instance via knife ec2 create. The command I’m using is:

knife ec2 server create -Z sa-east-1b -N inst_name -f c1.medium -I ami-c819c0d5 -r “role[role1],role[role2]” -g sg-XXXXXXXX -S ssh_key_name -x ubuntu -i ~/.ssh/ssh_key_name.pem

The AMI is the base Ubuntu AMI 12.04 for the region.

When I fire up that command, the instance is loaded up, but it fails to authenticate and asks for a password. If I try to SSH directly from the terminal, it works.

I checked /var/log/auth.log and found this:

Jan 18 11:39:09 ip-10-252-130-183 sshd[733]: Did not receive identification string from XXX.XXX.XXX.XXX
Jan 18 11:39:09 ip-10-252-130-183 sshd[1096]: reverse mapping checking getaddrinfo for XXX.XXX.XXX.XXX.static.gvt.net.br [XXX.XXX.XXX.XXX] failed - POSSIBLE BREAK-IN ATTEMPT!
Jan 18 11:39:09 ip-10-252-130-183 sshd[1096]: Connection closed by XXX.XXX.XXX.XXX [preauth]

What’s going on, and why does it work using SSH directly but not via knife-ec2?

Thanks,

  • cassiano
2

Never mind. Fixing the key path on knife.rb solved it.

I remember knife having a bug where the CLI arguments did not take precedence over knife.rb when they should, but I (barely) recall seeing e-mails about that being fixed, am I wrong?

I'm using knife 10.18.0

Cheers,

  • cassiano

On Friday, January 18, 2013 at 09:59, Cassiano Leal wrote:

Hello,

I'm trying to create an EC2 instance via knife ec2 create. The command I'm using is:

knife ec2 server create -Z sa-east-1b -N inst_name -f c1.medium -I ami-c819c0d5 -r "role[role1],role[role2]" -g sg-XXXXXXXX -S ssh_key_name -x ubuntu -i ~/.ssh/ssh_key_name.pem

The AMI is the base Ubuntu AMI 12.04 for the region.

When I fire up that command, the instance is loaded up, but it fails to authenticate and asks for a password. If I try to SSH directly from the terminal, it works.

I checked /var/log/auth.log and found this:

Jan 18 11:39:09 ip-10-252-130-183 sshd[733]: Did not receive identification string from XXX.XXX.XXX.XXX
Jan 18 11:39:09 ip-10-252-130-183 sshd[1096]: reverse mapping checking getaddrinfo for XXX.XXX.XXX.XXX.static.gvt.net.br [XXX.XXX.XXX.XXX] failed - POSSIBLE BREAK-IN ATTEMPT!
Jan 18 11:39:09 ip-10-252-130-183 sshd[1096]: Connection closed by XXX.XXX.XXX.XXX [preauth]

What's going on, and why does it work using SSH directly but not via knife-ec2?

Thanks,

  • cassiano
3

On Friday, January 18, 2013 at 4:56 AM, Cassiano Leal wrote:

Never mind. Fixing the key path on knife.rb solved it.

I remember knife having a bug where the CLI arguments did not take precedence over knife.rb when they should, but I (barely) recall seeing e-mails about that being fixed, am I wrong?

I'm using knife 10.18.0

Cheers,

  • cassiano

In Chef 10.x, it's sort-of been a game of whack-a-mole with getting the precedence correct. For Chef 11, we've recently committed a fix where knife will handle precedence in the correct way automatically:

http://tickets.opscode.com/browse/CHEF-3497

This builds on a recent change we shipped for mixlib-cli:

There will probably be some follow-up changes in Chef 11 to remove workarounds and such.

For knife plugin authors, there is some discussion about how these changes impact knife plugin development here:

http://wiki.opscode.com/display/chef/Breaking+Changes+in+Chef+11#BreakingChangesinChef11-KnifeConfigurationParameterChanges

--
Daniel DeLeo

4

Cool. So for now I'll just have to make sure that knife.rb is properly configured before issuing a command.

Thanks,

  • cassiano

On Friday, January 18, 2013 at 13:22, Daniel DeLeo wrote:

On Friday, January 18, 2013 at 4:56 AM, Cassiano Leal wrote:

Never mind. Fixing the key path on knife.rb solved it.

I remember knife having a bug where the CLI arguments did not take precedence over knife.rb when they should, but I (barely) recall seeing e-mails about that being fixed, am I wrong?

I'm using knife 10.18.0

Cheers,

  • cassiano

In Chef 10.x, it's sort-of been a game of whack-a-mole with getting the precedence correct. For Chef 11, we've recently committed a fix where knife will handle precedence in the correct way automatically:

http://tickets.opscode.com/browse/CHEF-3497
[CHEF-3497] Fix knife configure order, apply any relevant Chef::Config[:knife] settings by danielsdeleo · Pull Request #583 · chef/chef · GitHub

This builds on a recent change we shipped for mixlib-cli:
[CHEF-3497] Optionally Separate Default Values from User-Supplied Values by danielsdeleo · Pull Request #11 · chef/mixlib-cli · GitHub

There will probably be some follow-up changes in Chef 11 to remove workarounds and such.

For knife plugin authors, there is some discussion about how these changes impact knife plugin development here:

http://wiki.opscode.com/display/chef/Breaking+Changes+in+Chef+11#BreakingChangesinChef11-KnifeConfigurationParameterChanges

--
Daniel DeLeo