SSH Sunucusu, yeniden başlattıktan sonra eksik / var / run / sshd kaynaklı çalışmayı durduruyor


23

VPS'im yaklaşık 3 ay boyunca yeniden başlatılmadı. OpenVZ sanallaştırma türüne sahip bir sunucuda barındırılıyor ve işletim sistemi Ubuntu 16.04. Nedense VPS'yi yeniden başlattım ve bundan sonra ssh ile sunucuya bağlanamadım, aldığım mesaj:

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

Böylece VPS'de bir Seri Konsol açtım ve araştırmaya başladım ... openssh-serverBaşarısız bir şeyi temizledim ve yeniden kurdum . İki saatimi Internet'teki benzer konularla ilgili makale, soru ve cevapları okumak için harcadım.

Sonunda /var/run/sshd, sistemin başlatılması sırasında dizinin oluşturulmadığını anladım . Ve manuel olarak oluşturduğumda SSH hizmetini sorunsuz bir şekilde başlatabilirim, ancak bir sonraki açılışta sorun devam ediyor. Yani benim sorularım:

  • Bu sorunun nedeni ne olabilir? /var/run/sshdSistem başlangıcında neden oluşturulmadı?

  • Konuyu doğru şekilde nasıl çözebilirim? Bu yazının sonunda belirtilen geçici bir çözüm buldum.

  • Sorun VPS'nin OpenVZ sunucusuyla ilgili olabilir mi? Barındırma sağlayıcısından çözmesini istemeli miyim?


Çıkış systemctl status ssh.service, sshd -Ddp 22ve journalctl -xebir:

# 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'.

İçeriği /usr/lib/tmpfiles.d/sshd.confve /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

Sistem hakkında ek bilgi:

# 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

Geçici çözüm: Bunun /var/runsembolik bir bağlantı olduğunu öğrendim, /runbunun neden gerekli olduğunu bilmiyorum, ancak dosyanın içeriğini değiştirdiğimde /usr/lib/tmpfiles.d/sshd.conf:

d /var/run/sshd 0755 root root

için:

d /run/sshd 0755 root root

Sistem başlangıcında her şey yolunda gidiyor, SSH servisi normal olarak başlatılıyor ve SSH üzerinden oturum açabiliyorum.


Bu sorun, bu bağlantılı soruda açıklandığı gibi, yeniden başlatmadan hemen önce yapılan sürüm yükseltme nedeniyle bir yeniden başlatmadan sonra aniden görünebilir . Ders: Çekirdeğinizin destekleyebileceğinden emin değilseniz, yükseltme yapmayın.
Kar

Yanıtlar:


24

Bu benim durumumda olduğu gibi bazı VPS ayrıcalıklarının kullandığı systemd ve eski çekirdeğin geçerli sürümünde bir hata olduğunu buldum. Bu hata, Launchpad'de görüldüğü gibi zaman zaman ortaya çıkıyor: Bug # 45234 , Bug # 1811580 ; veya ServerFault'da: Neden her açılıştan sonra / var / run / sshd eksik?

Bu sorunun birkaç çözümü vardır, hepsi /var/run/sshdSSH sunucusunu çalıştırmadan önce oluşturmanın alternatif bir yolunu bir araya getirir . İşte size üç olası çözüm.


Geçici Çözüm 1:/usr/lib/tmpfiles.d/sshd.conf Aşağıdaki şekilde değiştirin :

d /run/sshd 0755 root root

Sorunda da belirtildiği gibi /var/runsembolik bir bağlantıdır /run, nihai sonuç aynıdır: /var/run/sshdyaratılır. Nedenini bilmiyorum ama bu işe yarıyor.


Geçici Çözüm 2:/var/run/sshd SSH sunucusu oluşturacak ve yeniden başlatacak Cron işini kullanın, kökün crontabbu amaçla kullanabilirsiniz - sudo crontab -eaşağıdaki girişi yürütün ve ekleyin:

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

Şu anda bu çözümü kullanıyorum, bu yüzden test edildi.


Geçici Çözüm 3: Hata bildirimi # 45234'teki bu yorumda gösterildiği/etc/rc.local gibi yukarıdakilerle aynı işlemi yapmak için kullanın .


1
Teşekkürler, bu ssh'i düzeltir ancak daha geniş sistem problemlerinin bozulmamasını sağlar. Systemd-tmpfiles çalıştırmayı deneyin - yaratın ve tüm hataları görün
paulzag

1
Haklısın, @paulzag, ama benim durumumda genel sorunun eski çekirdek olduğuna eminim. Bu hataları göz ardı etmeye karar verdim systemd-tmpfiles --create, çünkü şu anda sunucuda herhangi bir makul arıza bulunmuyor. Mevcut soru ise yeniden başlatıldıktan sonra operasyonel SSH hizmeti almak için nasıl ilgili sorun devreye girer isterseniz siz bir çözüm :) upvote olabilir.
pa4080

"Geçici Çözüm 1" benim için çalıştı ... Teşekkürler ... Yukarı Oy verildi ...
Biswadeep Sarkar

2
Bu dosya paket yöneticisi tarafından yönetildiği için doğrudan değiştirmek yerine geçersiz kılmak daha uygun olur /usr/lib/tmpfiles.d/sshd.conf. Bunu yapmak için, sadece değişikliği yapın /etc/tmpfiles.d/sshd.conf; bu, sshd.confin yerine öncelikli olacaktır /usr/lib. Tmpfiles.d (5) bölümündeki bu bölüme bakınız . Ne olursa olsun, büyük bir cevap, bir OpenVZ
VPS'de

1
Gelince neden Çözüm 1 çalışır; /var/runsembolik bağlantıyı kullanmaktan kaçınıyorsunuz , ki systemd-tmpfilesbununla bir sorunu var ve neden PrivSep dizini oluşturulmuyor. Bu konunun dördüncü mesajı, buna biraz ışık tutuyor. Kabul systemd-tmpfiles-cleanediyorum, konuyla ilgili , ama aynı şeyin burada da geçerli olduğunu hissediyorum.
ZeroKnight

1

/(Root dosya sistemi) izinlerinizin değişip değişmediğini kontrol edebilir misiniz ? root:rootAşağıdaki iki çizgi gibi olmak zorunda :

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

Eğer sahibi başka bir kullanıcı ise (ve root değil) bu, sistem başlangıcında tüm geçici dosyaların sistem tarafından oluşturulmasını önleyecektir. Ayrıca şu komutu da kontrol edebilirsiniz:

systemd-tmpfiles --create

Kök klasörü ( /) farklı izinlere sahipse, lütfen aşağıdaki komutla değiştirin:

chown root: /

0

Yardımcı bilgiler için herkese teşekkürler. Xenial Lubuntu'mdaki ssh-server ile ilgili sorun Melebius & Stefan'ın önerdiği gibi '/' mülkiyeti ile ilgiliydi. Ssh.service dosyasını ssh-server'ı geçici olarak
el ile oluşturma /var/run/sshdve yeniden başlatma. Düzenleme sshd.confbu sistemde yardımcı olmadı. Sonra son öneriyi takiben, kök klasör sahipliğini kontrol ettim:

' ls -alF /' ve elbette, yanlışlıkla yerel bir kullanıcı / grup olarak değiştirildi. Terminalden çıkış: ' sudo chown root:root /' Düzenleme ne olursa olsun, sistemimi düzeltti sshd.conf. Bu yüzden orijinal durumuna geri getirdim, yani d /var/run/sshd 0755 root root.


0

Tek bir makinede birden fazla sshd örneği çalıştırdığımda bu sorunu yaşıyorum (18.04.02 LTS, OpenSSH 7.6p1).

Sorun, sshd_config"ayrıcalık ayırma dizini" nin konumunu değiştirmek için sshd'de (yani komut satırı veya dosya) herhangi bir anahtar olmamasıdır . /var/emptyOpenSSH 7.6p1 kaynak koduna göre, dizin içinde olmalıdır .

Ubuntu paketi bunu yeniden gönderdi /run/sshd.

Her init.diki hizmet betiği de dizini oluşturmaya çalıştığında, önyükleme sırasında komut dosyalarında "iş güvenliği" sorunu vardır . Hem Ubuntu hem de OpenSSH'den, sshd'deki kodlanmış "ayrıcalık dizini" yol adları konusunu ele almasını istedim. Dosya yükleyebilseydim, 8.0p1 OpenSSH kaynak kodunu temel alarak düzeltmeyi yaptım.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.