web-dev-qa-db-fra.com

Échec de l'établissement de la connexion lors de la configuration via ansible-playbook server.yml

J'utilise le flux de travail Trellis de Root.io.

J'ai rencontré une erreur qui ne permettait pas d'établir une connexion via ansible-playbook.

  1. Lorsque j'exécute ansible-playbook server.yml -e env=staging, une erreur s'est produite, indiquant que la connexion ssh ne peut pas être établie. J'ai vérifié mon fichier users.yml et constaté un problème dans la section keys:

    - name: "{{ admin_user }}"
  groups:
    - Sudo
  keys:
    - "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
    - https://github.com/dummyuser.keys

    J'ai réalisé que j'avais une clé id_rsa.pub existante mais je ne l'avais pas autorisée sur mon serveur, j'utilisais plutôt https://github.com/dummyuser.keys. Alors j'ai enlevé cette ligne

    - "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"

    Cependant, le problème persiste. La réponse fut:

    fatal: [10.10.2.5]: UNREACHABLE! => {
    "changed": false, 
    "msg": "Failed to connect to the Host via ssh.", 
    "unreachable": true
}

    Aussi, pourquoi la configuration pointe-t-elle sur le public key alors que nous avons besoin du private key pour se connecter via ssh. Je fais habituellement

    ssh -i ~/.ssh/private_key [email protected]

    chaque fois que je me connecte au serveur via ssh.

  2. J'ai donc utilisé une autre approche. spécifié la clé sur la cli cette fois

    ansible-playbook server.yml -e env=staging -vvvv --key-file=~/.ssh/dummy_rsa

    et le résultat fut que j'ai pu établir une connexion:

    <10.10.2.5> ESTABLISH SSH CONNECTION FOR USER: dummy_admin

    Mais il y avait une autre erreur: il dit a password is required voici le message complet:

    fatal: [10.10.2.5]: FAILED! => {
    "changed": false, 
    "failed": true, 
    "invocation": {"module_name": "setup"}, 
    "module_stderr": "OpenSSH_6.9p1, LibreSSL 2.1.8\r\ndebug1: Reading configuration data /etc/ssh/ssh_config\r\ndebug1: /etc/ssh/ssh_config line 21: Applying options for *\r\ndebug1: auto-mux: Trying existing master\r\ndebug2: fd 3 setting O_NONBLOCK\r\ndebug2: mux_client_hello_exchange: master version 4\r\ndebug3: mux_client_forwards: request forwardings: 0 local, 0 remote\r\ndebug3: mux_client_request_session: entering\r\ndebug3: mux_client_request_alive: entering\r\ndebug3: mux_client_request_alive: done pid = 85702\r\ndebug3: mux_client_request_session: session request sent\r\ndebug1: mux_client_request_session: master session id: 2\r\ndebug3: mux_client_read_packet: read header failed: Broken pipe\r\ndebug2: Received exit status from master 1\r\nShared connection to 10.10.2.5 closed.\r\n", 
    "module_stdout": "Sudo: a password is required\r\n", 
    "msg": "MODULE FAILURE", 
    "parsed": false
}

    Je ne sais pas pourquoi il demande un mot de passe. Je l'ai déjà défini dans mon group_vars/staging/vault.yml en voici le contenu:

    vault_mysql_root_password: stagingpw
vault_sudoer_passwords:
  dummy_admin: $6$rounds=656000$8DWzDN3KQkM9SjlF$DhxLkYaayplFmtj9q.EqzMDWmvlLNKsLU0GPL9E0P2EvkFQBsbjcMCXgWkug4a5E66PfwL4eZQXzMLkhXcPBk0

  3. Alors je me suis finalement connecté en utilisant la commande ci-dessous:

    ansible-playbook server.yml -e env=staging -vvvv --key-file=~/.ssh/dummy_rsa --ask-become-pass

    apres me demander un mot de passe cela fonctionne et approvisionne mon serveur sans probleme.

Quelqu'un peut-il éclairer cela? Est-ce que je manque quelque chose? Faites-moi savoir si vous avez besoin de plus de détails.

deploymenttheme-rootsssh
2
JohnnyQ

J'ai aussi posté cette question sur discours et @fullyint a répondu en détail. Donc, je poste juste un lien pour la réponse et un extrait

Aider Ansible et ssh à trouver la clé privée nécessaire

Cela signifie que vous spécifiez manuellement la clé privée avec chaque commande ssh, et oui, le corollaire de la spécification manuelle de la clé privée avec chaque commande ansible-playbook consiste à ajouter l'option --private-key = ou key-file =. Cependant, vous pourriez vous épargner quelques soucis en activant les commandes ssh et ansible-playbook pour rechercher et utiliser automatiquement le fichier de clé privée souhaité. Une solution consiste à ajouter une entrée à votre fichier de configuration ssh, en spécifiant le fichier IdentityFile à utiliser avec l'hôte 10.10.2.5. Je recommanderais l'alternative de charger ~/.ssh/dummy_rsa dans votre ssh-agent, qui peut gérer les clés pour vous, en essayant plusieurs clés privées lors d'une tentative de connexion.
Assurez-vous que votre agent ssh est en cours d'exécution: ssh-agent bash Ajoutez votre clé: ssh-add ~/.ssh/dummy_rsa Si vous êtes sur mac, ajoutez la clé à votre trousseau: ssh-add -K ~/.ssh/dummy_rsa Vous devriez maintenant pouvoir exécuter des commandes ssh sans l'option -i et des commandes ansible-playbook sans l'option --key-file = car votre agent ssh informera ces commandes des différentes clés privées disponibles. essayer de faire les connexions ssh.

Raisons de l'erreur "Sudo: un mot de passe est requis"

Parmi les tâches exécutées par Trellis via le livre de serveur server.yml, certaines nécessitent Sudo. Ceci n'est pas un problème lorsque le playbook se connecte en tant que root, mais parfois, le playbook ne se connecte pas en tant que root. Si cette tentative de connexion initiale en tant que root échoue, la connexion sera établie en tant qu'utilisateur admin_user. Cet utilisateur doit spécifier son mot de passe Sudo via l'option --ask-devenir-passe, comme vous l'avez découvert.
Vous savez peut-être déjà pourquoi votre connexion en tant que root a échoué, mais voici quelques possibilités:
Peut-être que votre télécommande est sur AWS, où la racine est désactivée par défaut, et votre admin_user: ubuntu.
Peut-être avez-vous déjà réussi à exécuter server.yml avec sshd_permit_root_login: false dans group_vars/all/security.yml, de sorte que root ne peut plus se connecter via ssh (bonne sécurité). Peut-être que la clé privée que vous essayez d'utiliser n'est pas chargée sur la télécommande dans la racine authorisedkeke de l'utilisateur root

2
JohnnyQ

Vous n'avez probablement pas ajouté votre clé public au fichier authorized_keys inside de la machine. Vous pouvez également ajouter votre clé private à votre agent SSH local.

  1. Mettez votre public key dans le serveur. Exemple pour une clé déjà présente sur le serveur:

    # Add key directly on the box:
echo "$(cat your_public_key)" >> ~/.ssh/authorized_keys
# Add key from local to remote:
ssh user@server "echo \"$(cat your_public_key)\" >> ~/.ssh/authorized_keys"

  2. Vous devez ajouter la clé private à votre agent.

    # Start agent
eval "$(ssh-agent -s)"
# Add private key
ssh-add ~/.ssh/your_private_key
1
kaiser