Apa yang menyebabkan masalah SSH setelah mem-boot ulang server 14.04?


15

Mengapa me-reboot server yang menjalankan Ubuntu 14.04 memberi saya kesalahan 'Sambungan ditolak'?

Saya melihat ssh: connect to host <IP-address-here> port 22: Connection refusedtetapi hanya untuk 14,04 dan hanya setelah reboot. Saya menggunakan Desktop 12,04 di rumah. Bagaimana saya memecahkan masalah ini?


Untuk membuat pertanyaan lebih jelas, inilah yang berfungsi atau tidak untuk saya:

  • SSH menjadi instalasi baru 12,04> logout> SSH dalam lagi> berfungsi
  • SSH menjadi instalasi baru 12,04> reboot> SSH dalam lagi> berfungsi
  • SSH menjadi instalasi baru 14,04> logout> SSH dalam lagi> berfungsi
  • SSH menjadi instalasi baru 14,04> reboot> SSH masuk lagi> Sambungan ditolak

Masalah yang saya alami adalah unik untuk 14,04, dan hanya terjadi setelah reboot. Saya memiliki beberapa server yang menjalankan 12,04 sebelum ini dan semuanya masih berfungsi dengan baik. Saya punya server baru yang ingin saya gunakan 14.04 dan saya ingin mengerti apa yang salah. Ada saran?


Inilah yang saya coba sejauh ini:

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

Traceroute berfungsi dengan baik, saya mendapat respons dari server pada port SSH 22.

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

Sepertinya ssh pada server 14.04 diatur untuk mulai saat boot (seperti yang diharapkan).

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

Sunting: Berikut adalah keseluruhan syslog dari mesin yang baru dibuat . Saya membuatnya, SSH akan & mengeluarkan reboot nowperintah, kemudian mendapat koneksi menolak kesalahan setelah menunggu untuk reboot dan mencoba untuk SSH di kedua kalinya. Hard reboot via hosting control panel dan sekarang koneksi SSH berfungsi lagi.


Saya memiliki masalah serupa, tetapi dalam konteks yang sangat berbeda. Tampaknya ada sesuatu yang berubah, tetapi saya tidak dapat menemukan apa. Saya tahu ada perubahan dengan udev, tetapi saya tidak melihat persis bagaimana itu menjadi masalah, karena jaringan tampaknya berfungsi dengan baik jika tidak. Hanya sshd yang merepotkan.
Jo-Erlend Schinstad

1
@ Jo-ErlendSchinstad Saya menghabiskan 2 jam hari ini untuk menguji ini dengan server AWS, DigitalOcean dan OVH dan dapat mereproduksi 100% dari waktu. 12,04 = ok, 14,04 = tidak ada SSH setelah reboot. Jika ini adalah bug saya berharap kami akan mendengar dari banyak orang lain yang terkunci dari server mereka! Semoga saya mengabaikan sesuatu tetapi dengan instalasi baru + login SSH tunggal untuk reboot, tidak ada banyak ruang untuk kesalahan manusia di sini. Baru saja mengujinya sekarang dari laptop 14,04 saya (kalau-kalau ini adalah 12,04) dan tidak ada perubahan, hasil yang sama. Sangat berharap untuk mengetahui hal ini segera ...
Tom Brossman

1
Oh, saya punya banyak server yang menjalankan sshd tanpa masalah sama sekali. Ini adalah masalah yang saya maksudkan
Jo-Erlend Schinstad

Jawaban:


17

Jawaban cepat:

SSH bukan masalahnya. Perintah yang Anda gunakan untuk reboot adalah masalahnya: jangan lakukan reboot now, lakukan, rebootatau shutdown -r nowreboot sistem Anda.

Sintaks perintah ( sejak 13.04 ) adalah:

reboot [OPTION]...  [REBOOTCOMMAND]

Yang REBOOTCOMMANDtidak pernah ada sebelumnya. Dalam 12,04, Anda nowbaru saja diabaikan tetapi sekarang sedang digunakan ... Dan itu menghancurkan segalanya.

Jawaban panjang, dengan hasil dan penjelasan tes saya:

Saya memiliki masalah yang sama dengan beberapa server yang menjalankan 14,04 DAN di VPS (di-host di penyedia OVH Prancis - menjalankan OpenVZ) DAN ketika melakukan reboot now di dalam server itu sendiri.

Seperti Anda, saya sudah mengeluarkan perintah reboot now dari konsol (masuk menggunakan SSH). Beberapa detik setelah saya tekan RETURN, sesi saya terputus secara otomatis. Seperti Anda, saya tidak pernah dapat terhubung kembali ke server melalui SSH setelah mengeluarkan perintah ini.

Jadi, saya memutuskan untuk membuka konsol KVM yang disediakan oleh OVH. (meniru akses langsung menggunakan keyboard dan layar pada server fisik untuk server virtual semacam ini).

Saya dapat terhubung ke mesin saya dan saya melihat bahwa dia masuk ke Mode Pengguna Tunggal, menunggu saya untuk menekan CTRL+ Duntuk melanjutkan atau untuk memasukkan kata sandi root untuk masuk ke mode pemeliharaan. Saya menekan kombinasi tombol untuk membiarkan proses berlanjut dan kemudian dapat SSH ke sistem saya lagi. Apa yang saya duga, setelah berlari uptime, bahwa waktu aktifnya bukan 2 atau 3 menit tetapi banyak hari:reboot now dijalankan di dalam Ubuntu 14,04 VPS tidak benar-benar me-reboot tetapi hanya meminta untuk masuk ke mode Pengguna Tunggal!

Dari ini, saya telah belajar untuk tidak pernah meminta reboot dari dalam VPS saya tetapi untuk memintanya dari perintah yang disediakan pada antarmuka manajemen hoster.

Dengan demikian tidak ada masalah dengan instalasi SSH Anda. Masalahnya adalah saat Anda mengetik reboot now. Bahkan, saya mengujinya setelah itu juga, jika Anda mengetik reboot(hanya kata, tidak ada pilihan), itu akan melakukan apa yang ingin Anda lakukan: reboot server.

Menggunakan rebootdengan argumen (dari halaman manual) panggilan perintah shutdowndengan argumen yang diberikan. Dan memang, jika saya mengeksekusi shutdown now, saya memiliki perilaku yang sama: sistem tidak di-reboot, itu masuk ke mode pengguna tunggal.

Komentar: sepertinya itu adalah perilaku yang dimaksudkan sebagai pesan yang muncul di layar setelah menekan menjalankan perintah ini mengatakan sesuatu seperti:

Sistem akan dibawa ke mode pemeliharaan

Mode pemeliharaan atau mode pengguna tunggal, ini mewakili yang sama, runlevel dengan mencatat lebih dari shell, tidak ada jaringan, tidak ada proses jaringan, ...

Ini mungkin membingungkan, tetapi perhatikan bahwa penggunaan yang benar shutdownadalah, misalnya: shutdown -h nowuntuk menghentikan sistem sekarang atau shutdown -r nowuntuk mem-boot ulang sekarang. Saya tidak sadar bahwa shutdown nowhanya akan membawa sistem ke mode pengguna tunggal. Saya biasanya lakukan init Suntuk mencapai ini.


Terima kasih atas jawaban paling menarik ini! Saya akan menguji semua ini sekarang karena saya menggunakan dedicated server (bukan VPS) tapi saya punya masalah pada kedua jenis - asalkan 14,04 dan bukan 12,04. sudo reboot nowberfungsi dengan baik dalam 12,04 dan uptimesesuai dengan terakhir kali saya melakukannya. Perubahan yang sangat menarik untuk 14,04 sekalipun.
Tom Brossman

1
memiliki masalah yang sama persis setelah memperbarui server ke 14.04.1, dan reboot tidak menyelesaikannya.
chhantyal

Ini memperbaikinya untuk saya. Harus me-reboot server secara manual. Wow, ini sangat menyebalkan! Mengapa sekarang menyamakan ke mode pengguna tunggal? Pilihan yang bodoh. Mengapa tidak sudo reboot --single-usermendapatkan fungsionalitas itu ???
jcollum

2

Saya mungkin terlambat, dan mungkin sudah jelas, tetapi yang berhasil bagi saya adalah memeriksa file konfigurasi /etc/ssh/sshd_config: menjalankan daemon dengan /etc/init.d/ssh startatau kombinasi lain menunjukkan bahwa layanan berjalan meskipun tidak, tetapi jika saya meluncurkan executable dengan jalur absolutnya (dalam kasus saya /usr/sbin/sshd) saya melihat bahwa ada "0B" ditambahkan di akhir file konfigurasi yang menyebabkan kesalahan ketika memulai, menghapusnya memecahkan masalah.


Sangat berguna - dalam kasus saya, saya telah mengetik karakter yang salah di awal file. Sangat misterius bagaimana tidak ada kesalahan yang dilemparkan jika ada masalah dalam konfigurasi, dan semuanya tampaknya mulai walaupun tidak ada proses yang berjalan.
Andrew Mao

2

Penyebab potensial lainnya adalah ufwkehilangan konfigurasi aturan port SSH. Ini terjadi pada saya setidaknya satu atau dua kali, di mana setelah menerapkan pembaruan dan reboot, konfigurasi firewall menghalangi saya untuk mendapatkan akses ke server. Menggunakan fasilitas konsol VPS penyedia hosting saya memungkinkan saya untuk masuk ke mesin dan mendiagnosis masalahnya. Contoh di bawah ini menunjukkan masalah (mis. Tidak ada entri untuk port 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)

Mengaktifkan kembali port sebagai berikut akan melakukan trik:

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

-1

Untuk sistem saya masalahnya adalah bahwa skrip init ssh /etc/init.d/sshadalah satu-satunya yang memeriksa keberadaan versi pemula init.

Jadi /etc/init.d/sshtidak memulai ssh,karena percaya itu akan dimulai olehupstart .

Dalam kasus saya, pemula tidak memulai karena konfigurasi khusus saya:

Ada konfigurasi yang benar /etc/init/ssh.conf, tetapi ada juga /etc/init/ssh.overridefile yang mengandung manual, yang berartissh diharapkan akan dimulai secara manual.

File ini dibuat oleh get-remnux.sh skrip instalasi.

Mulai secara manual, atau menghapus /etc/init/ssh.overridefile memecahkan masalah.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.