এসএসএইচ সার্ভারটি পুনরায় বুটের পরে কাজ করা বন্ধ করে দেয়, যার ফলে / var / run / sshd হারিয়েছে


23

আমার ভিপিএস প্রায় 3 মাস ধরে রিবুট করা হয়নি। এটি ওপেনজেড ভার্চুয়ালাইজেশন ধরণের সার্ভারে হোস্ট করা হয়েছে এবং অপারেটিং সিস্টেমটি উবুন্টু 16.04। কোনও কারণে, আমি ভিপিএস পুনরায় বুট করেছি এবং তার পরে, আমি ssh এর মাধ্যমে সার্ভারের সাথে সংযোগ করতে পারিনি, আমি যে বার্তা পেয়েছি তা হ'ল:

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

সুতরাং আমি ভিপিএসে একটি সিরিয়াল কনসোল খুলে তদন্ত শুরু করেছি ... আমি সাফ করেছি এবং 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

সিস্টেম স্টার্টআপে সবকিছু ঠিকঠাক হয়, এসএসএইচ পরিষেবাটি সাধারণত শুরু হয় এবং আমি এসএসএইচ-এর মাধ্যমে লগ-ইন করতে সক্ষম হয়েছি।


এই লিঙ্কযুক্ত প্রশ্নে বর্ণিত হিসাবে, পুনরায় বুট করার আগেই করা সংস্করণ আপগ্রেডের কারণে হঠাৎ রিবুট হওয়ার পরে এই সমস্যাটি দেখা দিতে পারে । পাঠ: আপনার কার্নেল এটি সমর্থন করতে পারবেন না তা না হলে আপগ্রেড করবেন না।
তুষারপাত

উত্তর:


24

আমি পেয়েছি এটি সিস্টেমড এবং পুরাতন কার্নেলগুলির বর্তমান সংস্করণ সহ একটি বাগ যা কিছু ভিপিএস বেসরকারীরা আমার ক্ষেত্রে যেমন ব্যবহার করে তা ব্যবহার করে। এই বাগটি সময়ে সময়ে উপস্থিত হয়, যেমন আমরা লঞ্চপ্যাডে দেখতে পারি: বাগ # 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যা এসএসএইচ সার্ভারটি তৈরি এবং পুনঃসূচনা করবে, আপনি crontabএই উদ্দেশ্যে রুটটি ব্যবহার করতে পারেন - sudo crontab -eনিম্নলিখিত এন্ট্রি কার্যকর করুন এবং যুক্ত করুন:

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

বর্তমানে আমি এই সমাধানটি ব্যবহার করছি, সুতরাং এটিও পরীক্ষিত।


কার্য 3:/etc/rc.local উপরের মত একই কাজ করতে ব্যবহার করুন , যেমনটি বাগ রিপোর্ট # 45234 এ এই মন্তব্যে দেখানো হয়েছে


1
ধন্যবাদ, এটি সংশোধন করে তবে সিস্টেমেড বিচ্ছিন্ন হওয়ার বিস্তৃত সমস্যাগুলি নয়। Systemd-tmpfiles চালানোর চেষ্টা করুন - তৈরি করুন এবং সমস্ত ত্রুটি দেখুন
পলজ্যাগ

1
আপনি ঠিক, @paulzag কিন্তু আমার ক্ষেত্রে আমি "M নিশ্চিত সাধারণ সমস্যা পুরোনো কার্নেলটি হয়। আমি এই ত্রুটি উপেক্ষা করার সিদ্ধান্ত নিয়েছে যে systemd-tmpfiles --createশো, কারণ মুহূর্তে সেখানে সার্ভারে কোন যুক্তিসম্মত চলমান সমস্যা নয়। সাধারণভাবে, বর্তমান প্রশ্ন হল কিভাবে SSH পরিসেবা পুনরায় বুট করার পরে সক্রিয় পেতে যখন সম্পর্কে ইস্যু নিযুক্ত থাকে আপনি যদি চান আপনি সমাধান :) ভোট দিন করতে পারেন।
pa4080

"ওয়ার্কারআউন্ড 1" আমার পক্ষে কাজ করেছে ... ধন্যবাদ ... আপ ভোট দেওয়া ...
বিশ্বদীপ সরকার

2
সরাসরি ফাইলটি পরিবর্তনের পরিবর্তে ওভাররাইড করা আরও যথাযথ /usr/lib/tmpfiles.d/sshd.confহবে, কারণ ফাইলটি প্যাকেজ ম্যানেজার দ্বারা পরিচালিত হয়। এটি করতে, কেবল পরিবর্তন করুন /etc/tmpfiles.d/sshd.conf; এটি sshd.confভিতরে অগ্রাধিকার নিতে হবে /usr/libTmpfiles.d (5) এ এই বিভাগটি দেখুন । নির্বিশেষে দুর্দান্ত উত্তর,
ওপেনজেড ভিপিএসে থাকাকালীন

1
হিসেবে কেন কার্যসংক্রান্ত 1 কাজ করে; আপনি যে সিমলিংকটি ব্যবহার করছেন তা এড়িয়ে যাচ্ছেন /var/run, যা systemd-tmpfilesনিয়ে সমস্যা দেখা দিচ্ছে এবং কেন প্রাইভেসপ সীর তৈরি হচ্ছে না। এই থ্রেডের চতুর্থ-শেষ বার্তাটি এতে কিছুটা আলোকপাত করে। মঞ্জুর, এটি সম্পর্কিত 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

সহায়ক তথ্যের জন্য সবাইকে ধন্যবাদ। আমার জেনিয়াল লুবুন্টুতে এসএস-সার্ভারে সমস্যাটি আসলে '/' এর মালিকানার সাথে সম্পর্কিত ছিল যেমনটি মেলিবিয়াস এবং স্টেফান বলেছিল।
ম্যানুয়ালি তৈরি /var/run/sshdএবং সাময়িকভাবে সাময়িকভাবে ssh.service পুনরায় চালু করার SSH-সার্ভার। সম্পাদনা করা sshd.confএই সিস্টেমে কোনও উপকারে আসেনি। তারপরে সর্বশেষ পরামর্শটি অনুসরণ করে আমি এর সাথে মূল ফোল্ডারটির মালিকানা পরীক্ষা করেছি:

' ls -alF /' এবং যথেষ্ট নিশ্চিত, এটি ঘটনাক্রমে স্থানীয় ব্যবহারকারী / গোষ্ঠীতে পরিবর্তিত হয়েছিল। টার্মিনাল থেকে ইস্যু করা হচ্ছে: ' sudo chown root:root /' সম্পাদনা নির্বিশেষে আমার সিস্টেম ঠিক করেছে sshd.conf। সুতরাং আমি এটিকে তার মূল অবস্থায় পুনরুদ্ধার করেছি, অর্থাৎ d /var/run/sshd 0755 root root


0

আমি যখন একটি একক মেশিনে (18.04.02 এলটিএস, ওপেনএসএইচ 7.6p1) একাধিক উদাহরণ চালাচ্ছি তখন আমার মেশিনে এই সমস্যা হচ্ছে।

সমস্যাটি হ'ল sshd_config"সুবিধাযুক্ত বিচ্ছেদ ডিরেক্টরি" এর অবস্থান পরিবর্তন করার জন্য এসএসডিডি (অর্থাত্ কমান্ড লাইন বা ফাইল) তে কোনও সুইচ নেই । /var/emptyওপেনএসএসএইচ 7.6p1 উত্স কোড অনুযায়ী ডিরেক্টরিটি হওয়া উচিত ।

উবুন্টু প্যাকেজ এটিকে পুনরায় তৈরি করেছে /run/sshd

init.dবুট করার সময় স্ক্রিপ্টগুলিতে একটি "থ্রেড সুরক্ষা" সমস্যা রয়েছে যখন উভয় পরিষেবা স্ক্রিপ্ট ডিরেক্টরি বানানোর চেষ্টা করে। আমি উবুন্টু এবং ওপেনএসএসএইচ উভয়কেই sshd-তে হার্ড-কোডড "সুবিধার্থে পৃথকীকরণ ডিরেক্টরি" পথের নামটি সমাধান করতে বলেছি। যদি আমি ফাইলগুলি আপলোড করতে পারি তবে আমার 8.0p1 ওপেনএসএসএইচ উত্স কোডের উপর ভিত্তি করে ফিক্সটি আছে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.