मुझे हर बूट के बाद / var / run / sshd क्यों याद आ रहा है?

Question

मैं एक Ubuntu 16.04 कंटेनर को Proxmox 5.2-11 के तहत चला रहा हूं। पैच के नवीनतम दौर को लागू करने के बाद 1 मैं कंसोल पर या ssh पर लॉगिन करने में असमर्थ हूं।

मैं हाइपरविजर पर कंटेनर जड़ एफएस घुड़सवार और कहा 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और वे फाइलें मौजूद नहीं हैं

Answer 1

आपके sshdद्वारा की गई एक गलती हाथ से शुरू करने की कोशिश कर रही थी।

यदि आप इसके बजाय sshdआधिकारिक माध्यम से शुरू करते हैं तो यह सिर्फ काम करना चाहिए। serviceआदेश जानता है क्या सही तरीका है अपने वितरण पर एक सेवा शुरू करने के लिए है, और यह काम करना चाहिए:

service ssh start

Sysv init स्क्रिप्ट के मामले में, यह वह सब कुछ है जो आपको करने की आवश्यकता है। निर्देशिका गायब होने का कारण यह है कि /var/runएक सिम्लिंक है /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मैन्युअल रूप से चलाते हैं, तो यह सत्यापित कर सकता है कि यह बनाया गया है या नहीं ।

Comments

यह एक अच्छा विचार है लेकिन अनिवार्य रूप से वही काम कर रहा है जो सिस्टम ने बूट पर करने की कोशिश की (और उसी तरह असफल रहा)। मैं वास्तव में इस बारे में सोच रहा हूं कि क्यों सामान्य तरीके से निजी निर्देशिका नहीं बनाई जा रही है। क्या कोई डिस्क त्रुटि है? एक अनुमति मुद्दा? लॉक फ़ाइल? कहीं और देखने के अलावा journalctl?

— सर्वर दोष

@ServerFault कुछ परिस्थितियों /etc/init.d/sshमें नहीं चलाया systemctlजाएगा और इसके बजाय उपयोग किया जाएगा। और जब निर्देशिका के sshdमाध्यम से शुरू किया जाता systemctlहै तो नहीं बनाया जाता है। यह कुछ खुले प्रश्नों को छोड़ता है जो मैं कल में खोदने की कोशिश करूंगा जैसे कि वास्तव में क्या बदल गया है और इसका उपयोग करने के लिए वास्तव में उस निर्देशिका को कैसे बनाया जाना चाहिए systemctl।

— कास्परड नोव

@ServerFault systemctlइसका उपयोग करते समय /etc/init/ssh.confजो निर्देशिका बनाने के लिए जिम्मेदार है। मैंने Ubuntu 16.04 को पूरी तरह से अद्यतित किया और बूट के दौरान निर्देशिका बनाई गई। लेकिन किसी कारण से यह उपयोग करते समय निर्मित नहीं होता है service ssh start। कुछ systemdसंबंधित पैकेजों के हालिया अपडेट हैं, लेकिन मुझे उस निर्देशिका के निर्माण के बारे में व्यवहार के कोई सबूत नहीं दिख रहे हैं। और जब मैं परीक्षण करता हूं तो यह बूट के दौरान निर्मित हो जाता है। तो सवाल तो यह है कि क्या आपके /etc/init/ssh.confपास सही सामग्री है।

— कास्परड नोव

@ServerFault मैं गलत हो सकता है कि इसके बारे /etc/init/ssh.confमें भी /usr/lib/tmpfiles.d/sshd.confइस्तेमाल किया जा रहा है systemd-tmpfiles --create। है systemd-tmpfiles --createयाद आ रही बनाने /var/run/sshdनिर्देशिका?

— कास्परड

systemd-tmpfiles --createआउटपुट से प्रश्न करने के लिए जोड़ा गया चित्र । "Symlinks" systemd के बारे में शिकायत है (/tmp/.X11-unix) भी मौजूद नहीं है /tmp/इसलिए मुझे नहीं पता कि यह कहाँ से मिल रहा है। उस पर आपकी सभी मदद के लिए धन्यवाद, लेकिन मुझे लगता है कि मैं आगे बढ़ने जा रहा हूं।

— सर्वर फॉल्ट

Answer 2

तो / रन (और / / var / रन सहानुभूति के लिए) हर रिबूट को फिर से बनाया जाता है। सिवाय इसके कि 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

और बस..!

और जब ओपनश-सर्वर अपग्रेड हो जाता है, तो हम आशा करते हैं कि उन्होंने इस बग को ठीक कर दिया होगा (या क्या यह सिस्टम बग में वाकई बग है? या ओपनवेज़ ??) - अन्यथा आप उसी समस्या में भाग सकते हैं।

Comments

कर्नेल उन्नयन की प्रतीक्षा करते हुए फिक्स के लिए +1। मेरे मामले में इसे बनने की जरूरत थी: "d / run / sshd 0755 रूट रूट"

— paulzag

@ अंपुलजग ने मेरे लिए भी काम किया। मुझे आश्चर्य है कि अगर @ pepa65 कहने का मतलब है d /run/sshd 0755 root root, क्योंकि उनके निर्देश केवल /varभाग को हटाने के लिए कहते हैं (भले ही कोड वे उत्तर में देते हैं दोनों /varको /runहटा दिया गया है)।

— स्टीफन श्रुगर 15

Answer 3

जब यह OpenVZ कर्नेल 2.6.32-042stab134.7 या नया चला रहा हो, तो इसका समाधान हो जाता है। मुझे यह अजीब लगता है कि किसी भी तरह से सिस्टमड स्टार्ट स्क्रिप्ट में कोई फिक्स संभव नहीं है। संभवतः एक बदसूरत हैक जैसे स्वचालित रूप से बनाना / चलाना / 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 का चैंज यह कहता है:

सिस्टमड 229-4ubuntu21.9 के साथ उबंटू कंटेनर चलाने से सेवाओं को शुरू करने में विफलता हो सकती है क्योंकि सिम्डलिंग मुद्दों के कारण सिस्टमड-टैम्पिल्स पथ को मान्य करने में असमर्थ थे। (PSBM-90038)

Answer 4

वर्षों से सिस्टमड के साथ जितनी परेशानी हुई है, उसके लिए मुझे इस मुद्दे को स्वीकार करना चाहिए बजाय इसके कि एन्सिबल सिंक्रोनाइज़ निर्देश से।

किसी कारण से, हमारी होस्ट स्क्रिप्ट के साथ इस होस्ट को प्रोविज़न करने के बाद, यह एक व्यवस्थापक उपयोगकर्ता के स्वामित्व वाली / निर्देशिका (साथ ही / आदि, / ऑप्ट और अन्य) को छोड़ दिया, और रूट नहीं। chownचीजों को सही करने के लिए चलने के बाद , /var/run/sshdअब फिर से बूट पर बनाया जाता है।

मैं वास्तव में सभी इनपुट की सराहना करता हूं, लेकिन यहां कोई बग नहीं है, कम से कम इस अर्थ में कि रूट निर्देशिका में अनुचित स्वामित्व को लागू करने से अपरिभाषित सिस्टम व्यवहार हुआ।

Comments

यह! टिप के लिए धन्यवाद, हमारे मामले में भी दोषी अपराधी था!

— बीनिश खान