# SSH Session Timeout Issues



## Mike Z (Aug 16, 2016)

Hello Everyone,

I went into /etc/ssh/sshd_config and set the ClientAliveInterval to 30 (which I'm assuming means 30 seconds as per the man page), and I set the ClientAliveCountMax to 2. If I'm correct, this should logout an idle session after 60secs of inactivity, but it doesn't. I restarted the service after making the configurations just in case anyone asks. 

One thing to note is that I'm using RSA keys for authentication which I just figured out how to setup. I never had any issues when I was using password authentication, but something about the public-key authentication seems to be causing the issue. Does anyone have any ideas or troubleshooting advice? 

Thanks!!


----------



## Murph (Aug 16, 2016)

Those settings (ClientAlive*) are intended to keep idle SSH sessions alive, and to detect and disconnect a dead client (client or network gone away), not an idle client.  They can be useful for keeping things like NAT and firewall states from timing out and causing the TCP stream to fail.  You could try setting `ClientAliveCountMax 0`, which some stuff on the web suggests, but be aware that those settings are not intended to be used to disconnect idle sessions, so it could stop working in the future even if it happens to work today (this is essentially using a chisel to open tins of paint; it may happen to work, but it's not such a great idea and may break).  When the man page talks about disconnecting "unresponsive" clients, it's talking about the code failing to communicate, and not anything to do with human behaviour.

Personal opinion, but I would find a 60 second idle logout to be extremely obnoxious (to the point where I would very rapidly deploy configuration to defeat it), and it is well below the minimum I would ever suggest for disconnecting idle shells (5 minutes / 300 seconds, and even that can be annoyingly short).  I normally set 5 or 10 minutes on Cisco stuff where there's a small limit on max vtys, simply to avoid getting locked out of it for too long if sessions are dying due to network issues, and even that infuriates me at times (e.g. tab to the web to check on something, come back and session has been killed).  It makes me curious about exactly what problem you are trying to solve here, so you may get better suggestions by giving a more complete idea about what/why.

Some shells do have an auto/idle logout feature, but it's a per-shell thing.  E.g. autologout for csh(1), or TMOUT for bash(1).  I would suggest no less than an hour for normal-ish use cases, unless you have a really good reason to make it shorter.  It should generally be long enough to get a cup of coffee, take a quick pee / smoke break, read some documentation on the web, etc.

If the issue is security and users leaving terminals unattended, 60 seconds is plenty of time for an attacker to take over a terminal from a user who is in the habit of walking away for an extended period.  That issue needs to be solved through user education / penalties, and things like locking terminals before walking away.


----------



## SirDice (Aug 16, 2016)

Murph said:


> That issue needs to be solved through user education / penalties, and things like locking terminals before walking away.


If we find an unlocked terminal we tend to send an email to the department (as that user of course) telling everyone he/she will bring cakes to work tomorrow


----------



## Murph (Aug 16, 2016)

SirDice said:


> If we find an unlocked terminal we tend to send an email to the department (as that user of course) telling everyone he/she will bring cakes to work tomorrow


Nice, I like it!


----------



## Mike Z (Aug 16, 2016)

Thanks for the info Murph. I misunderstood the use for the ClientAlive settings. Also, I would never set an idle timeout to 1 min in actual practice. This server is just for me, so I don't have to worry about inconveniencing others with my settings, but still...1 min would make me go bonkers. I set it to 1 min in this case so I didn't have to wait too long to see if my configurations worked. Basically, I'm using WinSCP on the Windows side as my client, and on my Android phone I'm using ES File Explorer. WinSCP is no problem since it's very easy to disconnect a session when I'm done. However, ES File Explorer seems to leave a session running for an extended period of time without any obvious settings to disconnect. I might look through ES's settings to see if there is an idle logout setting somewhere, but is there any substantial security risk from leaving that session open while I'm not using it?


----------



## Murph (Aug 16, 2016)

Mike Z said:


> I might look through ES's settings to see if there is an idle logout setting somewhere, but is there any substantial security risk from leaving that session open while I'm not using it?



The risk there should pretty much be limited to someone getting physical control of the client device (and there not being any form of security lock active on it at the time).  The cryptography should basically keep the open session secure unless your data is worth a considerable amount of supercomputer time and the attention of certain people in Maryland or Cheltenham (who would be equally likely to have someone use a $5 wrench instead…).  That's assuming that both the SSH client and server are good implementations and up to date with security patches, you adhere to good practices for verifying remote SSH key fingerprints, and there's not any configuration on either client or server which has weakened the cryptography.

For maximum security, you can enable time based rekeying of open sessions, e.g. `RekeyLimit default 1d` in sshd_config(5).  That changes the session keys periodically, instead of just based on the volume of data since last rekey (which defaults to a limit based on the cipher in use).  For most purposes, it really isn't necessary, but it does raise the bar even higher by limiting the validity of a compromised session key.  I don't recommend setting a very short lifespan for session keys, in general, as that would just generate frequent additional crypto effort for very little benefit.

It does seem to be a questionable design choice to have any form of crypto client which does not have a simple and reliable means to disconnect/close sessions.


----------



## Mike Z (Aug 18, 2016)

Thanks a bunch Murph. I'm still pretty early in my IT career and these little experiments are invaluable learning tools. Again, thank you for your insight!


----------

