Menjamin akses SSH pada server yang stres

Saya punya masalah beberapa waktu lalu dengan server di mana Apache dan Snort menempati 100% dari prosesor, membuat sshd tidak responsif melalui akses jarak jauh. Saya harus pergi secara fisik ke server untuk masuk ke TTY lokal dan kemudian berhenti apache / mendengus.

Saya bertanya-tanya apakah ada cara untuk menjamin konektivitas ssh pada situasi 100% CPU / memori yang dimuat. Menetapkan prioritas "baik" sudah cukup?

Terima kasih!

linux ssh process-priority

— Renato Todorov
sumber

Jawaban:

Selain menggunakan metode out-of-band, tidak ada cara untuk menjamin bahwa SSH akan tersedia di server yang terisi penuh. Jika layanan Anda dimuat sehingga tidak dapat melayani terminal SSH dasar untuk Anda, maka Anda memiliki masalah lain.

Ya, renicedan memberikannya nilai yang lebih rendah niceakan meningkatkan kinerja dalam beban berat, tetapi sebaliknya menggunakan sesuatu seperti pam_security (contoh yang ditunjukkan di sini ) akan mencegah Apache / apa pun menjadi tidak terkelola untuk memulai.

— Nathan C
sumber

Baik. Dia berusaha mengobati gejalanya, bukan masalah sebenarnya.

— ewwhite

@ewwhite Tepat. Dan mengobati gejala hanya akan menghasilkan mengejar ekor Anda mencoba mencari tahu mengapa hal - hal lain pecah sebagai hasilnya. :)

— Nathan C

Saya mencari cara untuk memadamkan api tetapi tentu saja saya akan menetapkan batas untuk daemon lainnya. Ini untuk situasi darurat, saya harus memiliki ketenangan untuk mengetahui bahwa saya akan selalu memiliki sshd responsif untuk akses jarak jauh.

— Renato Todorov

@RenatoTodorov dalam hal ini Anda tidak dapat mengobati gejalanya. Jika sistem Anda memiliki proses pelarian yang mengkonsumsi semua {CPU, RAM, Soket, PID} Anda tidak dapat menjamin bahwa biarpun nicepelakunya akan di-boot dari CPU dengan cukup cepat untuk memastikan Anda memiliki akses SSH (atau dalam hal itu akses konsol apa pun yang Anda miliki akan dapat digunakan). Masalah mendasar (resource-hog) perlu diatasi. Fire-Fighting adalah manajemen sistem yang buruk.

— voretaq7

Nah, kalian meyakinkan saya, saya akan menggunakan iDRAC 7 Express selama saya sudah memilikinya. Terima kasih semua!

— Renato Todorov

Solusi tujuan umum Anda untuk ini adalah alat manajemen out-of-band, seperti Dell iDRAC, IBM Remote Supervisor, atau HP iLO. Itu selalu dapat menghadirkan konsol (apakah OS dapat merespons atau tidak tergantung pada situasi spesifik Anda), dan menerapkan status daya yang diinginkan sesuai kebutuhan.

— mfinni
sumber

Ok, iDRAC adalah pilihan yang baik karena saya menggunakan server Dell tetapi saya berpikir tentang solusi yang lebih sederhana, mungkin sesuatu seperti memesan CPU untuk sshd (termasuk itu melahirkan anak-anak), semacam "QoS" untuk layanan lokal.

— Renato Todorov

Beberapa perusahaan bangkrut atau serakah: dalam kasus seperti itu, sysrqd dapat menjadi alternatif murah untuk iDRAC, iLO, KVM ...

— bgtvfr

Saya sudah beberapa kali berhasil memberikan hak istimewa realtime ke sshd, namun itu harus dibayar dengan me-reboot mesin jika salah satu proses realtime hilang.

Jadi, jika Anda ingin turun rute ini, mulai daemon ssh kedua yang hanya untuk keadaan darurat. :)

— Simon Richter
sumber

realtimesshd nampaknya berbahaya bagi saya, terutama pada port 22 (pemindaian SSH bisa menjadi serangan DoS - berjalan pada port alternatif dapat mengurangi itu, tapi saya masih takut ...)

— voretaq7

tidak masalah jika saya memblokir akses dari internet, sebenarnya satu-satunya rute saya ke server ini adalah melalui VPN. terima kasih atas sarannya!

— Renato Todorov