ทำไมฉันหายไป / var / run / sshd หลังจากบูตทุกครั้ง


14

ฉันใช้งาน Ubuntu 16.04 container ภายใต้ Proxmox 5.2-11 หลังจากใช้ชุดข้อมูลแก้ไขรอบล่าสุด1ฉันไม่สามารถลงชื่อเข้าใช้ที่คอนโซลหรือผ่าน ssh ได้

ฉันเมานต์รูทคอนเทนเนอร์ FS บนไฮเปอร์ไวเซอร์และเพิ่มลงpts/0ใน/etc/security/access.conf(เราเรียกใช้pam_access) และอนุญาตให้รูทล็อกอินเข้าสู่คอนโซล เราได้root : lxc/tty0 lxc/tty1 lxc/tty2ในaccess.confซึ่งผมคิดว่าเพียงพอดังนั้นทำไมฉันต้องการpts/0ตอนนี้คือการทำให้งง

ฉันสังเกตว่า ssh ไม่ทำงานดังนั้นลองเริ่มด้วยมือ ( /usr/sbin/sshd -DDD -f /etc/ssh/sshd_config) และได้รับข้อผิดพลาดนี้:

Missing privilege separation directory: /var/run/sshd

ฉันสร้างไดเรกทอรีด้วยมือเริ่มต้นsshและสามารถเข้าสู่ระบบได้ในที่สุด แต่หลังจากรีบูตปัญหายังคงมีอยู่ ไม่ได้สร้างไดเรกทอรี บิตที่มีประโยชน์เท่านั้นjournalctlและส่วนที่น่าสนใจเพียงอย่างเดียวคือ "การดำเนินการที่ไม่อนุญาต" แต่ไม่มีข้อมูลเพิ่มเติม

ฉันไม่คุ้นเคยกับ 16.04 ดังนั้นสงสัยว่าฉันจะหาข้อมูลเพิ่มเติมเกี่ยวกับปัญหาได้อย่างไร ฉันไม่มี/var/log/syslogหรือ/var/log/messagesเพียงkern.logเพื่อให้ชนิดของที่หายไป

1

systemd-sysv 229-4ubuntu21.9
libpam-systemd 229-4ubuntu21.9
libsystemd0 229-4ubuntu21.9
systemd 229-4ubuntu21.9
udev 229-4ubuntu21.9
libudev1 229-4ubuntu21.9
iproute2 4.3.0-1ubuntu3.16.04.4
libsasl2-modules-db 2.1.26.dfsg1-14ubuntu0.1
libsasl2-2 2.1.26.dfsg1-14ubuntu0.1
ldap-utils 2.4.42dfsg-2ubuntu3.4
libldap-2.4-2 2.4.42dfsg-2ubuntu3.4
libsasl2-modules 2.1.26.dfsg1-14ubuntu0.1
libgs9-common 9.25dfsg1-0ubuntu0.16.04.3
ghostscript 9.25dfsg1-0ubuntu0.16.04.3
libgs9 9.25dfsg1-0ubuntu0.16.04.3

[2]

Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[474]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:48 host16 mysqld_safe[495]: Starting mysqld daemon with databases from /var/lib/mysql/mysql
Nov 27 10:13:48 host16 mysqld[500]: 181127 10:13:48 [Note] /usr/sbin/mysqld (mysqld 10.0.36-MariaDB-0ubuntu0.16.04.1) starting as process 499 ...
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:48 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: Failed to reset devices.list on /system.slice/ssh.service: Operation not permitted
Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[502]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:48 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: Failed to reset devices.list on /system.slice/ssh.service: Operation not permitted
Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[503]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:48 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: Failed to reset devices.list on /system.slice/ssh.service: Operation not permitted
Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[504]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:49 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Start request repeated too quickly.
Nov 27 10:13:49 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Failed with result 'start-limit-hit'.
Nov 27 10:13:49 host16 systemd[1]: Started /etc/rc.local Compatibility.
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/plymouth-quit.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Starting Terminate Plymouth Boot Screen...
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/plymouth-quit-wait.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Starting Hold until boot process finishes up...
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/rc-local.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Started Hold until boot process finishes up.
Nov 27 10:13:49 host16 systemd[1]: Started Container Getty on /dev/pts/1.
Nov 27 10:13:49 host16 systemd[1]: Started Container Getty on /dev/pts/0.
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/console-getty.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Started Console Getty.
Nov 27 10:13:49 host16 systemd[1]: Reached target Login Prompts.
Nov 27 10:13:49 host16 systemd[1]: Started Terminate Plymouth Boot Screen.
Nov 27 10:13:52 host16 nslcd[338]: accepting connections
Nov 27 10:13:52 host16 nslcd[275]:    ...done.
Nov 27 10:13:52 host16 systemd[1]: Started LSB: LDAP connection daemon.
Nov 27 10:13:52 host16 systemd[1]: Failed to reset devices.list on /system.slice/cron.service: Operation not permitted
Nov 27 10:13:52 host16 systemd[1]: Started Regular background program processing daemon.
Nov 27 10:13:52 host16 systemd[1]: Failed to reset devices.list on /system.slice/atd.service: Operation not permitted

เพิ่มsystemd-tmpfiles --createเอาท์พุท

น่าแปลกจริงๆ .... ฉันตรวจสอบ/tmpแล้วและไม่มีไฟล์เหล่านั้น ป้อนคำอธิบายรูปภาพที่นี่

คำตอบ:


11

คุณทำผิดพลาดอย่างหนึ่งคือพยายามเริ่มsshdด้วยมือ

หากคุณเริ่มต้นsshdอย่างเป็นทางการหมายความว่ามันควรจะทำงาน serviceคำสั่งรู้ว่าสิ่งที่วิธีที่ถูกต้องเริ่มให้บริการเกี่ยวกับการกระจายของคุณเป็นและนี้ควรจะทำงาน:

service ssh start

ในกรณีของสคริปต์ sysv init นั่นคือทุกสิ่งที่คุณต้องทำ เหตุผลที่ทำให้ไดเร็กทอรีขาดหายไปนั่น/var/runคือ symlink ไป/runและ/runเป็นtmpfsจุดเชื่อมต่อ นั่นหมายความว่าในการบู๊ตแต่ละครั้ง/var/runจะเริ่มว่างเปล่า เมื่อคุณใช้serviceคำสั่ง/etc/init.d/sshสคริปต์จะถูกใช้เพื่อเริ่มต้นsshdแต่ก่อนที่จะทำสคริปต์นั้นจะสร้างขึ้น/var/run/sshdหากไม่มีอยู่

ด้วยsystemdสิ่งที่ทำงานแตกต่างกันเล็กน้อย จะมีไฟล์ที่เรียกว่า/usr/lib/tmpfiles.d/sshd.confมีเนื้อหานี้:

d /var/run/sshd 0755 root root

ในระหว่างการบูทสิ่งนี้จะทำให้/var/run/sshdไดเรกทอรีถูกสร้างขึ้น สิ่งที่คุณต้องตรวจสอบว่าไฟล์นั้นมีอยู่และมีเนื้อหาที่ถูกต้อง หาก/var/run/sshdไดเรกทอรียังคงหายไปคุณสามารถตรวจสอบว่ามันถูกสร้างขึ้นเมื่อคุณรันsystemd-tmpfiles --createด้วยตนเอง


นั่นเป็นความคิดที่ดี แต่กำลังทำสิ่งเดียวกันกับที่ระบบพยายามจะทำการบูท (และล้มเหลวในลักษณะเดียวกัน) สิ่งที่ฉันสงสัยจริงๆก็คือสาเหตุที่ทำให้ไดเรกทอรี privsep ไม่ได้ถูกสร้างขึ้นด้วยวิธีการปกติ มีข้อผิดพลาดของดิสก์หรือไม่ ปัญหาการอนุญาตหรือไม่ ล็อคไฟล์หรือไม่ มีสถานที่อื่นนอกเหนือจากที่อื่นjournalctlหรือไม่
ข้อผิดพลาดเซิร์ฟเวอร์

@ServerFault ในบางกรณี/etc/init.d/sshจะไม่สามารถใช้งานได้และsystemctlจะถูกใช้แทน และเมื่อsshdไม่ได้เริ่มต้นผ่านsystemctlไดเรกทอรีจะไม่ถูกสร้างขึ้น นั่นเป็นคำถามเปิดสองสามข้อที่ฉันจะพยายามขุดลงไปในวันพรุ่งนี้เช่นสิ่งที่เปลี่ยนไปและสิ่งที่ควรจะสร้างเมื่อsystemctlใช้ไดเรกทอรี
kasperd

@ServerFault เมื่อใช้systemctlมัน/etc/init/ssh.confเป็นหน้าที่รับผิดชอบในการสร้างไดเรกทอรี ฉันทดสอบ Ubuntu 16.04 ที่อัปเดตอย่างสมบูรณ์แล้วและไดเรกทอรีจะถูกสร้างขึ้นระหว่างการบู๊ต service ssh startแต่ด้วยเหตุผลบางอย่างมันไม่ได้รับการสร้างขึ้นเมื่อใช้ มีการอัปเดตล่าสุดของsystemdแพคเกจที่เกี่ยวข้องบางอย่างแต่ฉันไม่เห็นหลักฐานของพฤติกรรมที่เกี่ยวข้องกับการสร้างไดเรกทอรีที่มีการเปลี่ยนแปลง และเมื่อฉันทดสอบมันจะถูกสร้างขึ้นระหว่างการบูท ดังนั้นคำถามคือถ้าคุณ/etc/init/ssh.confมีเนื้อหาที่ถูกต้อง
kasperd

@ServerFault ผมอาจจะได้รับความเข้าใจผิดเกี่ยวกับการ/etc/init/ssh.confนอกจากนี้ยังมีซึ่งดูเหมือนจะถูกใช้โดย/usr/lib/tmpfiles.d/sshd.conf systemd-tmpfiles --createไม่systemd-tmpfiles --createสร้างหายไป/var/run/sshdไดเรกทอรี?
kasperd

เพิ่มรูปคำถามจากsystemd-tmpfiles --createผลลัพธ์ "symlinks" systemd กำลังบ่นเกี่ยวกับ (/tmp/.X11-unix) ไม่มีอยู่ใน/tmp/นั้นดังนั้นฉันจึงไม่รู้ว่ามันมาจากไหน ขอบคุณสำหรับความช่วยเหลือทั้งหมดของคุณ แต่ฉันคิดว่าฉันจะเดินหน้าต่อไป
ข้อผิดพลาดของเซิร์ฟเวอร์

11

ดังนั้น / run (และ / var / run เชื่อมโยงกับมัน) จะได้รับการสร้างใหม่ทุกครั้งที่รีบูต ยกเว้นว่า systemd-tmpfiles ไม่ได้ทำเช่นนั้นสำหรับบางไฟล์รวมถึง (/ var) / run / sshd

เห็นได้ชัดว่าสิ่งนี้ได้รับการแก้ไขโดยการอัพเกรดเคอร์เนล OpenVZ แต่การแก้ไขจริงตอนนี้คุณแก้ไข/usr/lib/tmpfiles.d/sshd.confและลบ/varจากบรรทัดd /var/run/sshd 0755 root rootเพื่ออ่านแทน: d /run/sshd 0755 root root

และนั่นมัน .. !

และเมื่อ openssh-server ได้รับการอัพเกรดเราหวังว่าพวกเขาจะแก้ไขข้อผิดพลาดนี้ (หรือเป็นข้อบกพร่องใน systemd? หรือ openvz ??) - มิฉะนั้นคุณอาจพบปัญหาเดียวกัน


1
+1 สำหรับการแก้ไขในขณะที่รอการอัปเกรดเคอร์เนล ในกรณีของฉันจำเป็นต้องกลายเป็น: "d / run / sshd 0755 root root"
paulzag

1
@paulzag นั่นก็ใช้ได้กับฉันเช่นกัน ฉันสงสัยว่า @ pepa65 หมายถึงว่าd /run/sshd 0755 root rootตั้งแต่เส้นทางของพวกเขาบอกว่าจะลบเฉพาะ/varส่วน (แม้ว่ารหัสที่พวกเขาให้ในคำตอบมีทั้ง/varและ/runออก)
Stephen Schrauger

4

เห็นได้ชัดว่าสิ่งนี้ได้รับการแก้ไขเมื่อใช้งานเคอร์เนล OpenVZ 2.6.32-042stab134.7 หรือใหม่กว่า ฉันคิดว่ามันแปลกที่ไม่มีการแก้ไขใด ๆ ที่เป็นไปได้ในสคริปต์เริ่ม systemd อย่างใด อาจแฮ็กที่น่าเกลียดอย่างเช่นการสร้าง / run / sshd / โดยอัตโนมัติหลังจากเริ่มต้นแล้วการเริ่มต้น sshd จะทำงานได้

ผลลัพธ์ของฉันsystemd-tmpfiles --create:

[/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
fchownat() of /run/named failed: Invalid argument
Failed to openat(/dev/simfs): Operation not permitted
Failed to validate path /var/run/screen: Too many levels of symbolic links
Failed to validate path /var/run/sshd: Too many levels of symbolic links
Failed to validate path /var/run/sudo: Too many levels of symbolic links
Failed to validate path /var/run/sudo/ts: Too many levels of symbolic links
fchownat() of /run/systemd/netif failed: Invalid argument
fchownat() of /run/systemd/netif/links failed: Invalid argument
fchownat() of /run/systemd/netif/leases failed: Invalid argument
fchownat() of /run/log/journal failed: Invalid argument
fchownat() of /run/log/journal/e9e1d08bc42c48999865b96c250f40cc failed: Invalid argument
fchownat() of /run/log/journal/e9e1d08bc42c48999865b96c250f40cc/system.journal failed: Invalid argument

การเปลี่ยนแปลงของ OpenVZ 2.6.32-042stab134.7 กล่าวว่า:

การเรียกใช้คอนเทนเนอร์ของ Ubuntu ด้วย systemd 229-4ubuntu21.9 อาจทำให้บริการไม่สามารถเริ่มทำงานได้เนื่องจาก systemd-tmpfiles ไม่สามารถตรวจสอบเส้นทางได้เนื่องจากปัญหาการเชื่อมโยง (PSBM-90038)


2

สำหรับปัญหามากที่สุดเท่าที่ฉันเคยมีกับ systemd ในช่วงหลายปีที่ผ่านมาฉันต้องยอมรับปัญหานี้เกิดขึ้นแทนจากคำสั่งประสาน Ansible

ด้วยเหตุผลบางอย่างหลังจากจัดเตรียมโฮสต์นี้ด้วยสคริปต์ ansbile ของเรามันจะออกจากไดเรกทอรี / (รวมถึง / etc, / opt และอื่น ๆ ) ที่เป็นเจ้าของโดยผู้ใช้ที่ไม่ใช่ผู้ดูแลระบบ หลังจากทำงานchownเพื่อแก้ไขสิ่งต่าง ๆ/var/run/sshdตอนนี้จะถูกสร้างขึ้นในการบูตอีกครั้ง

ฉันขอขอบคุณอินพุตทั้งหมด แต่ไม่มีข้อผิดพลาดที่นี่อย่างน้อยก็ในแง่ที่ว่าการใช้ความเป็นเจ้าของที่ไม่เหมาะสมกับไดเรกทอรีรากทำให้เกิดพฤติกรรมของระบบที่ไม่ได้กำหนด


นี้! ขอบคุณสำหรับเคล็ดลับ Ansible ก็เป็นผู้ร้ายในกรณีของเราเช่นกัน!
Beenish Khan
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.