SSH disconnects after 60mins - unexpectedly closed network connection

[GREG_WALKER]

Hi all,

I've got an issue across all 4 of our v3240 filers (2 HA pairs).  I am connecting to them via ssh, using public key encryption to authenticate to root account without any isue.  I can work with the filers for exactly an hour, before I get booed out of my ssh session with "Server unexpectedly closed network connection".  This happens with both Putty and Kitty ssh clients, and I have disabled all the autologout options i can find, and set all timeouts to over 60mins, but it is still disconnecting me.  It happens regardless of activity within the session, sometimes I am in the middle of entering commands when it kicks me out. 

toaster> options autologout

autologout.console.enable    off        (value might be overwritten in takeover)

autologout.console.timeout   540        (value might be overwritten in takeover)

autologout.telnet.enable     off        (value might be overwritten in takeover)

autologout.telnet.timeout    2880       (value might be overwritten in takeover)

toaster> options ssh

ssh.access                   *

ssh.enable                   on

ssh.idle.timeout             31536000

ssh.passwd_auth.enable       on

ssh.port                     22

ssh.pubkey_auth.enable       on

ssh1.enable                  off

ssh2.enable                  on

[aborzenkov]

Do you have any firewall, NAT or similar device in the network path?

[GREG_WALKER]

No, there is a WAN link between myself and one pair, but I am in the office next to one datacentre with an affected pair.  There's no firewall configured on my workstation either.  I'm certain it's the filers that are disconnecting me, as I often open up 4 KiTTY sessions to each of the filers one after another.  It takes me a few seconds of clicking to launch each session in turn, and one hour later, I can see the disconnect messages appear with the same few secconds between each session.

[RAESIDEPAUL · Accepted solution]

open putty > got to change settings > connection > ssh > kex  change "Max Minutes before rekey (0 for no limit)" to 0 for no limit. I bet yours is set to 60 right now...

[TINKERDUDE1]

I had the exact same problem. Drove me nuts for months. But RAESIDEPAUL got it right (putty ssh/kex timeout config) and all is well now. RAESIDEPAUL should get credit for a correct answer.

[TONY_BARNETT]

I made this change in putty and still get disconnected exactly 60 minutes after login.

filer2> options autologout

autologout.console.enable    on         (value might be overwritten in takeover)

autologout.console.timeout   300        (value might be overwritten in takeover)

autologout.telnet.enable     on         (value might be overwritten in takeover)

autologout.telnet.timeout    300        (value might be overwritten in takeover)

filer2> options ssh

ssh.access                   *

ssh.enable                   on

ssh.idle.timeout             0

ssh.passwd_auth.enable       on

ssh.port                     22

ssh.pubkey_auth.enable       on

ssh1.enable                  off

ssh2.enable                  on

[TONY_BARNETT]

Disregard.  I made a boo-boo.  This did fix my issue also. 

Thanks!

[NICOLAS_MELAY]

As could be guessed from its name, fiddling with rekey settings is not a good idea security wise.

You should NOT do this.

http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter4.html#config-ssh-kex-rekey

If you change it anyway, do so on a custom saved session, not in the default PuTTY session.

The real fix for this problem lies in NetApp's hands: ONTAP's SSH server needs rekey support.

Edit:

The NetApp bug has actually been accounted for by PuTTY's developper, and there's a workaround.

You just need to enable it in the "bugs" page.

That's much better than totally disabling rekeying.

Have been using it for the last few days, so far so good.

[XQ10907RS]

this workaround works for me,thanks!

[koumoun_nik]

anks a lot this was the proper answer, it solved my problem as well.

[GVM666GVM]

RAESIDEPAUL

You are totally right fixed my problem as well!

GREG.WALKER: please mark this thread as solved if it was for you.