Sudoer password to set up remote server

After ansible-playbook server.yml -e env=staging --ask-become-pass I have this error:

TASK [setup] *******************************************************************
fatal: []: FAILED! => {"failed": true, "msg": "ERROR! Incorrect sudo password"}

Without --ask-become-pass the error is different:

TASK [setup] *******************************************************************
fatal: []: FAILED! => {"changed": false, "failed": true, "module_stderr": "", "module_stdout": "sudo: a password is required\r\n", "msg": "MODULE FAILURE", "parsed": false}


  • I have set up admin_user as “aitor” in group_vars/all/users.yml
  • I have set up my public key at ~/.ssh/
  • Also I have the same public key at
  • I can test my keys doing ssh aitor@ (connecting without ask password. It works)

I read caerfully the SSH docs and I don’t undestand why my admin_user, with his public key defined, can not connect with remote server from ansible. I know I am asking too much lately. Sorry about that, I’m doing my best :sweat:

My entire group_vars/all/users.yml file is:

admin_user: aitor

# Also define sudoer_passwords in group_vars/<environment>/main.yml
  - name: "{{ web_user }}"
      - "{{ web_group }}"
      - "{{ lookup('file', '~/.ssh/') }}"
      # -
  - name: "{{ admin_user }}"
      - sudo
      - "{{ lookup('file', '~/.ssh/') }}"

web_user: web
web_group: www-data
  - "/usr/sbin/service php7.0-fpm *"

From the Admin user sudoer password docs:

While server.yml provisions your server as the admin_user, it will perform some operations using sudo with a password. You will need to set the sudoer password for admin in the list of vault_sudoer_passwords defined in group_vars/<environment>/vault.yml.

Although this statement in the docs implies that your admin_user must be listed in vault_sudoer_passwords, it could be more explicit that if you change the name of the admin_user, you’ll need to add that new user name to vault_sudoer_passwords.

I’d recommend just going back to the default admin_user: admin (note that the default sudoer password for admin is example_password, as mentioned in the docs above). That way you can have a colleague also use admin for the occasional sudo need, instead of having him/her use aitor. Or you could set up additional users for colleagues. Of course, it’s fine to have admin_user: aitor, but you’d need to add aitor to vault_sudoer_passwords.

You can also simplify your users list by removing one of the two keys listed for admin_user, given that you say they are the same key (just from different locations).

Indeed your admin_user can connect, as you verified with ssh aitor@ The problem was after Ansible had connected, it tested the sudo password it needed to run as the become user. With no password set for aitor the message was ERROR! Incorrect sudo password.

Note that -K (uppercase letter K) is a convenient shortcut for --ask-become-pass.


Ok, then, I went back to “admin”. Should I type “example_password” when the terminal promt me for the password after -K?

In any case, I got this error:

TASK [setup] *******************************************************************
fatal: []: UNREACHABLE! => {"changed": false, "msg": "ERROR! SSH encountered an unknown error during the connection. We recommend you re-run the command using -vvvv, which will enable SSH debugging output to help diagnose the issue", "unreachable": true}

Also, a while ago, I tryied the second way, to generate a password with passlib and set it up for “aitor” in vault_sudoer_passwords of group_vars/staging and keep “aitor” as admin_user (With the same error as in the first post in this thread).

Thank you very much for all the help.

One thing to mention is that my current public key was recovered from a backup of my old system. This file ends with


If I try to make another key pair in my new system (I have reinstalled my OS), the public file ends with


(without ==) Can it be meaningfull?

Yes. Don’t hesitate to experiment like this, especially given that this is your staging site and not production. From the Trellis docs for admin user:

[once you] add the option --ask-become-pass when running server.yml … This prompts you to enter the sudoer password described in the “Admin User Sudoer Password” section [ i.e. example_password]

UNREACHABLE! ... ERROR! SSH encountered an unknown error during the connection.
This can arise after you recreate your VPS and your ~/.ssh/known_hosts has an outdated host key for your domain/ip. Open ~/.ssh/known_hosts and remove the entry for and for any associated domain names. Save the file, and try running server.yml again.

I don’t think this is related to the ssh connection problem. The problem is probably with outdated known_hosts entries. Just be sure that your local machine has the private key that corresponds to the public key you put on your server at time of creating the current VPS (e.g., creating the DigitalOcean droplet). That key pair enables server.yml to connect as the root user.

You can use the root user’s same key pair for the web_user and/or admin_user if you want, or a different pair. Just be sure that your local machine has the private key that corresponds to the public key(s) you list for web_user and admin_userin the users dictionary.

1 Like

Ok, yesterday I detected, with verbosity option -vvvv, the know hosts issue and I fixed it with ssh-keygen -R. Anyway, I did it again by hand with no success.

I have an ERROR! SSH encountered an unknown error message in the terminal output and several no such identity at the end of the output.

This is the entire outpuf of the task with -vvvv flag

Also, I found this possible explanation (too technical for me)

Do you thing I’m gettig this kind of error? Thank you so much.

Looking at the pastebin output, I see admin... does not exist. This is probably because on your previous runs of server.yml the user admin was not created. The users dictionary had the admin_user variable but that variable resolved to aitor not admin, so only the user aitor was created.

Easiest approach – recreate VPS
If it’s convenient to just recreate the VPS, go ahead and do it, and again clean out the known_hosts entries. Leaving admin_user: admin, run server.yml and the connection should work.

Harder, but keeps current VPS
If you prefer not to recreate the VPS, temporarily set admin_user: aitor just so Trellis can connect as aitor. Manually add the user named admin to users, like this:

   - name: "{{ web_user }}"
       - "{{ web_group }}"
   - name: "{{ admin_user }}"
       - sudo
+  - name: admin
+    groups:
+      - sudo
+    keys:
+      -

Make sure you have sudoer passwords for both aitor and admin. Just leave them both the default value while you get things working.

  admin: $6$rounds=100000$JUkj1d3hCa6uFp6R$3rZ8jImyCpTP40e4I5APx7SbBvDCM8fB6GP/IGOrsk/GEUTUhl1i/Q2JNOpj9ashLpkgaCxqMqbFKdZdmAh26/
  aitor: $6$rounds=100000$JUkj1d3hCa6uFp6R$3rZ8jImyCpTP40e4I5APx7SbBvDCM8fB6GP/IGOrsk/GEUTUhl1i/Q2JNOpj9ashLpkgaCxqMqbFKdZdmAh26/

Run server.yml with -K as you have been doing, enter example_password when prompted. Assuming it runs to completion, you will now have both the admin and aitor users on the VPS. You can leave the edits above as they are, or reverse them. With admin created on the server, you can have admin_user: admin and the connection should succeed when you run server.yml again in the future.

1 Like

Just for ensure the workflow for easy approach, what are the correct steps?:

  1. Destroy DO droplet and recreate it from ubuntu 14.04.3 x64 image.
  2. Clean local know hosts
  3. Deploy server.yml

Should I create admin user with sudo privileges at remote server? In that case, after step 1:

ssh root@
# adduser admin
# gpasswd -a admin sudo
# su - admin
# mkdir .ssh
# chmod 700 .ssh
# nano .ssh/authorized_keys
paste inside
# chmod 600 .ssh/authorized_keys
# exit
# service ssh restart

Is it right?

1 Like

Yes, it works! I can’t beleave it. Three weeks without work since I broke my environment with a new defective router.

I do not know how to thank you, really.

I can set up my production server and restore my projects. But It should be easy with the same workflow.