Hi Chris -

You're correct rshstat is not available in ONTAP 7.2.6.x.

In attempt to isolate the problem, ssh is piggy-backed on top of rsh and telnet depending if ssh is interactive or not; so if rsh and telnet work then the problem is in ssh part. However if rsh does not work, hopefully, more information will be displayed. My thought is that all the rsh sessions and therefore ssh sessions have been consumed. The rshstat command would have told us. If all the rsh sessions are consumed, then unfortunately, a re-boot is needed.

All the options below look fine. Since the telnet.access and rsh.access is legacy, please check options trusted.hosts to make sure this is set correctly.

Regards,

- Rick -

-----Original Message----- From: Christopher B. Allison [mailto:cba@ccs.neu.edu] Sent: Wednesday, June 29, 2011 9:06 AM To: Ehrhart, Rick Cc: David N. Blank-Edelman; toasters@mathworks.com Subject: RE: kicking an unhappy ssh daemon

Hi Rick,

Thanks for your reply. I work for David, and am replying to this because

David is in meetings all day.

On Wed, 29 Jun 2011, Ehrhart, Rick wrote:

What is the version of ONTAP?

NetApp Release 7.2.6.1P9: Wed Aug 19 12:37:58 PDT 2009

Please show the output of "options ssh",

ssh.access host!=192.168.200.50 ssh.enable on ssh.idle.timeout 60 ssh.passwd_auth.enable on ssh.port 22 ssh.pubkey_auth.enable on ssh1.enable off ssh2.enable on

Note: We added the "host!=192.168.200.50" directive to block out our monitoring system when we thought it was consuming all the ssh slots. We've since discarded that theory, but haven't reverted the ssh block.

"options telnet"

telnet.access legacy telnet.distinct.enable off telnet.enable on

"options rsh".

rsh.access legacy rsh.enable on

Please show the output of "rshstat". "Do a "priv set advanced" first.

rshstat doesn't appear to be available on this filer, either in admin or

advanced privilege mode, though it is present on two filers we have running 8.0.x. Is rshstat available in ONTAP 7.2.6?

If it matters: I'm still investigating this on our side, but I believe the onset of the problem was actually tied to an influx of bad ssh attempts (brute force attack), rather than any configuration change on our part.

I'm happy to provide more information, including a detailed log of the attempts I've made to restart the ssh daemon, if it would be helpful.

Best,

-Chris Allison -- UNIX Systems Administrator College of Computer and Information Science Northeastern University, Boston, MA