Soru Sudo Pass verildiğinde bile Sudo Kimlik Doğrulama Başarısız


Sorun

En son, istikrarlı Ansible yapısını kullanarak, oyun kitabımın "Gathering_Facts" sırasında bir sunucuda asılı kaldığı, ancak Sudo kullanırken diğer benzer sunucularda iyi çalıştığı garip bir sorunum var. Ansible sunucusunda, kullanıcı (NIS kullanıcısı) olarak çalışıyorum ve kullanıyorum sudo Değişiklik yapmak için uzak sunucuda (root olarak). Sudo'yu bu kurulumdan kaldırırsam her şey yolunda gider.

Kurmak

Yazılım Sürümleri

  • işletim sistemi: RHEL 6.4
  • Ansible sürümü: 1.8.1.
  • Sudo sürümü:
    Sudo sürüm 1.8.6p3
    Sudoers politika eklentisi sürüm 1.8.6p3
    Sudoers dosya dilbilgisi sürümü 42
    Sudoers I / O eklenti sürümü 1.8.6p3
    
  • SSH sürümü: OpenSSH_5.3p1, OpenSSL 1.0.0-fps 29 Mar 2010

Sunucu Haritası

                   -------- Kullanıcı1 @ Sunucu1: sudo -H -S -p (Gathering_Facts üzerinde askıda kalıyor)
                  /
Kullanıcı1 @ Ansible ----
                  \
                   -------- Kullanıcı1 @ Sunucu2: sudo -H -S -p (İyi çalışıyor)

Kullanıcılar

  • Kullanıcı1: Server1 ve Server2'de NIS erişilebilir kullanıcı.
  • root: her sunucu için yerel kök kullanıcısı.

Ansible Yapılandırma

Benim ilgili bölümleri ansible.cfg.

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

İşte boş bir dosyaya dokunmak ve sonra kaldırmak için basit bir test kitabı. Gerçekten de, uzak sunucudaki sudo'yu doğru şekilde kullanabilmem için Ansible'ı test edip edemeyeceğimi test etmek istiyorum. Eğer oyun kitabı çalışırsa, ben iyi durumdayım.

TEST.yml

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

Sudo Yapılandırması

/ Etc / Sudoers

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

Bu sudo yapılandırması, BOTH sunucularında gayet iyi çalışır. Sudo'nun kendisi ile sorun yok.

Nasıl Çalıştırırım

Çok basit:

$ ansible-playbook test.yml
SSH şifresi:
sudo şifresi [varsayılanlar SSH şifresi]:

OYNAT [Sunucu1: Sunucu2] ******************************************** **

GELECEK HATALAR ************************************************ ***************
tamam: [Sunucu2]
başarısız: [Sunucu1] => {"başarısız": true, "ayrıştırıldı": false}

Üzgünüm, tekrar dene.
[ansible ile sudo, anahtar = mxxiqyvztlfnbctwixzmgvhwfdarumtq] parola:
sudo: 1 yanlış şifre girişimi


GÖREV: [bağlantıyı ve sudo erişimini sınamak için boş bir dosya oluştur] ****************
değiştirildi: [Server2]

DEĞİLDİ: [temiz] ********************************************* ****************
değiştirildi: [Server2]

OYUN RECAP ************************************************ ********************
           yeniden denemek için: --limit @ / home / User1 / test.retry

Sunucu1: tamam = 0 değiştirildi = 0 ulaşılamaz = 0 başarısız oldu = 1
Sunucu2: ok = 3 değiştirildi = 2 ulaşılamaz = 0 başarısız oldu = 0

SSH / Sudo şifrelerini açık bir şekilde girdiğimden ve dolaylı olarak (SSH'ya sudo pass default vermesine izin vermeme rağmen) başarısız olur.

Uzak Sunucu Günlükleri

Sunucu1 (Başarısız)

/ Var / log / güvenli

31 Aralık 15:21:10 Sunucu1 sshd [27093]: Kullanıcı1 için x.x.x.x bağlantı noktası 51446 ssh2 için kabul edilen parola
31 Aralık 15:21:10 Sunucu1 sshd [27093]: pam_unix (sshd: oturum): kullanıcı tarafından açılan oturum kullanıcı1 (uid = 0)
31 Aralık 15:21:11 Sunucu1 sshd [27095]: sftp için alt sistem isteği
31 Aralık 15:21:11 Sunucu1 sudo: pam_unix (sudo: auth): kimlik doğrulama hatası; logname = Kullanıcı1 uid = 187 euid = 0 tty = / dev / pts / 1 ruser = Kullanıcı1 rhost = kullanıcı = Kullanıcı1
31 Aralık 15:26:13 Sunucu1 sudo: pam_unix (sudo: auth): ileti dizisi başarısız oldu
31 Aralık 15:26:13 Sunucu1 sudo: pam_unix (sudo: auth): auth [Kullanıcı1] için parola tanımlayamadı
31 Aralık 15:26:13 Sunucu1 sudo: Kullanıcı1: 1 yanlış şifre denemesi; TTY = pts / 1; PWD = / ev / Kullanıcı1; USER = root; COMMAND = / bin / sh -c echo SUDO-SUCCESS-mxxiqyvztlfnbctwixzmgvhwfdarumtq; LANG = C LC_CTYPE = C / usr / bin / python /tmp/.ansible/tmp/ansible-tmp-1420039272.66-164754043073536/setup; rm -rf /tmp/.ansible/tmp/ansible-tmp-1420039272.66-164754043073536/> / dev / null 2> & 1
31 Aralık 15:26:13 Sunucu1 sshd [27093]: pam_unix (sshd: oturum): oturum User1 kullanıcı için kapatıldı

Server2 (iyi çalışır)

/ Var / log / güvenli

31 Aralık 15:21:12 Sunucu2 sshd [31447]: Kullanıcı1 için x.x.x.x bağlantı noktası 60346 ssh2 için kabul edilen parola
31 Aralık 15:21:12 Sunucu2 sshd [31447]: pam_unix (sshd: oturum): oturum kullanıcı tarafından açıldı User1 (uid = 0)
31 Aralık 15:21:12 Sunucu2 sshd [31449]: sftp için alt sistem isteği
31 Aralık 15:21:12 Sunucu2 sudo: Kullanıcı1: TTY = pts / 2; PWD = / ev / Kullanıcı1; USER = root; COMMAND = / 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
31 Aralık 15:21:14 Sunucu2 sshd [31447]: pam_unix (sshd: oturum): oturum User1 kullanıcı için kapatıldı

STRAÇ Çıkışı

Burada, root kullanıcısının ansible komutunu hedeflerken strace çıktısı verilmiştir. Komut:

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`

Sunucu 1

23650 select (0, NULL, NULL, NULL, {1, 508055}) = 0 (Zaman aşımı)
23650 soket (PF_NETLINK, SOCK_RAW, 9) = 10
23650 fcntl (10, F_SETFD, FD_CLOEXEC) = 0
23650 readlink ("/ proc / self / exe", "/ usr / bin / sudo", 4096) = 13
23650 sendto (10, "| \ 0 \ 0L \ 4 \ 5 \ 0 \ 1 \ 0 \ 0 \ 0 \ 0 \ 0P = PAM: otantik" ..., 124, 0, {sa_family = AF_NETLINK, pid = 0, gruplar = 00000000}, 12) = 124
23650 anketi ([{fd = 10, olaylar = POLLIN}], 1, 500) = 1 ([{fd = 10, revents = POLLIN}])
23650 recvfrom (10, "$ \ 0 \ 0 \ 0 \ 2 \ 0 \ 0 \ 0 \ 0 \ 0b \\ \ 0 \ 0 \ 0 \ 0 \ 0 | \ 0 \ 0 \ 0L \ 4 \ 5 \ 0 \ 1 \ 0 \ 0 \ 0 "..., 8988, MSG_PEEK | MSG_DONTWAIT, {sa_family = AF_NETLINK, pid = 0, gruplar = 00000000}, [12]) = 36
23650 recvfrom (10, "$ \ 0 \ 0 \ 0 \ 2 \ 0 \ 0 \ 0 \ 0 \ 0b \\ \ 0 \ 0 \ 0 \ 0 \ 0 | \ 0 \ 0 \ 0L \ 4 \ 5 \ 0 \ 1 \ 0 \ 0 \ 0 "..., 8988, MSG_DONTWAIT, {sa_family = AF_NETLINK, pid = 0, gruplar = 00000000}, [12]) = 36
23650 kapat (10) = 0
23650 write (2, "Üzgünüz, tekrar deneyin. \ N", 18) = 18
23650 gettimeofday ({1420050850, 238344}, NULL) = 0
23650 soket (PF_FILE, SOCK_STREAM, 0) = 10
23650 bağlayın (10, {sa_family = AF_FILE, yol = "/ var / run / dbus / system_bus_socket"}, 33) = 0

Sunucu2

6625 seçin (8, [5 7], [], NULL, NULL) =? ERESTARTNOHAND (Yeniden başlatılacak)
6625 --- SIGCHLD (Çocuk çıkıldı) 0 (0) ---
6625 yazma (8, "\ 21", 1) = 1
6625 rt_sigreturn (0x8) = -1 EINTR (Kesintili sistem çağrısı)
6625 seç (8, [5 7], [], NULL, NULL) = 1 ([7] içinde)
6625 oku (7, "\ 21", 1) = 1
6625 wait4 (6636, [{WIFEXITED (s) && WEXITSTATUS (s) == 0}], WNOHANG | WSTOPPED, NULL) = 6636
6625 rt_sigprocmask (SIG_BLOCK, NULL, [], 8) = 0
6625 soketi (PF_NETLINK, SOCK_RAW, 9) = 6
6625 fcntl (6, F_SETFD, FD_CLOEXEC) = 0
6625 readlink ("/ proc / self / exe", "/ usr / bin / sudo", 4096) = 13
6625 sendto (6, "x \ 0 \ 0R \ 4 \ 5 \ 0 \ 6 \ 0 \ 0 \ 0 \ 0 \ 0P = PAM: session_c" ..., 120, 0, {sa_family = AF_NETLINK, pid = 0, gruplar = 00000000}, 12) = 120
6625 anketi ([{fd = 6, olaylar = POLLIN}], 1, 500) = 1 ([{fd = 6, revents = POLLIN}])
6625 recvfrom (6, "$ \ 0 \ 0 \ 0 \ 2 \ 0 \ 0 \ 6 \ 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_family = AF_NETLINK, pid = 0, gruplar = 00000000}, [12]) = 36
6625 recvfrom (6, "$ \ 0 \ 0 \ 0 \ 2 \ 0 \ 0 \ 6 \ 0 \ 0 \ 330 \ 355 \ 377 \ 377 \ 0 \ 0 \ 0 \ 0x \ 0 \ 0 \ 0R \ 4 \ 5 \ 0 \ 6 \ 0 \ 0 \ 0 "..., 8988, MSG_DONTWAIT, {sa_family = AF_NETLINK, pid = 0, gruplar = 00000000}, [12]) = 36
6625 kapat (6) = 0
6625 açık ("/ etc / güvenlik / pam_env.conf", O_RDONLY) = 6
6625 fstat (6, {st_dev = makedev (253, 1), st_ino = 521434, st_mode = S_IFREG | 0644, st_nlink = 1, st_uid = 0, st_gid = 0, st_blksize = 4096, st_blocks = 8, st_size = 2980, st_atime = 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 oku (6, "# \ n # Bu, yapılandırma fi'dir" ..., 4096) = 2980
6625 oku (6, "", 4096) = 0
6625 kapat (6) = 0
6625 munmap (0x7fbc3a59a000, 4096) = 0
6625 açık ("/ etc / environment", O_RDONLY) = 6

Tahminimce

Sunucu1, şifreyi doğru şekilde almıyor veya yanlış bir şekilde şifre soruyor / beklemiyor. Bu, bir Sudo veya Ansible problemi gibi görünmüyor (yalnız, her ikisi de gayet iyi çalışıyor), ancak Server1, Server2 gibi benzer bir şekilde kimlik bilgilerini (veya onlara bağlı) almıyor gibi görünüyor. Server1 ve 2 farklı amaçlara hizmet eder, bu nedenle bazı kimlik doğrulama veya paket sürümü farklılıkları olabilir, ancak her ikisi de aynı depodan oluşturulmuş olabilir; bu yüzden, bu farklı olmamalılar.

PAM Auth

Sistemlerin, parolaların biraz farklı şekilde ele alınmasına neden olan farklı PAM yapılandırmaları olabileceğini düşündüm. /Etc/pam.d/ dosyalarını ( md5sum [file]) ve iki sistem arasında aynıdır.

Testler

Sudo STDIN

test edilmiş başka bir sorun sudo, STDIN'den bir parola okumadı, ancak bu her iki sunucuda da iyi çalıştı.

Sudo Ad-Hoc'u test et

-bash-4.1 $ ansible Server1 -m dosyası -a "dest = / tmp / ansible_test.txt state = dokunma" -sK
SSH şifresi:
sudo şifresi [varsayılanlar SSH şifresi]:
Sunucu1 | başarı >> {
    "değişti": doğru,
    "dest": "/tmp/ansible_test.txt",
    "gid": 0,
    "grup": "root",
    "mode": "0644",
    "sahip": "kök",
    "size": 0,
    "state": "dosya",
    "kullanıcı": 0
}

Başarı! Ama neden?!

TL; DR

  1. Server1, sudo parola istemi beklerken Server2, yalnızca iyi çalışıyor gibi görünüyor.
  2. Koşu ansible Server1 üzerinde "ad-hoc" iyi çalışıyor. Bir oyun kitabı olarak yayınlamak başarısız.

Soru (lar)

  • Ansible Sudo yapılandırmamın bir sunucuda düzgün çalışmasına ve başka bir konuda reddedilmesine neden olan nedir?
  • Ansible, ad-hoc playbook'u çalıştırırken şifreyi yerelden uzak makineye farklı şekilde "pass" yapar mı? Aynı olacağını düşündüm.

Bunun bir hata raporunu GitHub sayfasına göndererek, sudo erişiminin, geçici çalışıp çalışmadığımı bağlı olarak farklı sonuçlara yol açtığını düşünüyorum.


8
2017-12-31 16:37


Menşei




Cevaplar:


Yapmam gereken şey kullanmak

strace -vfp `pidof sshd`

ve nerede başarısız olduğunu görüyoruz.

Hesabı da kontrol et, belki kısıtlanmış ya da başka bir şey ama benim bahisim, bir şeylerin / etc / hosts dosyanızın yanlış olması ya da süreçte değişmesi.


4
2017-12-31 17:21



Teşekkürler lulian. Soruna birkaç düzenleme yaptım, bir bölüm STrace çıktı. İki sunucu arasında, uzak sunucuda başlatılan ispiyon sürecinden sonra nasıl devam ettikleri konusunda bir fark olduğu açıktır. Sonraki çalışmalar ve iz yakalamaları tutarlıydı. - BrM13
Bu strace -vfp'den daha fazlasına ihtiyacınız olduğunu düşünüyorum, bunu sshd işleminin üstünden el ile gerçekleştirin ve çıktıyı takip edin. Parola okuduktan sonra sanmıyorum ki, PAM'den geçmeden önce böyle bir kanalı kapatıyorum. Bu noktada lütfen sshd_config dosyasına ve hosts.deny'ye bir göz atın. - Iulian
Önerinizi daha önce denedim, ama oradaki önemli unsuru kaçırmam gerekiyordu (bu yüzden ilk STRAZ'DA olası bir süreci izlemeyi tercih ettim). Başka bir işlemden sonra gerçek şifre yerine boş bir {{password}} değişken geçildi. Cevabınız nihayet doğru yolda beni bulduktan sonra ayrı olarak bir "Cevap" göndermeyi tercih etti. - BrM13


Bu cevapta @lulianın dayanak noktası olarak kullanılması, sorun bir haydut haline geldi ansible_sudo_pass: için girilen şifreyi geçersiz kılan group_vars içinde tanımlanmış --ask-sudo-pass.

Aşağıdakileri kullanarak:

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

Onu bulabildim write(4, "{{ password }}\n", 15) girilen şifre yerine geçiyordu. Bazı hızlı aramalardan sonra gerçekten buldum ansible_sudo_pass benim girilen parolamı geçersiz kılan group_vars içinde tanımlanmış.

Herkese bir FYI olarak, ansible_sudo_pass: tanımı öncelikli görünüyor --ask-sudo-pass İlk başta, karşı sezgisel görünüyordu. Sonunda, bu kullanıcı hatasıdır, ancak @ lulian'ın SSH etkileşimini ayıklamanın metodolojisi ile ilişki arasındaki keşif ansible_sudo_pass ve --ask-sudo-pass Dışarıdakiler için çok yararlı olmalı. (İnşallah!)


4
2018-01-05 14:15



Ansible'ın komut satırı seçeneklerine göre dosya tanımlı değişkenlere öncelik verdiğini iddia ediyorum olduğu karşı sezgisel ve kötü davranış. Merakla, seçenekleri ile geçiş yaptığınızda bunun bozuk olduğunu fark eder -eve bununla uygun bir seçeneği geçerek bu konuda çalışabilirsiniz. -e. - Christopher Cashell