SSHD Processes Using 100% CPU

Jon, thanks for that script. Sent me off reading about FIFOs : D

For everyone experiencing this problem, please do submit a (polite) bug report at

http://bugreport.apple.com

You shouldn't be seeing this of course, and it's important that this issue get logged.

Thanks David - was unaware that there was such a site. Awesome!

I too have had the same problem. It's annoying because the only fix I had was to restart the computer all together. However, it does seem to be related to password issues as it only happens after a few random bots try to login to my computer. Or when I deliberately input incorrect passwords.

My temporary fix has been to add some IP based firewall rules to eliminate all the noise these annoying bots create. Basically I only allow SSH access on port 22 for IPs from home and work. Changing the SSHD port helps but the scanners still find the service now and then so the firewall is really the best method. We should all be doing that anyway in the first place.

Haven't had a problem since then. But hopefully Apple will get this fixed ASAP

Same here. No explanation for why sshd pegs the CPU at about 100%. Killing and restarting the process does NOT fix it...only a reboot of the machine. Grrr... I use ssh all the time, so disabling sshd is not an option. (And no, my machine is not being attacked.)

It looks like this is a race condition with devfs - I haven't figured out why it's looping rather than simply returning the failure (which the forkpty->openpty->grantpt->ioctl chain correctly propagates up) but I opened a bug report with the relevant traces:

rdar://5713758

I'd recommend everyone else do the same and perhaps mention that ID so it gets prioritized up inside the engineering group.

Yep... mine's been in since the 13th (of January)

rdar://5685756

Exact same problem, and i use a non standard port, and if any brute forces are detected they are blocked

Hopefully this will be fixed on 10.5.2

After looking around in the secure logs on my system the other day, I sure am interested about such a blocker 🙂 I've had quite some brute force attempts the latest weeks. However, when I tried to install sshdfilter, it complaint about some post flight script that could not be run, and the Installer said that the installation had failed. But the sshdfilter app was apparently installed as I can find it on my Mac. I even saw in the system log that it tried to start, but then it complained about that it couldn't read some sshd.fifo file. I checked that file out, and it seemed I didn't have permission to read it.

What should be noted is that I first tried the installation and application on OS 10.5.2, which might not be supported as yet? Glad if I could help, and I would be glad if you could help me 🙂

My bug was just closed as a duplicate of yours. Did they give you any timeframe for a fix? This doesn't happen often enough for me to want spend too much time on it but I might have to write a runaway ssh watchdog script for our compute systems.

I am also having this issue on 2 different Intel Mac Minis under 10.5.2 - so, no fix with the 10.5.2 release 😟 After a while, I can no longer run Terminal app. It goes to 100% CPU usage without displaying a window.

Argghhh!

Andy

Just a thought... Make sure you are not logging every failed and accepted packet. This will cause a similar spike in AFP usage as well.

Update with more info on my Mac Mini sshd and Terminal hangs. I have set up ipfw, allowing in only a single IP address for ssh. Still get hangs w/ 100% CPU utilization. Only error I can see in logs is:

kernel - devfs: ttys000: name slot allocation failed (Errno=17)

- Andy

Yeap - unfortunately the bug isn't due to network scanning or anything manageable. It's fairly deep in the way sshd opens a session up for a legitimate user (which is why it also affects Terminal.app) and there doesn't appear to be any way to solve that.

The only thing you can do is to open a bug report at bugreporter.apple.com - it'll be closed as a duplicate of Jon Bell's bug report (rdar://5685756) but it seems that the number of times a bug is reported does influence how quickly it gets fixed.

Is there any way the kernel can be reconfigured with more ttys to work around the problem?

Has anyone tried installing/compiling openssh as a fix to this issue? I don't have the luxury of experimentation as both my leopard servers are production machines. I have no idea what potential repercussions could result but if someone out there has a test environment, it might be worth a try. The openssh project claims to work with Mac OS X and is sure to work in FreeBSD environments since it is based on BSD.