You're not the only one - ssh is the only way we manage our filers, so this puts effectively puts us down until netapp can fix it. This happened after a recent upgrade from 6070->6280s to 8.0.2.p2 (7mode)
So, no fix or workaround - apparently OnTap is completely opaque (even to the diaguser systemshell on FreeBSD); killing the sshd process inside of ontap (which is separate from the one running under inetd in systemshell) is impossible. We just went through a hellishly obstructive (paperwork-wise) upgrade of our main netapp filers, and are now going to have to do it again in a few weeks when 8.0.2p3 comes out. This is extremely bad for us, because ssh is the only way we manage the filers. All of our scripts will have to be rewritten temporarily and insecure protocols turned on for us to do anything with these filers.
To anyone else that experiences this issue and finds this thread - don't waste your time with the diaguser for the entire day trying to find a way to fix it like I did! (Or just wait for 8x to become stable if you haven't upgraded yet.)
Ah, I thought they were one in the same, since we're seeing both the [openssh.session.limit:info] error in the RLM (that's how I found this thread) and the premature FIN (as per the packet trace above.) I hope they're not being tracked and fixed as two separate bugs - that would really be a kick in the nuts if we had to upgrade to 8.0.2p4 a month or so after upgrading to 8.0.2p3.
Found this thread while searching for more info on bug id 514876.
I dont know if the problem your having is the same we've had for over a year now, but I was able to fix this by doing the following (pasted from our internal wiki):
I used SecureCRT for this fix, putty has similar options and should work but was not tested.
Configure SSH session to filer to run a 'Remote Command' unpon login. I simply used '?'.
Connect to filer, enter credentials and the session will fail/close.
Remove the 'remote command' settings from your session options.
Connect to filer and it should now work.
Hope this helps some of you. I never saw messages regarding the 24 sessions, but we arn't on 8.0.2x yet. But i've had this particular issue since 7.3.3, currently on 8.0.1P5 (also have seen this on 4 separate v3140s. Never experienced on our v3240.)