Ticket #193 (accepted defect)

Opened 8 years ago

Last modified 6 years ago

Session timeout after a very short time

Reported by: gmuller64 Owned by: alamaison
Priority: major (affects peripheral workflow) Milestone: 0.9.x Bug sprint
Component: authentication Version: 0.6.3
Keywords: session timeout Cc:


Yes, this is related to ticket #178, but since that ticket has been flagged as "closed" I'm creating a new ticket.
Swish is a great product and I love the Explorer shell integration. However, like the creator of ticket #178, being constantly prompted to reenter the password due to a session timeout (< 60 secs) is very frustrating!
I only have the timeout issue while using Swish. Connections using ssh or sftp (from Cygwin), Putty, WinSSH, WinSCP, etc to my SSH/SFTP server NEVER timeout!
Thus, it can't be the timeout settings on the SSH/SFTP server. FYI, the timeout settings in the sshd_config file are:
TCPKeepAlive yes
ClientAliveInterval? 30
ClientAliveCountMax? 4

Please note that corresponding timeout settings also exist for the SSH/SFTP client according to the RFC, which are:

It would appear to me that Swish is not responding to the client alive messages from (some) SSH/SFTP servers. The messages log on my WD NAS shows:
Jul 31 13:59:01 MyBookWorld? auth.info sshd[8766]: Disconnecting: Timeout, your session not responding.

Can you please investigate the session timeout issue again?

Change History

comment:1 Changed 8 years ago by alamaison

  • Status changed from new to accepted

Thank you for a detailed bug report. We will look into this. In the mean time you may want to upgrade to 0.7.0 which supports public key authentication through Pageant. Load your key into Pageant and it will reconnect without prompting you for a password. Of course, the problem still exists but it won't be as noticeable.

Can you tell me what SSH and SFTP servers are running on your NAS?

comment:2 Changed 8 years ago by gmuller64

The SFTP service is provided by the SSH server. The version details for my WD NAS are:

Western Digital My Book World Edition (WhiteLight? version)
Firmware version: 01.02.06
SSH version: OpenSSH_3.9p1 (with OpenSSL 0.9.7e)

I know this is a very old version of OpenSSH, but I'm not prepared to update the NAS firmware due to stability issues with later versions. However, I may be able to use OpenSSH from Optware, which is using OpenSSH 5.9p1.

The fact remains that I only get the timeout issue with Swish. Other SSH/SFTP clients work okay.

FYI, I don't get the timeout issue for Swish connection to Red Hat Ent Linux 5.8 server with OpenSSH 4.3p2 installed.

comment:3 Changed 8 years ago by gmuller64

Further testing has confirmed that timeout issue "goes away" when the ClientAliveInterval? and ClientAliveCountMax? options are not set/used in the SSH server's sshd_config file and only TCPKeepAlive is set to "yes". This is the case for my Red Hat server, which explains why I was not getting the timeout problem there.

According to the sshd_config man page, the value for the ClientAliveInterval? option is 0, which means that these messages will not be sent to the client. The man page also states that the client alive message are sent via the encrypted channel and therefore will not be spoofable unlike the TCPKeepAlive messages, which are spoofable. Thus, for increased security you should use client alive messages.

The default installation on my WD NAS has ClientAliveInterval? set to a no-zero value for increased security. After setting ClientAliveInterval? to '0' (or commenting it out) in the sshd_config file and restarting the SSH server daemon I was no longer getting the timeout problem resulting in frequent password prompts.

Thus the problem is easily reproducible and confirms (for me at least :-)) that Swish does not respond to client alive messages from a SSH server.

comment:4 Changed 8 years ago by alamaison

I've reproduced the problem at my end with an up-to-date of OpenSSH. It's a flaw in Swish (or possibly libssh2 which we sit on top of). libssh2 responds to keepalive requests but only as it processes an API call. If the client sits around doing nothing, as an idle Swish connection will, it isn't called so doesn't see the requests.

The solution is probably to run a thread to pump these messages somehow. But I'm not sure how yet.

Thanks for your very detailed reports. They make it much easier to narrow down a problem quickly.

comment:5 Changed 8 years ago by alamaison

  • Milestone changed from 0.7 Public-key authentication to 0.7.x Bug sprint

comment:6 Changed 8 years ago by alamaison

* Ticket #219 marked duplicate of this one *

comment:7 Changed 6 years ago by anonymous

I have v.0.8.2 and I am having the same issue... when will this get fixed?

Note: See TracTickets for help on using tickets.