New to Ansible: FAILED Private key file encrypted

Hi,
Its my first hour with Ansible, and from what I have read on the
website I'm pretty psyched about it. I'm running on OS X 10.7. I
managing a new network of about 150 CentOS 5.7-6 hosts, and they need
a lot of work. I have worked out a couple of Python issues on my
machine and can run the ansible application without (I think) issue.
We have a weird config on the servers, this isn't something I have
done. The person who administered these machines in the past setup a
fake kind of sudo, because they reaally didn't understand securing
Linux. Essentially they changed all the permissions on binarys on the
box. In the interest of full disclosure I mention in case it would
cause the problem I'm having. I would like to use ansible to start to
secure these machines and deploy config files for sshd etc.

Here is the output from where I'm stuck. I'm running Python 2.7, is that okay?

sheepchase:paramiko-1.7.7.1 jmarcus$ ssh-agent bash

bash-3.2$ ssh-add ~/.ssh/id_dsa
Enter passphrase for /Users/jmarcus/.ssh/id_dsa:
Identity added: /Users/jmarcus/.ssh/id_dsa (/Users/jmarcus/.ssh/id_dsa)

bash-3.2$ ansible all -m ping
10.54.244.179 | FAILED => FAILED: Private key file is encrypted
10.54.244.177 | FAILED => FAILED: Private key file is encrypted
10.54.244.178 | FAILED => FAILED: Private key file is encrypted
10.54.244.143 | FAILED => FAILED: Private key file is encrypted
10.54.244.157 | FAILED => FAILED: Private key file is encrypted
10.54.244.155 | FAILED => FAILED: Private key file is encrypted
bash-3.2$ ansible all -a "/bin/echo hello"
10.54.244.179 | FAILED => FAILED: Private key file is encrypted
10.54.244.143 | FAILED => FAILED: Private key file is encrypted
10.54.244.177 | FAILED => FAILED: Private key file is encrypted
10.54.244.157 | FAILED => FAILED: Private key file is encrypted
10.54.244.178 | FAILED => FAILED: Private key file is encrypted
10.54.244.155 | FAILED => FAILED: Private key file is encrypted

Is this issue a red herring because of the permissions issue or is
there really a private key issue?

Thanks,
James

Hi,
Its my first hour with Ansible, and from what I have read on the
website I’m pretty psyched about it. I’m running on OS X 10.7. I
managing a new network of about 150 CentOS 5.7-6 hosts, and they need
a lot of work. I have worked out a couple of Python issues on my
machine and can run the ansible application without (I think) issue.
We have a weird config on the servers, this isn’t something I have
done. The person who administered these machines in the past setup a
fake kind of sudo, because they reaally didn’t understand securing
Linux. Essentially they changed all the permissions on binarys on the
box. In the interest of full disclosure I mention in case it would
cause the problem I’m having. I would like to use ansible to start to
secure these machines and deploy config files for sshd etc.

“a fake kind of sudo” == setuid binaries?

Anyway, it looks like you are having problems on your OS X box, not remotely.

Some folks have worked on getting OS X to work on clients, though I personally don’t use it there.

Are you using the latest Ansible from the devel branch? If not, switch to that, as that’s what we’ll be able to debug easiest.

Here is the output from where I’m stuck. I’m running Python 2.7, is that okay?

I would think so, yes.

sheepchase:paramiko-1.7.7.1 jmarcus$ ssh-agent bash

bash-3.2$ ssh-add ~/.ssh/id_dsa
Enter passphrase for /Users/jmarcus/.ssh/id_dsa:
Identity added: /Users/jmarcus/.ssh/id_dsa (/Users/jmarcus/.ssh/id_dsa)

ok, so ssh agent ran fine here, it seems

bash-3.2$ ansible all -m ping
10.54.244.179 | FAILED => FAILED: Private key file is encrypted
10.54.244.177 | FAILED => FAILED: Private key file is encrypted
10.54.244.178 | FAILED => FAILED: Private key file is encrypted
10.54.244.143 | FAILED => FAILED: Private key file is encrypted
10.54.244.157 | FAILED => FAILED: Private key file is encrypted
10.54.244.155 | FAILED => FAILED: Private key file is encrypted
bash-3.2$ ansible all -a “/bin/echo hello”
10.54.244.179 | FAILED => FAILED: Private key file is encrypted
10.54.244.143 | FAILED => FAILED: Private key file is encrypted
10.54.244.177 | FAILED => FAILED: Private key file is encrypted
10.54.244.157 | FAILED => FAILED: Private key file is encrypted
10.54.244.178 | FAILED => FAILED: Private key file is encrypted
10.54.244.155 | FAILED => FAILED: Private key file is encrypted

Ansible works quite well with ssh-agent AFAIK, so that’s new to me.

Do you have permissions on the key file? I know you should, but I’m wondering if the error message is just confused.

paramiko has a utils.log_to_file function we could try if that wasn’t it.

add paramiko.utils.log_to_file(“paramiko.log”,10) towards the top of the connection.py

Worst case you can use --ask-pass but it would be nice to avoid it.

You may also want to try from a CentOS VM or something for kicks.

Anybody else have ideas?

I just read this post: http://groups.google.com/group/ansible-project/browse_thread/thread/c49b37f084905a01
and I have gotten further, its funny that Google returns queries
about this post but not Google groups.

James

Gotten further how? that was a long thread :slight_smile:

Just specifying the user (-u) did the trick. Thanks.

"a fake kind of sudo" == setuid binaries? Yes... I think, I'm not sure
I have figured it out completely, its really annoying.

As for version, I used "Running from Checkout" and then "Make install"

Thanks for the response. I'm looking forward to using ansible

Thanks,
James

I was confused by this as well. It seems many people expect Ansible to connect as the current user by default. Perhaps we could revisit this decision? It’s pretty easy to sudo bash if you want to run as root, and that’s a pretty normal thing to do before sysadmin-type tasks anyway. If not, at least we could give a better diagnostic error message, like “Private key file for is encrypted.”

In many data centers, the current user most likely won’t even be available on the box. Or OS X laptop, where the names are made up by whoever installed them.

I’m not going to change existing behavior on that one, or we’ll be plagued with just as many questions, if not more, about the opposite.

Ansible is not /usr/bin/ssh – It uses ssh protocol.

That particular error message is from Paramiko. It may be able to be caught and intercepted to change the error, yes. Patch would be accepted.

–Michael