อะไรเป็นสาเหตุของปัญหา SSH หลังจากรีบูตเซิร์ฟเวอร์ 14.04


15

เหตุใดการรีบูตเซิร์ฟเวอร์ที่ใช้งาน Ubuntu 14.04 ให้ข้อผิดพลาด 'การเชื่อมต่อถูกปฏิเสธ'

ฉันเห็นssh: connect to host <IP-address-here> port 22: Connection refusedแต่เพียง 14.04 และหลังจากรีบูตเท่านั้น ฉันใช้เดสก์ท็อป 12.04 ที่บ้าน ฉันจะแก้ไขปัญหานี้ได้อย่างไร


หากต้องการทำให้คำถามชัดเจนขึ้นนี่คือสิ่งที่ทำงานหรือไม่ได้ผลสำหรับฉัน:

  • SSH ไปสู่การติดตั้งใหม่ 12.04> ออกจากระบบ> SSH อีกครั้ง> ใช้งานได้
  • SSH ไปสู่การติดตั้งใหม่ 12.04> เริ่มระบบใหม่> SSH อีกครั้ง> ใช้งานได้
  • SSH ไปยังการติดตั้งใหม่ที่ 14.04> ออกจากระบบ> SSH อีกครั้ง> ใช้งานได้
  • SSH ไปสู่การติดตั้งใหม่ที่ 14.04> รีบูต> SSH อีกครั้ง> การเชื่อมต่อถูกปฏิเสธ

ปัญหาที่ฉันมีไม่เหมือนใครกับ 14.04 และจะเกิดขึ้นหลังจากรีบูตเครื่องเท่านั้น ฉันมีเซิร์ฟเวอร์หลายเครื่องที่รัน 12.04 ก่อนหน้านี้และทุกอย่างยังทำงานได้อย่างสมบูรณ์ ฉันมีเซิร์ฟเวอร์ใหม่ที่ฉันต้องการใช้ 14.04 และฉันต้องการเข้าใจสิ่งที่เกิดขึ้น ข้อเสนอแนะใด ๆ


นี่คือสิ่งที่ฉันได้ลองมา:

sudo traceroute -p 22 -T <IP-address-here>

Traceroute ทำงานได้ดีฉันได้รับการตอบสนองจากเซิร์ฟเวอร์ที่พอร์ต SSH 22

initctl list
...
ssh start/running, process 23371
...

ดูเหมือนว่า ssh บนเซิร์ฟเวอร์ 14.04 ถูกตั้งค่าให้เริ่มต้นเมื่อบูต (ตามที่คาดไว้)

tom@Desktop:~$ ssh -vvv root@<IP-address-here>
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to <IP-address-here> [<IP-address-here>] port 22.
debug1: connect to address <IP-address-here> port 22: Connection refused
ssh: connect to host <IP-address-here> port 22: Connection refused

แก้ไข: นี่คือsyslog ทั้งจากเครื่องสร้างสด ฉันสร้างมัน SSH จะอยู่ใน & ออกreboot nowคำสั่งจากนั้นได้รับการเชื่อมต่อปฏิเสธข้อผิดพลาดหลังจากรอให้รีบูตและพยายาม SSH ในครั้งที่สอง ฮาร์ดรีบูตผ่านแผงควบคุมการโฮสต์และตอนนี้การเชื่อมต่อ SSH ทำงานได้อีกครั้ง


ฉันมีปัญหาที่คล้ายกัน แต่ในบริบทที่แตกต่างกันมาก ดูเหมือนว่ามีบางอย่างเปลี่ยนแปลงไป แต่ฉันไม่สามารถเข้าใจได้ ฉันรู้ว่ามีการเปลี่ยนแปลงกับ udev แต่ฉันไม่เห็นว่ามันจะมีความสำคัญเพราะระบบเครือข่ายดูเหมือนว่าจะทำงานอย่างถูกต้องเป็นอย่างอื่น เพียงแค่ sshd เป็นปัญหา
Jo-Erlend Schinstad

1
@ Jo-ErlendSchinstad ฉันใช้เวลา 2 ชั่วโมงในวันนี้ทดสอบกับเซิร์ฟเวอร์ AWS, DigitalOcean และ OVH และสามารถทำซ้ำได้ 100% 12.04 = ตกลง, 14.04 = ไม่มี SSH หลังจากรีบูตเครื่อง หากนี่เป็นข้อผิดพลาดฉันคาดหวังว่าเราจะได้ยินจากคนอื่น ๆ ที่ล็อคไว้ในเซิร์ฟเวอร์ของพวกเขา! หวังว่าฉันสามารถมองเห็นบางสิ่งบางอย่าง แต่ด้วยการติดตั้งใหม่ + เข้าสู่ระบบ SSH เดียวเพื่อรีบูตไม่มีข้อผิดพลาดของมนุษย์ที่นี่ เพิ่งทดสอบตอนนี้จากแล็ปท็อป 14.04 ของฉัน (ในกรณีนี้คือสิ่ง 12.04) และไม่มีการเปลี่ยนแปลงผลลัพธ์เดียวกัน หวังเป็นอย่างยิ่งว่าจะคิดเรื่องนี้ในไม่ช้า ...
Tom Brossman

1
โอ้ฉันมีเซิร์ฟเวอร์จำนวนมากที่รัน sshd โดยไม่มีปัญหาใด ๆ เลย นี่คือปัญหาที่ฉันอ้างถึง: askubuntu.com/questions/479448/ …
Jo-Erlend Schinstad

คำตอบ:


17

คำตอบที่รวดเร็ว:

SSH ไม่ใช่ปัญหา คำสั่งที่คุณใช้ในการรีบูตเป็นปัญหา: อย่าทำreboot nowทำrebootหรือshutdown -r nowรีบูตระบบของคุณ

ไวยากรณ์คำสั่ง ( ตั้งแต่ 13.04 ):

reboot [OPTION]...  [REBOOTCOMMAND]

REBOOTCOMMANDไม่เคยมีมาก่อน ใน 12.04 คุณnowถูกเพิกเฉย แต่ตอนนี้มันถูกใช้ ... และมันทำลายทุกอย่าง

คำตอบยาวด้วยผลการทดสอบและคำอธิบายของฉัน:

ฉันมีปัญหาคล้ายกันกับเซิร์ฟเวอร์บางตัวที่ทำงาน 14.04 และใน VPS (โฮสต์ที่ผู้ให้บริการ OVH ฝรั่งเศส - ใช้ OpenVZ) และเมื่อทำreboot nowภายในเซิร์ฟเวอร์เอง

เช่นเดียวกับคุณฉันได้ออกคำสั่งreboot nowจากคอนโซล (เข้าสู่ระบบโดยใช้ SSH) ไม่กี่วินาทีหลังจากฉันกดRETURNเซสชันของฉันจะถูกตัดการเชื่อมต่อโดยอัตโนมัติ เช่นเดียวกับคุณฉันไม่เคยเชื่อมต่อกับเซิร์ฟเวอร์ผ่าน SSH อีกครั้งหลังจากออกคำสั่งนี้

ดังนั้นฉันจึงตัดสินใจเปิดคอนโซล KVM ที่ OVH จัดหาให้ (เลียนแบบการเข้าถึงโดยตรงโดยใช้แป้นพิมพ์และหน้าจอบนเซิร์ฟเวอร์จริงสำหรับเซิร์ฟเวอร์เสมือนชนิดนี้)

ฉันสามารถเชื่อมต่อกับเครื่องของฉันและฉันเห็นว่าเธอกำลังเข้าสู่โหมดผู้ใช้คนเดียวรอให้ฉันกดCTRL+ Dเพื่อดำเนินการต่อหรือป้อนรหัสผ่านรูทเพื่อเข้าสู่โหมดบำรุงรักษา ฉันกดคีย์ผสมเพื่อให้กระบวนการดำเนินการต่อจากนั้นก็สามารถ SSH เข้าสู่ระบบของฉันอีกครั้ง สิ่งที่ฉันประหลาดใจที่เห็นหลังจากทำงานuptimeนั่นคือเวลาไม่เกิน 2 หรือ 3 นาที แต่ยังมีอีกหลายวัน: reboot nowดำเนินการภายใน Ubuntu 14.04 VPS ไม่ใช่การรีบูตจริง ๆ แต่เป็นการขอให้เข้าสู่โหมดผู้ใช้คนเดียว!

จากนี้ฉันได้เรียนรู้ที่จะไม่ขอรีบูตจากภายใน VPS ของฉัน แต่เพื่อขอจากคำสั่งที่มีให้ในส่วนต่อประสานการจัดการของ hoster

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

ใช้rebootกับอาร์กิวเมนต์ (จากหน้าคน) เรียกคำสั่งที่shutdownมีข้อโต้แย้งที่กำหนด และแน่นอนถ้าฉันดำเนินการshutdown nowฉันมีพฤติกรรมเหมือนกัน: ระบบไม่รีบูตระบบจะเข้าสู่โหมดผู้ใช้คนเดียว

หมายเหตุ:ดูเหมือนว่ามันเป็นพฤติกรรมที่ตั้งใจตามที่ปรากฏบนหน้าจอข้อความหลังจากที่เกลียดการดำเนินการคำสั่งนี้พูดว่า:

ระบบจะถูกนำไปที่โหมดการบำรุงรักษา

โหมดการบำรุงรักษาหรือโหมดผู้ใช้คนเดียวซึ่งเป็นตัวแทนเดียวกัน runlevel ที่มีมากกว่าเชลล์ไม่มีเครือข่ายไม่มีกระบวนการเครือข่าย ...

สิ่งนี้อาจทำให้เกิดความสับสน แต่โปรดทราบว่าการใช้งานที่ถูกต้องshutdownคือshutdown -h nowเพื่อหยุดระบบในขณะนี้หรือshutdown -r nowเพื่อรีบูตทันที ฉันไม่ทราบว่าshutdown nowจะนำระบบเข้าสู่โหมดผู้ใช้คนเดียวเท่านั้น ฉันมักจะทำinit Sเพื่อให้บรรลุนี้


ขอบคุณสำหรับคำตอบที่น่าสนใจที่สุด! ฉันจะทดสอบทั้งหมดนี้ในขณะที่ฉันอยู่บนเซิร์ฟเวอร์เฉพาะ (ไม่ใช่ VPS) แต่ฉันมีปัญหากับทั้งสองประเภท - ตราบใดที่มันเป็น 14.04 และไม่ใช่ 12.04 sudo reboot nowทำงานได้อย่างสมบูรณ์ใน 12.04 และuptimeสอดคล้องกับครั้งสุดท้ายที่ฉันทำ การเปลี่ยนแปลงที่น่าสนใจมากสำหรับ 14.04 แม้ว่า
Tom Brossman

1
มีปัญหาเดียวกันแน่นอนหลังจากอัปเดตเซิร์ฟเวอร์เป็น 14.04.1 และการรีบูตไม่สามารถแก้ไขได้
chhantyal

สิ่งนี้แก้ไขได้สำหรับฉัน ต้องรีบูตเซิร์ฟเวอร์ด้วยตนเอง ว้าวนี่มันช่างน่ารำคาญสุด ๆ ! ทำไมบนโลกนี้จึงเปรียบเสมือนโหมดผู้ใช้คนเดียว? เป็นทางเลือกที่โง่อะไร ทำไมไม่ลองsudo reboot --single-userฟังก์ชั่นนั้น ???
jcollum

2

ฉันอาจจะมาสายและอาจเห็นได้ชัด แต่สิ่งที่ใช้ได้ผลสำหรับฉันคือการตรวจสอบไฟล์การกำหนดค่า/etc/ssh/sshd_config: การเรียกใช้ daemon ด้วย/etc/init.d/ssh startชุดค่าผสมอื่น ๆ แสดงว่าบริการกำลังทำงานอยู่แม้ว่าจะไม่ได้ใช้ แต่ถ้าฉันเปิดใช้งาน เส้นทางแบบสัมบูรณ์ (ในกรณีของฉัน/usr/sbin/sshd) ฉันเห็นว่ามี "0B" ต่อท้ายไฟล์กำหนดค่าที่ทำให้เกิดข้อผิดพลาดเมื่อเริ่มต้นการเอามันจะแก้ไขปัญหาได้


มีประโยชน์มาก - ในกรณีของฉันฉันพิมพ์อักขระที่ผิดพลาดที่จุดเริ่มต้นของไฟล์ ลึกลับมากว่าข้อผิดพลาดจะไม่ถูกโยนถ้ามีปัญหาในการกำหนดค่าและทุกอย่างดูเหมือนจะเริ่มแม้ว่าจะไม่มีกระบวนการทำงาน
Andrew Mao

2

สาเหตุที่เป็นไปได้อีกอย่างหนึ่งคือการufwสูญเสียการกำหนดค่ากฎพอร์ต SSH สิ่งนี้เกิดขึ้นกับฉันอย่างน้อยหนึ่งครั้งหรือสองครั้งซึ่งหลังจากที่ใช้การอัปเดตและการรีบูตเครื่องการกำหนดค่าไฟร์วอลล์ทำให้ฉันไม่สามารถเข้าถึงเซิร์ฟเวอร์ได้ การใช้สิ่งอำนวยความสะดวกคอนโซล VPS ของผู้ให้บริการโฮสต์ช่วยให้ฉันสามารถเข้าสู่เครื่องและวินิจฉัยปัญหาได้ ตัวอย่างด้านล่างแสดงปัญหา (เช่นไม่มีรายการสำหรับพอร์ต 22):

user@host:~$ sudo ufw status verbose
[sudo] password for user:
Status: active
Logging: on (low)
    Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80,443/tcp (Nginx Full)    ALLOW IN    Anywhere
25/tcp                     ALLOW IN    Anywhere
143                        ALLOW IN    Anywhere
110                        ALLOW IN    Anywhere
993/tcp (Dovecot Secure IMAP) ALLOW IN    Anywhere
995/tcp (Dovecot Secure POP3) ALLOW IN    Anywhere
25/tcp (Postfix)           ALLOW IN    Anywhere
465/tcp (Postfix SMTPS)    ALLOW IN    Anywhere
80,443/tcp (Nginx Full (v6)) ALLOW IN    Anywhere (v6)
25/tcp (v6)                ALLOW IN    Anywhere (v6)
143 (v6)                   ALLOW IN    Anywhere (v6)
110 (v6)                   ALLOW IN    Anywhere (v6)
993/tcp (Dovecot Secure IMAP (v6)) ALLOW IN    Anywhere (v6)
995/tcp (Dovecot Secure POP3 (v6)) ALLOW IN    Anywhere (v6)
25/tcp (Postfix (v6))      ALLOW IN    Anywhere (v6)
465/tcp (Postfix SMTPS (v6)) ALLOW IN    Anywhere (v6)

เปิดใช้งานพอร์ตดังต่อไปนี้อีกครั้งจะหลอกลวง:

user@host:~$ sudo ufw allow ssh
Rule added
Rule added (v6)

-1

สำหรับระบบของฉันปัญหาคือว่าสคริปต์ ssh init /etc/init.d/sshเป็นเพียงการตรวจสอบเดียวสำหรับการปรากฏตัวของรุ่น upstart ของ init

ดังนั้น/etc/init.d/sshอย่าเริ่มต้นssh,เพราะเชื่อว่าจะเริ่มupstartขึ้น

ในกรณีของฉันพุ่งพรวดไม่ได้เริ่มต้นเนื่องจากการกำหนดค่าเฉพาะของฉัน:

มีการกำหนดค่าที่ถูกต้องใน/etc/init/ssh.confแต่ก็ยังมี/etc/init/ssh.overrideไฟล์ที่มีmanualซึ่งหมายความsshว่าคาดว่าจะเริ่มด้วยตนเอง

ไฟล์นี้สร้างโดยget-remnux.shสคริปต์การติดตั้ง

เริ่มต้นด้วยตนเองหรือลบ/etc/init/ssh.overrideไฟล์เพื่อแก้ไขปัญหา

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