Назад | Перейти на главную страницу

файл, созданный ansible, похоже, имеет искаженные разрешения

Проблема с файлами, созданными Ansible

Я собираюсь использовать для установки новых серверов у нового интернет-провайдера, и я сделал несколько основных шагов для первого тестирования. Я новичок, но провел некоторое тестирование на серверах diff у другого интернет-провайдера, который, похоже, прошел нормально (я создал там файлы без проблем). Оба являются Unbuntu 12, но первоначальное тестирование проводилось на сервере, ядро ​​которого уже было обновлено до 3.8.0-44-generic и добавлены другие maint. Этот новый сервер также является Ubuntu 12, но исходит из шаблона ISP и использует ядро ​​3.5 (Ubuntu 12.04.2 LTS (GNU / Linux 3.5.0-23-generic x86_64))

Моим первым тестом было создание новых пользователей и загрузка их уже существующих ключей SSH для будущего входа в систему. Пользователь был создан без проблем, и создание файла не показало никаких ошибок в процессе создания, но это было, когда я пытался их использовать. Я попытался войти (новый пользователь) _, используя ключ, но система вела себя так, как будто файла ключа SSH там не было. Так как это был первый новый пользователь, я вошел в систему как root и сделал свой первый поиск и создание как root

Как root все выглядит хорошо. Файл «authorized_keys» в каталоге .ssh существует и, похоже, имеет правильные разрешения и правильное содержимое. Но попытка войти через SSH ведет себя так, как будто его там нет. Я вышел из системы root и снова вошел в систему как новый пользователь (используя пароль, поскольку ключ не распознавался). Я делаю «ls -al» и вижу каталог .ssh нормально, но выполнение «ls -al .ssh» для просмотра файла «authorized_keys» в каталоге дает очень странный результат. 'ls' выводит сообщение об ошибке «Permission denied» для каждого элемента внутри каталога, а затем отображает, какими должны быть результаты команды, но пока имя файла отображается, все остальное (разрешения, размер файла, пользователь / группа, дата) заменены вопросительными знаками.

Сначала как пользователь - 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:~$ 

Теперь как 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:~#

Что касается документации, мой сервер соответствует минимальным требованиям (Linux, SSH и Python).

Спецификации - Ubuntu 12.04.2 LTS (GNU / Linux 3.5.0-23-generic x86_64)

Доступная версия - 1.7.1

Я запускаю доступный сеанс на моем ноутбуке с OSX (10.9.4) Python Python 2.7.5

Ниже приведен Ansible Playbook, который я использовал для этого.

---
# 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

===== Просто обновился до ansible 1.7.2 и попробовал снова. Те же результаты. Исполнение ниже

имя сервера и IP-адрес замаскированы

$ 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

Первый ls вы процитировали то, что происходит, когда вы пытаетесь ls -l каталог, в котором у вас есть r разрешение но нет x разрешение. В r бит в каталоге дает вам возможность позвонить readdir на нем, поэтому вы можете получить внутри него имена файлов, но без x ты не можешь stat им, чтобы узнать всю другую информацию, которая ls -l нормально печатает.

ls рассказали вам о невозможности получить информацию с его Permission denied сообщения об ошибках и поля, заполненные вопросительными знаками.

Второй ls подтверждает диагноз этой строкой:

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

Пользователь myusername есть разрешение на чтение, но нет разрешения на выполнение. Вы, наверное, хотите u+x или a+x этот каталог.

Из вашего сообщения я узнал одну интересную вещь: r-без-x теперь дает немного больше информации, чем в былые времена ... вы можете видеть в исходном листинге, что authorized_keys это обычный файл и . и .. каталоги (первый столбец d vs. -). В более старых системах Unix / Linux этот первый столбец тоже был бы знаком вопроса! В наше время readdir возвращает информацию о типе файла в качестве бонуса, поэтому вы можете получить ее без stating.

... Я как бы пропустил вторую половину вашего вопроса, потому что я никогда не видел этого раньше, но это похоже на виновника

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

Я ожидал .ssh каталог быть 0700 как обычно. И файлы внутри будут 0600. Это та область, куда вы действительно не хотите, чтобы другие пользователи блуждали. В любом случае это должно быть как минимум 0500 для ls -l нормально функционировать для собственника.