Vấn đề

Sử dụng bản dựng Ansible ổn định, mới nhất, tôi gặp một vấn đề kỳ lạ khi playbook của tôi bị treo trên một máy chủ trong khi "Gathering_Facts" nhưng hoạt động tốt trên các máy chủ tương tự khác khi sử dụng Sudo. Trên máy chủ Ansible, tôi chạy với tư cách là người dùng của mình (người dùng NIS) và sử dụng sudo (với quyền root) trên máy chủ từ xa để thực hiện các thay đổi. Nếu tôi loại bỏ Sudo khỏi thiết lập này, mọi thứ sẽ hoạt động tốt.

Thiết lập

Phiên bản phần mềm

• HĐH : RHEL 6.4
• Phiên bản ansible : ansible 1.8.2
• Phiên bản Sudo :

  Phiên bản Sudo 1.8.6p3
  Plugin chính sách Sudoers phiên bản 1.8.6p3
  Sudoers tập tin ngữ pháp phiên bản 42
  Sudoers plugin I / O phiên bản 1.8.6p3
  

• Phiên bản SSH : OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 tháng 3 năm 2010

Bản đồ máy chủ

                   -------- User1 @ Server1: sudo -H -S -p (Treo trên Gathering_Facts)
                  /
Người dùng1 @ Ansible ----
                  \
                   -------- User1 @ Server2: sudo -H -S -p (Hoạt động tốt)

Người dùng

• Người dùng1: Người dùng có thể truy cập NIS trên cả Server1 & Server2.
• root: người dùng root cục bộ cho mỗi máy chủ.

Cấu hình ansible

Các phần có liên quan của ansible.cfg của tôi .

ansible.cfg

sudo           = true
sudo_user      = root
ask_sudo_pass  = True
ask_pass       = True
...
gathering = smart
....
# change this for alternative sudo implementations
sudo_exe = sudo

# what flags to pass to sudo
#sudo_flags = -H
...
# remote_user = ansible

Dưới đây là một playbook thử nghiệm đơn giản để chạm vào một tập tin trống và sau đó loại bỏ nó. Thực sự, tôi chỉ muốn kiểm tra xem tôi có thể sử dụng Ansible để sử dụng chính xác sudo trên máy chủ từ xa không. Nếu playbook chạy hoàn toàn, tôi đang ở trong tình trạng tốt.

KIỂM TRA

---
- hosts: Server1:Server2
  vars:
  - test_file: '/tmp/ansible_test_file.txt'
  sudo: yes
  tasks:
  - name: create empty file to test connectivity and sudo access
    file: dest={{ test_file }}
          state=touch
          owner=root group=root mode=0600
    notify:
    - clean
  handlers:
  - name: clean
    file: dest={{ test_file }}
          state=absent

Cấu hình Sudo

/ etc / sudoers

Host_Alias SRV     = Server1, Server2
User_Alias SUPPORT = User1, User2, User3
SUPPORT SRV=(root) ALL

Cấu hình sudo này chỉ hoạt động tốt trên các máy chủ CẢ. Không có vấn đề với chính sudo.

Làm thế nào tôi chạy tất cả

Rất đơn giản:

$ ansible-playbook test.yml
Mật khẩu SSH: 
mật khẩu sudo [mặc định là mật khẩu SSH]:

CHƠI [Máy ​​chủ1: Máy chủ2] ****** / TÌM KIẾM ** 

SỰ THẬT TUYỆT VỜI ****** / TÌM HIỂU ****** / TÌM HIỂU 
ok: [Máy ​​chủ2]
thất bại: [Server1] => {"fail": true, "đã phân tích cú pháp": false}

Xin lỗi, thử lại.
[sudo qua ansible, key = mxxiqyvztlfnbctwixzmgvhwfdarumtq] mật khẩu: 
sudo: 1 lần thử mật khẩu không chính xác


NHIỆM VỤ: [tạo tập tin trống để kiểm tra kết nối và truy cập sudo] ****** / TÌM HIỂU 
đã thay đổi: [Server2]

THÔNG BÁO: [sạch sẽ] ****** / TÌM HIỂU ****** / TÌM HIỂU 
đã thay đổi: [Server2]

CHƠI RECAP ****** / TÌM HIỂU ****** / TÌM HIỂU 
           để thử lại, sử dụng: --limit @ / home / User1 / test.retry

Máy chủ1: ok = 0 đã thay đổi = 0 không thể truy cập = 0 không thành công = 1   
Máy chủ2: ok = 3 thay đổi = 2 không thể truy cập = 0 không thành công = 0

Thất bại bất kể nếu tôi nhập rõ ràng cả mật khẩu SSH / Sudo cũng như ngầm định (cho phép sudo chuyển mặc định sang SSH).

Nhật ký máy chủ từ xa

Máy chủ1 (Thất bại)

/ var / log / an toàn

31/12 15:21:10 Server1 sshd [27093]: Mật khẩu được chấp nhận cho User1 từ cổng xxxx 51446 ssh2
Ngày 31 tháng 12 15:21:10 Server1 sshd [27093]: pam_unix (sshd: session): phiên được mở cho người dùng User1 by (uid = 0)
Ngày 31 tháng 12 15:21:11 Server1 sshd [27095]: yêu cầu hệ thống con cho sftp
Ngày 31 tháng 12 15:21:11 Server1 sudo: pam_unix (sudo: auth): lỗi xác thực; logname = User1 uid = 187 euid = 0 tty = / dev / pts / 1 ruser = User1 rhost = user = User1
31/12 15:26:13 Server1 sudo: pam_unix (sudo: auth): cuộc hội thoại thất bại
31/12 15:26:13 Server1 sudo: pam_unix (sudo: auth): auth không thể xác định mật khẩu cho [User1]
Ngày 31 tháng 12 15:26:13 Server1 sudo: User1: 1 lần thử mật khẩu không chính xác; TTY = pts / 1; NKT = / nhà / Người dùng1; NGƯỜI DÙNG = root; LỰA CHỌN = / bin / sh -c echo SUDO-SUCCESS-mxxiqyvztlfnbctwixzmgvhwfdarumtq; LANG = C LC_CTYPE = C / usr / bin / python /tmp/.ansible/tmp/ansible-tmp-1420039272.66-164854043073536/setup; rm -rf /tmp/.ansible/tmp/ansible-tmp-1420039272.66-164754043073536/> / dev / null 2> & 1
Ngày 31 tháng 12 15:26:13 Server1 sshd [27093]: pam_unix (sshd: session): phiên đóng cho người dùng User1 

Server2 (chạy tốt)

/ var / log / an toàn

31/12 15:21:12 Server2 sshd [31447]: Mật khẩu được chấp nhận cho User1 từ cổng xxxx 60346 ssh2
Ngày 31 tháng 12 15:21:12 Server2 sshd [31447]: pam_unix (sshd: session): phiên được mở cho người dùng User1 by (uid = 0)
Ngày 31 tháng 12 15:21:12 Server2 sshd [31449]: yêu cầu hệ thống con cho sftp
Ngày 31 tháng 12 15:21:12 Server2 sudo: Người dùng1: TTY = pts / 2; NKT = / nhà / Người dùng1; NGƯỜI DÙNG = root; LỆNH = / bin / sh -c echo SUDO-SUCCESS-vjaypzeocvrdlqalxflgcrcoezhnbibs; LANG = C LC_CTYPE = C / usr / bin / python /tmp/.ansible/tmp/ansible-tmp-1420039272.68-243930711246149/setup; rm -rf /tmp/.ansible/tmp/ansible-tmp-1420039272.68-243930711246149/> / dev / null 2> & 1
Ngày 31 tháng 12 15:21:14 Server2 sshd [31447]: pam_unix (sshd: session): phiên đóng cho người dùng User1 

Đầu ra STrace

Đây là đầu ra từ strace khi nhắm mục tiêu lệnh ansible của người dùng root. Chỉ huy:

while [[ -z $(ps -fu root|grep [a]nsible|awk '{print $2}') ]]; do
    continue
done
strace -vfp $(ps -fu root|grep [a]nsible|awk '{print $2}') -o /root/strace.out`

Máy chủ 1

23650 chọn (0, NULL, NULL, NULL, {1, 508055}) = 0 (Hết giờ)
Ổ cắm 23650 (PF_NETLINK, SOCK_RAW, 9) = 10
23650 fcntl (10, F_SETFD, FD_CLOEXEC) = 0
23650 đường dẫn đọc ("/ Proc / self / exe", "/ usr / bin / sudo", 4096) = 13
23650 sendto (10, "| \ 0 \ 0 \ 0L \ 4 \ 5 \ 0 \ 1 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0op = PAM: xác thực" ..., 124, 0, {sa_f Family = AF_NETLINK, pid = 0, nhóm = 00000000}, 12) = 124
Thăm dò ý kiến ​​23650 ([{fd = 10, sự kiện = POLLIN}], 1, 500) = 1 ([{fd = 10, revents = POLLIN}])
23650 recvfrom (10, "$ \ 0 \ 0 \ 0 \ 2 \ 0 \ 0 \ 0 \ 1 \ 0 \ 0 \ 0b \\\ 0 \ 0 \ 0 \ 0 \ 0 \ 0 | \ 0 \ 0 \ 0L \ 4 \ 5 \ 0 \ 1 \ 0 \ 0 \ 0 "..., 8988, MSG_PEEK | MSG_DONTWAIT, {sa_f Family = AF_NETLINK, pid = 0, Groups = 00000000}, [12]) = 36
23650 recvfrom (10, "$ \ 0 \ 0 \ 0 \ 2 \ 0 \ 0 \ 0 \ 1 \ 0 \ 0 \ 0b \\\ 0 \ 0 \ 0 \ 0 \ 0 \ 0 | \ 0 \ 0 \ 0L \ 4 \ 5 \ 0 \ 1 \ 0 \ 0 \ 0 "..., 8988, MSG_DONTWAIT, {sa_f Family = AF_NETLINK, pid = 0, nhóm = 00000000}, [12]) = 36
23650 đóng (10) = 0
23650 viết (2, "Xin lỗi, thử lại. \ N", 18) = 18
23650 gettimeofday ({1420050850, 238344}, NULL) = 0
Ổ cắm 23650 (PF_FILE, SOCK_STREAM, 0) = 10
23650 kết nối (10, {sa_f Family = AF_FILE, path = "/ var / run / dbus / system_bus_socket"}, 33) = 0

Máy chủ2

6625 chọn (8, [5 7], [], NULL, NULL) =? ERESTARTNOHAND (Sẽ được khởi động lại)
6625 --- SIGCHLD (Trẻ em đã thoát) @ 0 (0) ---
6625 viết (8, "\ 21", 1) = 1
6625 rt_sigreturn (0x8) = -1 EINTR (Cuộc gọi hệ thống bị gián đoạn)
6625 chọn (8, [5 7], [], NULL, NULL) = 1 (trong [7])
6625 đọc (7, "\ 21", 1) = 1
6625 Wait4 (6636, [{WIFEXITED (s) && WEXITSTATUS (s) == 0}], WNOHANG | WSTOPPED, NULL) = 6636
6625 rt_sigprocmask (SIG_BLOCK, NULL, [], 8) = 0
Ổ cắm 6625 (PF_NETLINK, SOCK_RAW, 9) = 6
6625 fcntl (6, F_SETFD, FD_CLOEXEC) = 0
6625 đường dẫn đọc ("/ Proc / self / exe", "/ usr / bin / sudo", 4096) = 13
6625 sendto (6, "x \ 0 \ 0 \ 0R \ 4 \ 5 \ 0 \ 6 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0op = PAM: session_c" ..., 120, 0, {sa_f Family = AF_NETLINK, pid = 0, nhóm = 00000000}, 12) = 120
Thăm dò ý kiến ​​6625 ([{fd = 6, sự kiện = POLLIN}], 1, 500) = 1 ([{fd = 6, revents = POLLIN}])
6625 recvfrom (6, "$ \ 0 \ 0 \ 0 \ 2 \ 0 \ 0 \ 0 \ 6 \ 0 \ 0 \ 0 \ 330 \ 355 \ 377 \ 377 \ 0 \ 0 \ 0 \ 0x \ 0 \ 0 \ 0R \ 4 \ 5 \ 0 \ 6 \ 0 \ 0 \ 0 "..., 8988, MSG_PEEK | MSG_DONTWAIT, {sa_f Family = AF_NETLINK, pid = 0, nhóm = 00000000}, [12]) = 36
6625 recvfrom (6, "$ \ 0 \ 0 \ 0 \ 2 \ 0 \ 0 \ 0 \ 6 \ 0 \ 0 \ 0 \ 330 \ 355 \ 377 \ 377 \ 0 \ 0 \ 0 \ 0x \ 0 \ 0 \ 0R \ 4 \ 5 \ 0 \ 6 \ 0 \ 0 \ 0 "..., 8988, MSG_DONTWAIT, {sa_f Family = AF_NETLINK, pid = 0, nhóm = 00000000}, [12]) = 36
6625 đóng (6) = 0
6625 mở ("/ etc / security / pam_env.conf", O_RDONLY) = 6
6625 fstat (6, {st_dev = makenev (253, 1), st_ino = 521434, st_mode = S_IFREG | 0644, st_nlink = 1, st_uid = 0, st_gid = 0, st_blksize = 4096, st_blksize = 2014/12 / 31-16: 10: 01, st_mtime = 2012/10 / 15-08: 23: 52, st_ctime = 2014/06 / 16-15: 45: 35}) = 0
6625 mmap (NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0) = 0x7fbc3a59a000
6625 đọc (6, "# \ n # Đây là cấu hình fi" ..., 4096) = 2980
6625 đọc (6, "", 4096) = 0
6625 đóng (6) = 0
6625 munmap (0x7fbc3a59a000, 4096) = 0
6625 mở ("/ etc / môi trường", O_RDONLY) = 6

Đoán của tôi

Server1 không nhận được mật khẩu chính xác hoặc yêu cầu / chờ mật khẩu không chính xác. Điều này không giống như vấn đề Sudo hoặc Ansible (một mình, cả hai đều hoạt động tốt), nhưng Server1 dường như không nhận được thông tin đăng nhập (hoặc tuân thủ chúng) theo cách tương tự như Server2. Server1 & 2 phục vụ các mục đích khác nhau, vì vậy có thể chúng có một số khác biệt về phiên bản gói hoặc xác thực, nhưng cả hai đều được xây dựng từ cùng một kho lưu trữ; do đó, họ không nên khác nhau.

PAM Auth

Tôi nghĩ có lẽ các hệ thống có cấu hình PAM khác nhau khiến mật khẩu được xử lý hơi khác một chút. Tôi đã so sánh các tập tin /etc/pam.d/ (bằng cách sử dụng md5sum [file]) và chúng giống nhau giữa hai hệ thống.

Xét nghiệm

STDIN Sudo

Đã kiểm tra một vấn đề khác trong đó sudo sẽ không đọc mật khẩu từ STDIN, nhưng nó đã hoạt động tốt trên cả hai máy chủ.

Kiểm tra Sudo Ad-Hoc

-bash-4.1 $ ansible Server1 -m tệp -a "Dest = / tmp / ansible_test.txt state = touch" -sK
Mật khẩu SSH: 
mật khẩu sudo [mặc định là mật khẩu SSH]: 
Máy chủ1 | thành công >>
    "đã thay đổi": đúng, 
    "mệnh": "/tmp/ansible_test.txt", 
    "gid": 0, 
    "nhóm": "gốc", 
    "chế độ": "0644", 
    "chủ sở hữu": "root", 
    "kích thước": 0, 
    "trạng thái": "tập tin", 
    "uid": 0
}

Sự thành công! Nhưng tại sao?!

TL; DR

1. Server1 dường như đang chờ trên dấu nhắc mật khẩu sudo trong khi Server2 chạy tốt.
2. Chạy ansible"ad-hoc" trên Server1 hoạt động tốt. Chạy nó như một vở kịch thất bại.

Câu hỏi

• Điều gì có thể khiến cấu hình Ansible Sudo của tôi hoạt động tốt trên một máy chủ và bị từ chối trên một máy chủ khác?
• Ansible có thực hiện "chuyển" mật khẩu từ máy cục bộ sang máy từ xa khác nhau khi chạy ad-hoc so với playbook không? Tôi cho rằng họ sẽ giống nhau.

Tôi nghĩ rằng điều này đang tiến gần đến việc gửi báo cáo lỗi đến trang GitHub hoàn toàn dựa trên thực tế là truy cập sudo có kết quả khác nhau tùy thuộc vào việc tôi có chạy ad-hoc hay không.

Những gì tôi sẽ làm là sử dụng

strace -vfp `pidof sshd`

và xem nó thất bại ở đâu.

Kiểm tra tài khoản là tốt, có thể nó bị hạn chế hoặc một cái gì đó nhưng tôi cá là có gì đó không ổn với tập tin / etc / hosts của bạn hoặc nó bị thay đổi trong quy trình.

Sử dụng @lulian như một chỗ đứng trong câu trả lời này, vấn đề đã dẫn đến một sự bất hảo ansible_sudo_pass:được xác định trong các nhóm dữ liệu ghi đè mật khẩu đã nhập --ask-sudo-pass.

Sử dụng như sau:

while [[ -z $(ps -eaf|grep 'sshd: [U]ser1@pts/1') ]]; do
    continue
done
strace -ff -vfp $(ps -eaf|grep 'sshd: [U]ser1@pts/1'|awk '{print $2}') -o /root/strace_sshd1_2.out

Tôi đã có thể tìm thấy nó write(4, "{{ password }}\n", 15)đã được thông qua thay vì mật khẩu đã nhập. Sau một số tìm kiếm nhanh, tôi thực sự đã tìm thấy ansible_sudo_passđược xác định trong các nhóm của tôi, ghi đè mật khẩu đã nhập của tôi.

Là một FYI cho những người khác, ansible_sudo_pass:định nghĩa dường như được ưu tiên hơn --ask-sudo-pass, lúc đầu, dường như phản trực giác. Cuối cùng, đây là lỗi của người dùng, nhưng phương pháp của @ lulian trong việc gỡ lỗi tương tác SSH cũng như phát hiện mối quan hệ giữa ansible_sudo_passvà --ask-sudo-passsẽ rất hữu ích cho những người khác ngoài kia. (Hy vọng!)