arquivo criado por ansible parece ter permissões mutiladas

Question

Problema com arquivos criados pelo Ansible

Estou pensando em usar alguns novos servidores em um novo provedor e tenho feito algumas etapas básicas para testar primeiro. Eu sou novo, mas tenho feito alguns testes em servidores diff em outro ISP que parecia ir OK (eu tinha criado arquivos não há problema). Ambos são Unbuntu 12, mas o teste original foi em um servidor que já tinha seu kernel atualizado para 3.8.0-44-generic e outros maint adicionados. Este novo servidor também é o Ubuntu 12, mas vem do modelo ISP e está usando o Kernel 3.5 (Ubuntu 12.04.2 LTS (GNU / Linux 3.5.0-23-genérico x86_64))

Meu primeiro teste seria criar novos usuários e fazer o upload de suas chaves SSH já existentes para login futuro. O usuário foi criado sem problemas e a criação do arquivo não indicou nenhum erro durante o processo de criação, mas ocorreu quando tentei usá-los. Tentei fazer o login (novo usuário) _ usando a chave, mas o sistema agiu como se o arquivo de chave SSH não estivesse lá. Como esse foi o primeiro novo usuário, eu estava logado como root e fiz minha primeira pesquisa e criação como root

Como root tudo parece bom. O arquivo “authorized_keys” no diretório .ssh existe e parece ter as permissões corretas e o conteúdo correto. Mas tentar fazer o login via SSH age como se não estivesse lá. Saí da raiz e me conectei novamente como o novo usuário (usando a senha, pois a chave não estava sendo reconhecida). Eu faço um “ls -al” e vejo o diretório .ssh bem, mas fazer “ls -al .ssh” para ver o arquivo “authorized_keys” no diretório me dá um resultado muito estranho. 'ls' coloca uma mensagem de erro "Permissão negada" para cada item dentro do diretório, e então exibe o que deve ser o resultado do comando, mas enquanto o nome do arquivo é visível, tudo (permissões, tamanho do arquivo, usuário / grupo, data) substituído por pontos de interrogação.

Primeiro como usuário - myusername

myusername@my-server:~$ ls -al .ssh
ls: cannot access .ssh/authorized_keys: Permission denied
ls: cannot access .ssh/..: Permission denied
ls: cannot access .ssh/.: Permission denied
total 0
d????????? ? ? ? ?            ? .
d????????? ? ? ? ?            ? ..
-????????? ? ? ? ?            ? authorized_keys
myusername@my-server:~$ 

Agora como root

sudo bash
[sudo] password for myusername:
root@my-server:~# sudo ls -al .ssh
total 12
drw-r--r-- 2 myusername myusername 4096 Sep 17 19:54 .
drwxr-xr-x 4 myusername myusername 4096 Sep 17 22:51 ..
-rw-r--r-- 1 myusername myusername  406 Sep 17 19:54 authorized_keys
root@my-server:~#

No que diz respeito à documentação, meu servidor atende aos requisitos mínimos (linux, SSH e Python)

As especificações são - Ubuntu 12.04.2 LTS (GNU / Linux 3.5.0-23-genérico x86_64)

A versão ansible é 1.7.1

Estou executando a sessão ansible do meu laptop Python Python 2.7.5 OSX (10.9.4)

Abaixo está o Ansible Playbook que eu corri para fazer isso

---
# This playbook create my user {{userid}} and loads the public ssh-key

- name: create my user {{userid}} and loads the public ssh-key  
  hosts: myservername-public 
#  gather_facts: no
#  remote_user: myusername
  vars:
#    security_groups: "sudo,adm"
    security_groups: ""
    userid: testjunk01
  tasks:
  - name: test connection
    ping:
    remote_user: myusername

  - name: Create user {{userid}} groups={{security_groups}} 
    user: name={{userid}} shell=/bin/bash groups={{security_groups}} append=yes 
      password=$hashed_password_was_here_and_it_worked

  - name: Verify that needed directories are in place before file copy 
    file: dest="/home/{{userid}}/.ssh"
          mode=0644
          owner={{userid}} group={{userid}} 
          state=directory

  - name: Copy file into user {{userid}}'s directory 
    copy: src="/Users/osx_user/Documents/Projects/Projects Internal/Security/ssh-key-public/myusername"
          dest="/home/{{userid}}/.ssh/authorized_keys"
          mode=0644
          owner={{userid}} group={{userid}} 
          backup=yes

  - name: Reset permissions for file after file copy 
    file: dest="/home/{{userid}}/.ssh/authorized_keys"
          mode=0644
          owner={{userid}} group={{userid}} 
          state=file

===== Atualizou para ansible 1.7.2 e tentou novamente. Mesmos resultados Execução abaixo

nome do servidor e endereço IP mascarados

$ ansible-playbook playbooks/test01/Test02/create-user -i  ansible-hosts --ask-pass -vv
SSH password:

PLAY [create my user testjunk01 and loads the public ssh-key] *****************

GATHERING FACTS ***************************************************************
<192..168.1.1> REMOTE_MODULE setup
ok: [myserver-public]

TASK: [test connection] *******************************************************
<192..168.1.1> REMOTE_MODULE ping
ok: [myserver-public] => {"changed": false, "ping": "pong"}

TASK: [Create user testjunk01 groups=] ****************************************
<192..168.1.1> REMOTE_MODULE user name=testjunk01 shell=/bin/bash groups= append=yes password=VALUE_HIDDEN
ok: [myserver-public] => {"append": true, "changed": false, "comment": "", "group": 1003, "groups": "", "home": "/home/testjunk01", "move_home": false, "name": "testjunk01", "password": "NOT_LOGGING_PASSWORD", "shell": "/bin/bash", "state": "present", "uid": 1003}

TASK: [Verify that needed directories are in place before file copy] **********
<192..168.1.1> REMOTE_MODULE file dest="/home/testjunk01/.ssh" mode=0644 owner=testjunk01 group=testjunk01 state=directory
changed: [myserver-public] => {"changed": true, "gid": 1003, "group": "testjunk01", "mode": "0644", "owner": "testjunk01", "path": "/home/testjunk01/.ssh", "size": 4096, "state": "directory", "uid": 1003}

TASK: [Copy file into user testjunk01's directory] ****************************
changed: [myserver-public] => {"changed": true, "dest": "/home/testjunk01/.ssh/authorized_keys", "gid": 1003, "group": "testjunk01", "md5sum": "fd6c6017993e847026a010bf67a96c1a", "mode": "0644", "owner": "testjunk01", "size": 406, "src": "/root/.ansible/tmp/ansible-tmp-1412114658.34-25330110994991/source", "state": "file", "uid": 1003}

TASK: [Reset permissions for file after file copy] ****************************
<192..168.1.1> REMOTE_MODULE file dest="/home/testjunk01/.ssh/authorized_keys" mode=0644 owner=testjunk01 group=testjunk01 state=file
ok: [myserver-public] => {"changed": false, "gid": 1003, "group": "testjunk01", "mode": "0644", "owner": "testjunk01", "path": "/home/testjunk01/.ssh/authorized_keys", "size": 406, "state": "file", "uid": 1003}

PLAY RECAP ********************************************************************
myserver-public         : ok=6    changed=2    unreachable=0    failed=0

    

Answer 1

O primeiro ls que você citou é o que acontece quando você tenta ls -l um diretório no qual você tem r permissão, mas não x permission. O r bit em um diretório dá a você a habilidade de chamar readdir , então você pode obter os nomes dos arquivos dentro dele, mas sem x você não pode stat para descobrir todas as outras informações que ls -l normalmente imprime.

ls informou sobre a incapacidade de obter as informações com suas mensagens de erro Permission denied e campos cheios de pontos de interrogação.

O segundo ls confirma o diagnóstico com esta linha:

drw-r--r-- 2 myusername myusername 4096 Sep 17 19:54 .

O usuário myusername tem permissão de leitura, mas não tem permissão de execução. Você provavelmente deseja u+x ou a+x desse diretório.

Uma coisa interessante que aprendi em sua postagem é que r -sem- x agora fornece um pouco mais de informações do que antigamente ... você pode ver na listagem original que authorized_keys é uma publicação regular arquivo e . e .. são diretórios (primeira coluna d vs. - ). Em um sistema Unix / Linux mais antigo, a primeira coluna também seria um ponto de interrogação! Hoje em dia, readdir retorna informações do tipo de arquivo como um bônus para que você possa obtê-lo sem stat ing.

... eu meio que passei a segunda metade da sua pergunta porque eu nunca vi essas coisas antes, mas isso parece o culpado

file: dest="/home/{{userid}}/.ssh"
      mode=0644

Eu esperaria que um diretório .ssh fosse 0700 normalmente. E os arquivos dentro de para ser 0600 . É uma área em que você realmente não quer que outros usuários entrem. De qualquer forma, é preciso que pelo menos 0500 para ls -l funcione normalmente para o proprietário.