Kapan saja dimungkinkan membuat perubahan ke sshd di CentOS7, bermain acak di masa depan tidak dapat terhubung


8

Ini telah menjadi masalah yang cukup menjengkelkan sekarang saya pikir saya akhirnya akan bertanya pada masyarakat luas apa solusi yang mungkin. Lebih menjengkelkan lagi karena saya tampaknya menjadi satu-satunya yang mengalami masalah ini.

Pada dasarnya, kapan saja dalam CentOS 7.x, konfigurasi sshd, atau bagian mana pun dari sshd akan dimodifikasi, dan daemon akan dinyalakan kembali / dimuat kembali di beberapa "titik acak" dalam 3 menit berikutnya, koneksi ssh diatur ulang, dan kemudian server tersebut dihidupkan kembali. tidak dapat dijangkau selama beberapa detik melalui ssh.

Ini terutama masalah untuk memungkinkan dalam hal itu perlu melakukan perubahan ini sendiri untuk sshd kadang-kadang, dan juga memuat ulang (misalnya dalam membangun server CentOS 7x baru). Tapi kemudian di play berikutnya hanya secara acak tidak dapat terhubung ke ssh, dan itu meledak sisa playbook / drama untuk host yang gagal dihubungi. Ini terutama buruk untuk pola host besar, karena beberapa akan selesai secara acak, tetapi yang lain akan gagal pada berbagai tahap di sepanjang buku pedoman setelah sshd dimanipulasi. Perlu dicatat, bahwa hal semacam itu tidak terjadi pada CentOS 5x, 6x, atau bahkan pada Solaris.

Yang terbaik yang bisa saya lakukan untuk menghindari hal ini adalah dengan membuat 90 detik menunggu setelah ada perubahan pada sshd, dan bahkan ini tidak sepenuhnya aman. Itu membuat buku-buku pedoman itu membutuhkan waktu 20 menit untuk dijalankan jika itu dipanggil 7-8 kali.

Berikut ini beberapa fakta di lingkungan ini:

Semua pemasangan baru berasal dari ISO ISO resmi. Setiap server adalah tamu hyper-v 2012 Setiap server yang memiliki masalah ini adalah CentOS 7.x

Berikut adalah beberapa hasil aktual dari masalah dan beberapa solusi yang diretas:

Kesalahan:

fatal: [voltron]: UNREACHABLE! => {"changed": false, "msg": "All items         completed", "results": [{"_ansible_item_result": true, "item": ["rsync", "iotop", "bind-utils", "sysstat.x86_64", "lsof"], "msg": "Failed to connect to the host via ssh: Shared connection to voltron closed.\r\n", "unreachable": true}]}

Contoh salah satu perubahan ke sshd:

- name: Configure sshd to disallow root logins for security purposes on CentOS and Redhat 7x servers.
    lineinfile:
      backup: yes
      dest: /etc/ssh/sshd_config
      regexp: '^(#PermitRootLogin)'
      line: "PermitRootLogin no"
      state: present
    when: (ansible_distribution == "CentOS" or "RedHat") and (ansible_distribution_major_version == "7")
    notify: sshd reload Linux 7x

Pawang berikut:

- name: sshd reload Linux 7x
   systemd:
     state: restarted
     daemon_reload: yes
     name: sshd

Akhirnya perbaikan ghetto saya untuk mencoba dan menjelaskan masalah ini:

- name: Wait a bit on CentOS/Redhat 7x servers to ensure changes don't mess up ssh and screw up further plays.
    pause:
      seconds: 90
    when: (ansible_distribution == "CentOS" or "RedHat") and (ansible_distribution_major_version == "7")

Harus ada solusi yang lebih baik daripada yang saya temukan, dan sulit untuk percaya bahwa semua orang menemukan ini dan juga bertahan dengan itu. Apakah ada sesuatu yang perlu saya konfigurasi di server CentOS 7.x untuk mencegah hal ini? Apakah ada sesuatu yang mungkin yang diperlukan untuk mengatasi hal ini, seperti beberapa upaya ssh per permainan pada kegagalan pertama?

Terima kasih sebelumnya!


1
Apakah Anda yakin telah melihatnya mengatur ulang koneksi ssh yang ada ? Biasanya, memulai ulang ssh tidak seharusnya mempengaruhi koneksi yang ada, jadi ini mungkin semacam petunjuk.
sourcejedi

Silakan tentukan versi ansible tepat Anda menggunakan (misalnya jika ada adalah bug dalam modul systemd, orang akan tertarik versi apa itu di).
sourcejedi

@sourcejedi ansible --version ansible 2.2.0.0 file config = /etc/ansible/ansible.cfg jalur pencarian modul yang dikonfigurasikan = Default tanpa ditimpa Ya, maksud saya "bisa" menjadi bug, tetapi jika demikian, mengapa saya satu-satunya yang mengalaminya? Kecuali jika tidak ada orang lain di luar sana yang menggunakan CentOS 7x dengan memungkinkan .... Namun Anda benar bahwa penyegaran layanan tidak akan memengaruhi koneksi yang ada. Memang, pada server CentOS 6x saya, semuanya bekerja dengan sempurna di playbook yang sama.
Viskositas

Ketika Anda mengatakan itu restart - dalam log sistem, apakah hanya itu yang Anda dapatkan? Atau apakah systemd melaporkan sshd yang keluar, dan dimulai kembali menurut Restart=on-failure? Jika demikian, apa status keluarnya? Dan apakah sshd tidak mencatat pesan kesalahan apa pun?
sourcejedi

Ini bukan masalah Ansible, tetapi SSH atau beberapa masalah jaringan. Memulai ulang SSH tidak memengaruhi koneksi SSH saat ini, jadi ada hal lain yang sedang dimainkan. Sudahkah Anda mencoba menghubungkan SSH secara teratur dari terminal, menyalakan kembali sshddan apa yang terjadi dengan koneksi Anda? Anda juga menggunakan SSH ControlMasterdengan Ansible? Anda dapat mengaktifkannya di ansible.cfg ssh_args = -o ControlMaster=auto -o ControlPersist=60s.
Strahinja Kustudic

Jawaban:


0

Daripada menggunakan systemdmodul, coba servicemodul:

- name: Restart secure shell daemon post configuration
  service: 
    name: sshd
    state: restarted

1
Menarik, saya akan mencobanya dan kembali ke halaman ini untuk memberi tahu orang. Tapi bukankah modul layanan hanya memanipulasi biner "layanan" yang benar-benar hanya diarahkan melalui systemctl? Yah, aku akan mencobanya.
Viskositas

DopeGhoti, sayangnya saran Anda tidak berhasil. Saya mendapatkan masalah yang sama persis seperti sebelumnya, dan tampaknya tidak tergantung modul antara layanan, atau modul systemd. Adakah yang punya saran?
Viskositas

0

Ini tampaknya menjadi masalah umum. Patch untuk ssh coba lagi Anshs mulai 2016

Solusi yang lebih baik mungkin menunggu sshd siap untuk terhubung. Utas asli dengan solusi kode yang memungkinkan ini:

[Tugas pembuatan VM ...]

  - name: Tunggu instalasi Kickstart selesai dan VM untuk reboot local_action: wait_for host = {{vm_hostname}} port = 22 penundaan = 30 batas waktu = 1200 keadaan = dimulai

  - nama: Sekarang konfigurasikan VM ...

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.