SSHD Processes Using 100% CPU

The problem doesn't appear to be Apple's supplied OpenSSH build - the same bug affects Terminal's ability to open a new window/tab because everything which creates a terminal session makes the same openpty() syscall and that's where the actual failure occurs.

I, too, get this problem. I'm on Mac OS X 10.5.2.

Mostly with ssh-ing in from other places, or by opening xterm.

A few people in this thread have made some good observations, but I don't think there's an easy fix. I believe it's something Apple needs to fix in Mac OS X.

Hey!

The problem seems to be fixed with latest Leopard update: "Security Update 2008-2"

I can now ssh into my systems and run Terminal app.

Andy

FYI - With 2008-2 installed on 10.5.2, still get crashed sshd processes.

Wrote too soon. I am still having issues with sshd and Terminal app - even after Security Update 2008-2. Still seeing 100% CPU utilization for sshd and Terminal app hang.

Bummer!

Of interest, my Mac Pro 10.5.2 server had 100% utilization on two threads for the sshd. I went through the security log files and it looks like the system has been getting brutally hit by thousands of attempted logins every day. I adjusted my firewall and hopefully that will solve the problem.

i've been embarassed by this issue too.
i think something wrong in allocating pseudo ptys.
if you got this trouble, try "slogin -T servername". -T disables allocating ptys so probably you can login to the server (but without tty).

We've got what seems to be one of the same problems as in this thread. sshd hangs during login and then the process sits consuming nearly an entire CPU (on a 8 cpu Xserve) - 10.5.2 - problem was evident on 10.5.0 and 10.5.1 but seems worse now.

I built Portable OpenSSH 5.0p1 with PAM support and it does the same thing. It seems to get hung up in PAM processing:

...
debug3: mm sshpamrespond
debug3: mm requestsend entering: type 52
debug3: mm sshpamrespond: waiting for MONITOR ANS_PAMRESPOND
debug3: mm request_receiveexpect entering: type 53
debug3: mm requestreceive entering
debug3: monitor_read: checking request 52
debug3: mm answer_pamrespond
debug2: PAM: sshpam_respond entering, 1 responses
debug3: ssh msgsend: type 6
debug3: mm requestsend entering: type 53
debug3: mm requestreceive entering
debug3: mm sshpamrespond: pam_respond returned 1
debug3: mm sshpamquery
debug3: mm requestsend entering: type 50
debug3: mm sshpamquery: waiting for MONITOR ANS_PAMQUERY
debug3: mm request_receiveexpect entering: type 51
debug3: mm requestreceive entering
debug3: monitor_read: checking request 50
debug3: mm answer_pamquery
debug3: PAM: sshpam_query entering
debug3: ssh msgrecv entering
...

It would be nice if the sshd worked so we could get some development done.

I filed a bugreport in any event.

same problem for us. Intel quad-core X serve @ 2.8GHz leopard server 10.5.2

Something interesting happened to me: I activated SACL for SSH and allowed a staff group and the admin user... and ssh started working like a charm ! Before that, only admin could connect through ssh and all other attempts by regular users blocked sshd.

Even more interesting, even after I went back to the original SACL settings (i.e. no access control at all), ssh was still working properly.

After a very basic search, it appears that /etc/aliases.db and /etc/postfix/aliases have been modified at the time I activated SACL.

Could someone try this ?

Hi Davidh,
I've checked those links but couldn't find how to configure ssh daemon to only allow login via shared keys and not user/password keying.
Anybody knows where I can get info on this?
Thanks,
Inacio

Hi icordoba. I answered here:
http://discussions.apple.com/thread.jspa?threadID=1495224

Seeing this though on my Macbook Pro (running 10.5 non-server, but has same behavior). How's this for strange -- if I'm connected to the server using Remote Desktop, and:
1. The sshd process is pegging at 100%
2. And then I kill the sshd process
3. And then I try to open the Terminal (it'll hang)
4. And leave the terminal at 99% cpu
5. THEN try ssh'ing in...it works.

However, killing the Terminal process and then trying to ssh in again triggers the problem once more.

I am seeing this exact problem on two different xServes running 10.5.2.

I have to Remote in and kill the sshd processes and then my CPU % being used goes way down.

I am lucky, I can turn off SSH and use ARD to get control of the xServes when needed, but this won't last for long.

I was having the same problem, apparently related to failed ssh logins. I'd get one or two new runaway sshd processes within 5-10 minutes, then up to five more within the next half hour.

Ever since I turned off IPv6 on that interface it hasn't recurred (knock on wood,) even though I'm still getting regular dictionary login attempts from a botnet (sshdfilter has slowed this down immensely, btw.)

HTH.