Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- Running sshd with high priority
- Fred Randall
January 10, 2005, 2:41 am
rate this thread
our only solution is to either:
1. Pull the network cables and allow all connections to time-out so we
can regain enough memory to login (even via console).
So far I have only seen this behavior in QA and DEV where immature code
is run or where load testing is occuring. However, it would be nice to
have a way to regain control even if the box is in a bad way.
Would it be advisable to run sshd with an elevated priority or are there
additional risks there. Redhat linux seems to default to a nice value
of 0, while AIX's default priority seems to be 20.
Thanks for any input.
Re: Running sshd with high priority
What about setting some ulimits (eg memory, CPU time) to prevent the
runaway in the first place?
Bumping up the priority of sshd shouldn't hurt much. The only risk I can
think of is that an attacker can soak up high-priority CPU cycles by
connecting repeatedly to sshd (but by the sound of it that's a smaller
risk than from the application...)
From what you describe, if there's not enough resources to log in at
the console then the box may be out of RAM or swaplocked or something,
in which case fiddling with priorities won't help.
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
- » protocol question - issue with exit-status inside unfinished data stream?
- — Newest thread in » Secure Shell Forum