SSH सर्वर रिबूट के बाद काम करना बंद कर देता है, जो गुम / var / run / sshd के कारण होता है

23

मेरे VPS को लगभग 3 महीने तक रिबूट नहीं किया गया था। यह OpenVZ वर्चुअलाइजेशन प्रकार वाले सर्वर पर होस्ट किया गया है और ऑपरेटिंग सिस्टम Ubuntu 16.04 है। किसी कारण से, मैंने VPS को रिबूट किया और उसके बाद, मैं ssh के माध्यम से सर्वर से कनेक्ट नहीं कर सका, जो संदेश मुझे मिला:

ssh: connect to host srvname.com port 22: Connection refused

इसलिए मैंने VPS पर एक सीरियल कंसोल खोला और जांच शुरू कर दी ... मैंने openssh-serverकोई सफलता नहीं मिलने के साथ ही उसे शुद्ध और पुन: स्थापित किया है । मैंने इंटरनेट पर इसी तरह के मुद्दों के बारे में लेख, प्रश्न और उत्तर पढ़ने में दो घंटे बिताए।

अंत में मैं यह समझने में कामयाब रहा कि /var/run/sshdसिस्टम स्टार्टअप के दौरान निर्देशिका नहीं बनाई गई है। और एक बार जब मैं इसे मैन्युअल रूप से बना लेता हूं तो मैं बिना किसी समस्या के एसएसएच सेवा शुरू कर सकता हूं, लेकिन अगले रिबूट पर समस्या बनी हुई है। तो मेरे सवाल हैं:

  • इस मुद्दे का कारण क्या हो सकता है? /var/run/sshdसिस्टम स्टार्टअप के दौरान क्यों नहीं बनाया जाता है?

  • मैं समस्या का उचित तरीके से समाधान कैसे कर सकता हूं? मुझे एक अस्थायी समाधान मिला जो इस पोस्ट के अंत में उल्लिखित है।

  • क्या यह मुद्दा वीपीएस के ओपनवीजेड मेजबान से संबंधित हो सकता है? क्या मुझे होस्टिंग प्रदाता से इसे हल करने के लिए कहना चाहिए?

के उत्पादन systemctl status ssh.service, sshd -Ddp 22और journalctl -xeहै:

# systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: failed (Result: start-limit-hit) since вт 2019-01-15 12:58:08 EET; 22s ago
  Process: 407 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255)

яну 15 12:58:07 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
яну 15 12:58:07 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 12:58:07 srvname systemd[1]: ssh.service: Failed with result 'exit-code'.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
яну 15 12:58:08 srvname systemd[1]: Stopped OpenBSD Secure Shell server.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Start request repeated too quickly.
яну 15 12:58:08 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Failed with result 'start-limit-hit'.


# $(which sshd) -Ddp 22
debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: private host key #0: ssh-rsa SHA256:...
debug1: private host key #1: ssh-dss SHA256:...
debug1: private host key #2: ecdsa-sha2-nistp256 SHA256:...
debug1: private host key #3: ssh-ed25519 SHA256:...
Missing privilege separation directory: /var/run/sshd


# journalctl -xe
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has begun starting up.
яну 15 13:21:21 srvname sshd[1688]: Missing privilege separation directory: /var/run/sshd
яну 15 13:21:21 srvname systemd[1]: ssh.service: Control process exited, code=exited status=255
яну 15 13:21:21 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has failed.
-- 
-- The result is failed.
яну 15 13:21:21 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 13:21:21 srvname systemd[1]: ssh.service: Failed with result 'exit-code'.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
яну 15 13:21:22 srvname systemd[1]: Stopped OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has finished shutting down.
яну 15 13:21:22 srvname systemd[1]: Starting OpenBSD Secure Shell server...
-- Subject: Unit ssh.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has begun starting up.
яну 15 13:21:22 srvname sshd[1691]: Missing privilege separation directory: /var/run/sshd
яну 15 13:21:22 srvname systemd[1]: ssh.service: Control process exited, code=exited status=255
яну 15 13:21:22 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has failed.
-- 
-- The result is failed.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Failed with result 'exit-code'.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
яну 15 13:21:22 srvname systemd[1]: Stopped OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has finished shutting down.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Start request repeated too quickly.
яну 15 13:21:22 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has failed.
-- 
-- The result is failed.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Failed with result 'start-limit-hit'.

की सामग्री /usr/lib/tmpfiles.d/sshd.confऔर /etc/init/ssh.confहै:

# cat /usr/lib/tmpfiles.d/sshd.conf 
d /var/run/sshd 0755 root root

# cat /etc/init/ssh.conf | sed '/^#/ d'

description "OpenSSH server"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
respawn limit 10 5
umask 022

env SSH_SIGSTOP=1
expect stop

console none

pre-start script
    test -x /usr/sbin/sshd || { stop; exit 0; }
    test -e /etc/ssh/sshd_not_to_be_run && { stop; exit 0; }

    mkdir -p -m0755 /var/run/sshd
end script

exec /usr/sbin/sshd -D

सिस्टम के बारे में अतिरिक्त जानकारी:

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.5 LTS
Release:    16.04
Codename:   xenial

# uname -a
Linux srvname 2.6.32-042stab127.2 #1 SMP Thu Jan 4 16:41:44 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux

# apt show openssh-server | grep 'Version'
Version: 1:7.2p2-4ubuntu2.6

अस्थायी समाधान: मैंने पाया कि /var/runयह एक प्रतीकात्मक कड़ी है /run, मुझे नहीं पता कि इसकी आवश्यकता क्यों है, लेकिन जब मैंने फ़ाइल की सामग्री को इसमें /usr/lib/tmpfiles.d/sshd.confसे संशोधित किया :

d /var/run/sshd 0755 root root

सेवा मेरे:

d /run/sshd 0755 root root

सिस्टम स्टार्टअप पर सब कुछ ठीक हो जाता है, एसएसएच सेवा सामान्य रूप से शुरू हो जाती है और मैं एसएसएच के माध्यम से लॉग-इन करने में सक्षम हूं।

16.04  server  ssh  startup  openvz 
— pa4080
स्रोत
यह समस्या अचानक रिबूट के बाद दिखाई दे सकती है क्योंकि एक संस्करण अपग्रेड जो उस रिबूट से ठीक पहले किया गया था, जैसा कि इस लिंक किए गए प्रश्न में वर्णित है । सबक: अपग्रेड न करें जब तक कि आप सुनिश्चित न हों कि आपका कर्नेल इसका समर्थन कर सकता है।
— हिम

जवाबों:

24

मैंने पाया कि यह सिस्टमड और पुराने कर्नेल के मौजूदा संस्करण के साथ एक बग है जो कुछ VPS के निजीकरण द्वारा उपयोग किया जाता है जैसा कि मेरे मामले में है। यह बग समय-समय पर प्रकट होता है, जैसा कि हम लॉन्चपैड पर देख सकते हैं: बग # 45234 , बग # 1811580 ; या सर्वरफॉल्ट पर: मैं हर बूट के बाद / var / run / sshd को क्यों याद कर रहा हूं?

इस समस्या के कुछ वर्कअराउंड हैं, वे सभी /var/run/sshdएसएसएच सर्वर को चलाने से पहले बनाने के लिए वैकल्पिक तरीके से एक साथ आते हैं । यहां तीन संभावित उपाय दिए गए हैं।

समाधान 1:/usr/lib/tmpfiles.d/sshd.conf निम्न तरीके से संशोधित करें :

d /run/sshd 0755 root root

जैसा कि यह प्रश्न में उल्लेख किया गया है, /var/runएक प्रतीकात्मक लिंक है /run, अंतिम परिणाम समान है: /var/run/sshdबनाया गया है। मुझे नहीं पता कि क्यों, लेकिन यह काम करता है।

समाधान 2: क्रोन जॉब का उपयोग करें /var/run/sshdजो SSH सर्वर का निर्माण और पुनः आरंभ करेगा , आप crontabइस उद्देश्य के लिए रूट का उपयोग कर सकते हैं - sudo crontab -eनिम्नलिखित प्रविष्टि को निष्पादित और जोड़ें:

@reboot mkdir -p -m0755 /var/run/sshd && systemctl restart ssh.service

वर्तमान में मैं इस समाधान का उपयोग कर रहा हूं, इसलिए इसका परीक्षण भी किया जाता है।

वर्कअराउंड 3:/etc/rc.local उपरोक्त के समान करने के लिए उपयोग करें , जैसा कि बग टिप्पणी में इस टिप्पणी में दिखाया गया है # 45234।

— pa4080
स्रोत
1
धन्यवाद, जो ssh को ठीक करता है लेकिन सिस्टमड की व्यापक समस्याओं को तोड़ा नहीं जा रहा है। Systemd-tmpfiles --create चलाने की कोशिश करें और सभी त्रुटियों को देखने
— paulzag
1
आप सही कह रहे हैं, @paulzag, लेकिन मेरे मामले में मुझे यकीन है कि सामान्य समस्या पुरानी कर्नेल है। मैंने इन त्रुटियों को systemd-tmpfiles --createदिखाने का फैसला किया है , क्योंकि इस समय सर्वर पर कोई भी समझदार खराबी नहीं हैं। वर्तमान सवाल यह है कि रिबूट के बाद SSH सेवा को कैसे चालू किया जाए जबकि समस्या लगी हुई है। यदि आप चाहें तो समाधान को
— बढ़ा
"वर्कअराउंड 1" ने मेरे लिए काम किया ... धन्यवाद ... अप वोटेड ...
— बिस्वदीप सरकार
2
इसे सीधे सीधे संशोधित करने के बजाय ओवरराइड करना अधिक उचित होगा /usr/lib/tmpfiles.d/sshd.conf, क्योंकि उस फाइल को पैकेज मैनेजर द्वारा प्रबंधित किया जाता है। ऐसा करने के लिए, बस में परिवर्तन करें /etc/tmpfiles.d/sshd.conf; इस पर वरीयता दी जाएगी sshd.confमें /usr/lib। इस अनुभाग को tmpfiles.d (5) में देखें । महान जवाब की परवाह किए बिना, एक OpenVZ VPS पर होने के नाते ठीक उसी स्थिति में है जिसका मैंने इसमें सामना किया है।
— ZeroKnight
1
के रूप में क्यों वर्कअराउंड 1 काम करता है; आप सीलिंक का उपयोग करने से बच रहे हैं /var/run, जो कि systemd-tmpfilesएक समस्या है, और क्यों प्रिवीपप डायर नहीं बनाया जा रहा है। इस धागे का 4-आखिरी संदेश इस पर कुछ प्रकाश डालता है। दी, यह संबंधित है systemd-tmpfiles-clean, लेकिन मुझे लगता है कि यही बात यहां लागू होती है।
— शून्य रात्रि
1

क्या आप जांच सकते हैं कि आपकी /(रूट फाइल सिस्टम) अनुमतियां बदली नहीं गई हैं? root:rootनीचे दो लाइनों की तरह होना चाहिए :

drwxr-xr-x  25 root root      4096 дек 21 06:45 ..
drwxr-xr-x  25 root root      4096 дек 21 06:45 .

यदि मालिक कोई अन्य उपयोगकर्ता है (और रूट नहीं है) तो यह सिस्टम स्टार्टअप द्वारा सिस्टम स्टार्टअप के दौरान सभी अस्थायी फ़ाइलों को बनाने से रोक देगा। आप कमांड के साथ भी देख सकते हैं:

systemd-tmpfiles --create

यदि रूट फ़ोल्डर ( /) में अलग-अलग अनुमति है, तो कृपया इसे निम्न कमांड से बदलें:

chown root: /
— स्टीफन
स्रोत
0

उपयोगी जानकारी के लिए सभी को धन्यवाद। मेरे ज़ेनियल लुबंटू पर ssh- सर्वर के साथ समस्या वास्तव में '/' के स्वामित्व से संबंधित थी जैसा कि मेलेबियस और शिफान ने सुझाव दिया था। अस्थायी रूप से ssh.service को अस्थायी
रूप से बनाना /var/run/sshdऔर पुनः आरंभ करना अस्थायी रूप से ssh-server। sshd.confइस प्रणाली को संपादित करने से मदद नहीं मिली। फिर अंतिम सुझाव के बाद, मैंने रूट फ़ोल्डर स्वामित्व की जाँच की:

' ls -alF /' और निश्चित रूप से, यह गलती से एक स्थानीय उपयोगकर्ता / समूह में बदल गया था। टर्मिनल से जारी करना: ' sudo chown root:root /' मेरे सिस्टम को ठीक कर दिया गया है, भले ही संपादन के लिए sshd.conf। इसलिए मैंने इसे अपनी मूल स्थिति में पुनर्स्थापित किया, अर्थात d /var/run/sshd 0755 root root।

— माइकल
स्रोत
0

मुझे अपनी मशीन पर यह समस्या आ रही है जब मैं एक मशीन (18.04.02 LTS, OpenSSH 7.6p1) पर sshd के कई उदाहरण चला रहा हूं।

समस्या यह है कि sshd_config"विशेषाधिकार अलगाव निर्देशिका" के स्थान को बदलने के लिए sshd (यानी कमांड लाइन या फ़ाइल) में कोई स्विच नहीं हैं । /var/emptyOpenSSH 7.6p1 स्रोत कोड के अनुसार निर्देशिका में होना चाहिए ।

उबंटू पैकेज ने इसे रीमैप किया है /run/sshd।

init.dबूट पर स्क्रिप्ट में "थ्रेड सुरक्षा" समस्या होती है जब दोनों सेवा स्क्रिप्ट निर्देशिका बनाने का प्रयास करते हैं। मैंने उबंटू और ओपनएसएसएच दोनों को एसडीएस में हार्ड-कोडेड "विशेषाधिकार पृथक्करण निर्देशिका" पथ नामों के मुद्दे को संबोधित करने के लिए कहा है। अगर मैं फाइलें अपलोड कर सकता हूं, तो मेरे पास 8.0p1 ओपनएसएसएच स्रोत कोड के आधार पर तय है।

— ल्यूक ए पर्किन्स
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.