Subscribe

Exceeded the maximum allowed ssh session in ontap 8.0.2P1

Hi,

We use a Linux Redhat to manage our filers (FAS 3240, FAS 3160)

Since the upgrade to Ontap 8.0.2P1 we have every week this message when we want to connect in SSH to our filer.

In the Linux Console : ssh_exchange_identification: Connection closed by remote host

In the Putty :

If I go to the system in RLM I see this message in console of the Filer:

gdc00181> Mon AugMon Aug 29 12:50:22 CEST [openssh.session.limit:in 29 12:fo]: Exceeded the maximum allowed ssh sessions: 24.

50:22 CEST [openssh.session.limit:info]: Exceeded the maximum allowed ssh sessions: 24.

The only workaroud found is to reboot the filer

I want to know if somebody have noticed the same problems

Thanks in advance

Jerome

Re: Exceeded the maximum allowed ssh session in ontap 8.0.2P1

Hello,

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)

I'll reply again if we fix it without a reboot.

Exceeded the maximum allowed ssh session in ontap 8.0.2P1

Looks like an 8.0.2P3 fix for this.

Exceeded the maximum allowed ssh session in ontap 8.0.2P1

which isn't out yet but I keep checking every day since it will be worth the ssh fix.

Re: Exceeded the maximum allowed ssh session in ontap 8.0.2P1

Do you know where I can view the details of this bug?

Re: Exceeded the maximum allowed ssh session in ontap 8.0.2P1

I had a customer hit it but was an internal burt I couldn't view. Support will know though on your existing case.

Typos Sent on Blackberry Wireless

Re: Exceeded the maximum allowed ssh session in ontap 8.0.2P1

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.)

Re: Exceeded the maximum allowed ssh session in ontap 8.0.2P1

we open a case for that and we had an answer of the support:

it's a bug, here is the burt :

http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=484047

http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=514876

it's corrected in version :  ONTAP 8.0.2P2D4 

I will try this version and let you know.


Re: Exceeded the maximum allowed ssh session in ontap 8.0.2P1

Thanks for those links - support couldn't provide them. we experienced activity similar to the one in 48407:

<foobar ~>  sudo tcpdump -i eth1 'host toaster1'

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes

00:17:50.276938 IP foobar.40047 > toaster1.ssh: Flags [S] [...]

00:17:50.277795 IP toaster1.ssh > foobar.40047: Flags [S.] [...]

00:17:50.277813 IP foobar.40047 > toaster1.ssh: Flags [.] [...]

00:17:50.278732 IP toaster1.ssh > foobar.40047: Flags [F.] [...]

00:17:50.279027 IP foobar.40047 > toaster1.ssh: Flags [F.] [...]

00:17:50.279842 IP toaster1.ssh > foobar.40047: Flags [.] [...]

Since this is a minor-rev upgrade, we would be able to do it without taking down the cluster. Let us know how it goes and if you continue seeing symptoms;

Re: Exceeded the maximum allowed ssh session in ontap 8.0.2P1

This is different than the bug where all 24 ssh sessions are locked and can’t be deleted…or might be in this fix but I don’t see it in the fix list.