Hi Farrell,
That's an interesting idea. But like you said, if the server suddenly
disappears off the network then the client won't be told to die if we do
idle timeouts and/or keep alives. The server alive in OpenSSH is
request/response so it ensures that the client can figure out the
connection is hozed even if the server is frozen. Fortunately it doesn't
look too hard to port over support from OpenSSH. I should hopefully have
a messy patch today that I can tidy up.
Thanks,
Ahilan
Farrell Aultman wrote:
Hello Ahilan,
Look at the Idletimeout option, "-I". Try to run "-I" on the client.
To the best of my remembrance, you are correct, -K only sends keep alive
messages and doesn't actually check for any response. Some type of keep
alive will have to be sent from the server side for this to work. I
don't recall if there is a response to -K (when sending keep alives from
the client), so you may have to send keep alives from the server to the
clients.
What I do is run -I on the server and -K on the clients to detect when
clients have went down and shut down the server process, which causes
the client to die. But if my server process died, I'd be screwed too.
Farrell
On Tue, Dec 8, 2009 at 6:47 PM, Ahilan Anantha <[email protected]
<mailto:[email protected]>> wrote:
Hi List,
I plan to use "dbclient" as a low memory footprint alternative to
OpenSSH's "ssh" for SSH tunnels.
On the client I have software that creates SSH tunnels to many
systems. Sometimes the connection to these remote systems will
break, at which point "ssh" will exit. The exit gets detected and
the connection gets reestablished. But this works in "ssh" because
I'm using the ServerAliveInterval and ServerAliveCountMax options.
Without them, ssh would never check that the connection was up and
I'd have to wait an eternity for a TCP timeout. Or implement my own
heartbeat on top of the tunnel.
dbclient instead has a "-K" option. It's been suggested on this
mailing list that this basically did the same thing... but based on
my testing that doesn't appear to be true. At least for the case of
dbclient against an OpenSSH server.
I ran "dbclient -K 3" against an OpenSSH server. Then I sent a
SIGSTOP to the sshd child process servicing the connection. dbclient
did not terminate the session within any reasonable amount of time.
Perhaps if I waited a really long time, I would see a TCP timeout.
When I try the same with an "ssh -oServerAliveInterval=3
-oServerAliveCountMax=1", the ssh client disconnects very quickly:
"Disconnecting: Timeout, server not responding."
After comparing the OpenSSH and dropbear source code, it appears to
me that dropbear implements the equivalent of OpenSSH's "TCP keep
alive" but not "server alive".
In the case of "server alive", OpenSSH requires a response from the
server. Each server alive interval it checks to see how many server
alive requests are outstanding. If that count exceeds the max
(default is 3), it terminates the connection. In the case of "TCP
keep alive", ssh sends a message with no response requested. In this
case, it's just trying to maintain some activity over the stream so
that intermediate firewalls don't kill it as an idle connection.
Is this a known issue? Has anyone else asked for this?
Regards,
Ahilan
