Failure to establish connection when provisioning via ansible-playbook server.yml

trellis
3

After typing a bunch, I see that @kalenjohnson already replied. I’ll still share what I typed, just for extra info.

Purpose of public keys listed in users

The ssh-keys docs point out that Trellis …

will create the users defined in group_vars/all/users.yml, assigning their groups and public SSH keys.

This creates the users on the remote server and enables them to connect at a later point by loading their public keys into ~/.ssh/authorized_keys. Once server.yml has run and has set this up, anyone with the appropriate private key can ssh in to the server as the user with the corresponding public key in the remote’s ~/.ssh/authorized_keys file for that user. That’s why the docs say…

List keys for anyone who will need to make an SSH connection as that user.

Given that an authorized_keys file may have multiple keys, your list of keys under users may have multiple keys; you don’t need to limit the list to a single public key. In your case, you could have retained the lookup for ~/.ssh/id_rsa.pub, which would load that key into authorized_keys on the remote, enabling you to use your regular id_rsa private key to connect in the future, if desired.

The clarification that may help is that the users list is not relevant to the initial connection you were attempting. For the initial connection, the docs mention this…

We assume that when you first create your server you’ve already added your SSH key to the root account… server.yml will try to connect to your server as root. If the connection fails, server.yml will try to connect as the admin_user defined in group_vars/all/users.yml (default admin).

###Helping Ansible and ssh to find the necessary private key

This means that you are manually specifying the private key with each ssh command, and yes, the corollary of manually specifying the private key with every ansible-playbook command is to add the --private-key= or key-file= option. However, you could save yourself some hassle by enabling ssh and ansible-playbook commands to automatically find and use your desired private key file. One approach would be to add an entry to your ssh config file, specifying the IdentityFile to be used with Host 10.10.2.5. I’d recommend the alternative of loading the ~/.ssh/dummy_rsa into your ssh-agent, which can handle keys for you, trying multiple private keys when attempting a connection.

  • Make sure your ssh-agent is running: ssh-agent bash
  • Add your key: ssh-add ~/.ssh/dummy_rsa
  • If you’re on mac, add the key to your Keychain: ssh-add -K ~/.ssh/dummy_rsa

Now you should be able to run ssh commands without the -i option, and ansible-playbook commands without the --key-file= option because your ssh-agent will inform those commands of the various available private keys to try in making the ssh connections.

Reasons for the error “sudo: a password is required”

Of the tasks Trellis runs via the server.yml playbook, some require sudo. This is a non-issue when the playbook connects as root, but sometimes the playbook doesn’t connect as root. If this initial connection attempt as root fails, it will fall back to connecting as the admin_user. This user must specify its sudo password via the option --ask-become-pass, as you discovered.

Maybe you already know why your connection as root failed, but here are some possibilities:

  • Maybe your remote is on AWS, where root is disabled by default, and your admin_user: ubuntu.
  • Maybe you’ve already successfully run server.yml with sshd_permit_root_login: false in group_vars/all/security.yml, so root is no longer allowed to log in via ssh (good security).
  • Maybe the private key you are trying to use is not loaded on the remote in the root user’s authorized_keys
4 Likes