ssh ServerAlive

[smasher]

I was having two opposite problems at the same time:

1. Interactive ssh logins to the AC68U would drop out randomly, and
2. non-interactive ssh logins would hang indefinitely after the connection died

Solution to the first problem: Disable "ServerAliveInterval" . See the ssh_config man-page for details, but dropbear doesn't support this, and it doesn't support it in a way that can cause idle connections to disconnect, seemingly "at random". Now my "~/.ssh/config" includes this

Host    ac68u.lan
        HostName                RT-AC68U-1234.lan
        User                    admin
        ConnectTimeout          10
        RequestTTY              yes
        ServerAliveInterval     0

The important thing here is "ServerAliveInterval 0".

Make sure the ssh_config spec for "ControlPath" includes the "%n" token. Again, refer to the man-page.

nb, if you're testing this, make sure any persistent shared connections are closed with "ssh -O exit ac68u.lan", otherwise you'll just be reconnecting to the same ssh tunnel, and the config changes won't have any effect.

Next problem: When running a command like:

ssh sh.ac68u.lan  'cat /dev/urandom' > /tmp/file

I've had too many problems with the ssh connection dying, but the command just hangs, acting like everything is fine. In these cases, I want the ssh command to exit if the connection isn't passing data. In these cases, I want an idle connection to make the ssh command exit. Back to my "~/.ssh/config"

## create an alias for remote commands                                          
## and let this one break connections if it goes quiet                          
Host    sh.ac68u.lan
        HostName                RT-AC68U-1234.lan
        User                    admin
        ConnectTimeout          10
        RequestTTY              no
        ServerAliveInterval     5
        ServerAliveCountMax     2

This creates an alias "sh.ac68u.lan", and when I ssh to that, it sends a "ServerAlive" packet every five seconds (ServerAliveInterval 5), and if two of them (ServerAliveCountMax 2) don't get answered (and they won't; dropbear just ignores them) the connection will die after ten seconds.

Use "ssh -G" to check that it's doing what you think it's doing.


Also, you can use "ssh -vvvv". This will show ServerAlive as "debug3: send packet: type 80". If there are responses, they'll show up as "debug3: receive packet: type 82". Don't expect any responses from dropbear, but this can be tested with other ssh servers.

 

[Dabombber]

Seems like an awkward workaround to your ssh client not properly detecting lost connections. Setting ConnectTimeout by itself should be enough shouldn't it, are you sure TCPKeepAlive is enabled?

 

[smasher]

Setting ConnectTimeout by itself should be enough shouldn't it, are you sure TCPKeepAlive is enabled?

ConnectTimeout only affects connections as they're being made/attempted... eg, "how long should I keep trying to initiate a connection before quitting". It has no affect on closing connections after they've been opened.

From the man page, "TCPKeepAlive ... This option only uses TCP keepalives (as opposed to using ssh level keepalives), so takes a long time to notice when the connection dies. As such, you probably want the ServerAliveInterval option as well." Basically, the ServerAlive options can be tuned more finely, and be more responsive to failure.