tcp session timeout. Linux 2.6 | dropbear ssh server
Marco Peng
Thanks for your reading. :-)
I meet a problem, I use dropbear as a ssh server.
I limit the concurrent session max = 1.
If I login after a logout, all work good.
But if I shutdown my client without logout, I cannot login again.
Can some one give my some hints to handle this case ?
How can I change the system TCP session time out for my next login
without the last logout?
The server OS is linux 2.6
I limit the concurrent session max =1 with the instruction:
"tcpsvd -vv -c 1 -C 1 0 22 /usr/sbin/dropbear -r /etc/rsa_key.priv -i -
E -x &"
any response will be appreciated!
Marco Peng.
Rick Jones
If I recall correctly, ssh defines an application-layer keepalive
mechanism. It would be best to look into enabling that to clear-out
your half-open sessions.
rick jones
--
I don't interest myself in "why." I think more often in terms of
"when," sometimes "where;" always "how much." - Joubert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Jorgen Grahn
> Marco Peng <marco...@gmail.com> wrote:
>
>> Thanks for your reading. :-)
>> I meet a problem, I use dropbear as a ssh server.
>> I limit the concurrent session max = 1.
>> If I login after a logout, all work good.
>> But if I shutdown my client without logout, I cannot login again.
>> Can some one give my some hints to handle this case ?
>> How can I change the system TCP session time out for my next login
>> without the last logout?
> If I recall correctly, ssh defines an application-layer keepalive
> mechanism. It would be best to look into enabling that to clear-out
> your half-open sessions.
It has (or at least OpenSSH has).
And implicit in your answer is this (correct me if I'm wrong): if
someone pulls the plug on the client, the server isn't automatially
going to notice. You need application activity for that.
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
Rick Jones
> And implicit in your answer is this (correct me if I'm wrong): if
> someone pulls the plug on the client, the server isn't automatially
> going to notice. You need application activity for that.
Indeed application activity is the best way to clear-out connections.
Now, for completeness, there is in the TCP standard the concept of a
"keepalive probe" that TCP can be asked to emit after the connection
has been idle for some length of time. By default that is disabled
and the application must make a setsockopt() call to enable it. The
system-wide defaults on a 2.6.ish kernel visible in the output of
"sysctl -a | grep keep" If you tweak those you are affecting all
applications which are enabling TCP_KEEPALIVE. IIRC documented in the
Linux 2.6 tcp(7) manpage are some linux-specific setsockopt() calls an
application can make to alter the settings for a given connection.
Still, IMO and in the opinion of many others, it is best to use an
application-layer "are you still there" mechanism - the TCP_KEEPALIVE
mechanism by definition will not detect a present but hung application
because it never gets above TCP. Further, those linux-specific
per-connection setsockopt() calls are not portable.
rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
David Schwartz
> I meet a problem, I use dropbear as a ssh server.
> I limit the concurrent session max = 1.
This strikes me as an incredibly bad idea. If there's some problem
within existing session, you can't log in to fix it, as you have
discovered. Are you really sure that's what you want to do? In any
event, 'dropbear' has a '-K' option to keep the connection active and
a '-I' option to break the connection on inactivity.
DS
Barry Margolin
<0df35d0a-48f2-4d6d...@o5g2000prh.googlegroups.com>,
David Schwartz <dav...@webmaster.com> wrote:
Everyone's recommending turning on keepalives, but I don't understand
why this is necessary for the OP's problem. It sounds like dropbear has
a bug. When he closes the ssh connection, it should send a FIN and
dropbear should realize that the session no longer exists.
Keepalive is necessary if he pulls the network cable or powers down the
client machine without cleanly shutting down ssh first. But he said
"shutdown my client without logout".
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Jorgen Grahn
> In article
> <0df35d0a-48f2-4d6d...@o5g2000prh.googlegroups.com>,
> David Schwartz <dav...@webmaster.com> wrote:
>
>> On Jun 24, 2:28�am, Marco Peng <marco.p...@gmail.com> wrote:
>>
>> > I meet a problem, I use dropbear as a ssh server.
>> > I limit the concurrent session max = 1.
>>
>> This strikes me as an incredibly bad idea. If there's some problem
>> within existing session, you can't log in to fix it, as you have
>> discovered. Are you really sure that's what you want to do? In any
>> event, 'dropbear' has a '-K' option to keep the connection active and
>> a '-I' option to break the connection on inactivity.
>>
>> DS
>
> Everyone's recommending turning on keepalives, but I don't understand
> why this is necessary for the OP's problem. It sounds like dropbear has
> a bug. When he closes the ssh connection, it should send a FIN and
> dropbear should realize that the session no longer exists.
>
> Keepalive is necessary if he pulls the network cable or powers down the
> client machine without cleanly shutting down ssh first. But he said
> "shutdown my client without logout".
I kind of assumed he didn't mean "controlled shutdown" as in e.g.
shutting down a Unix machine, but rather hitting the power switch.
Maybe he's using some hand-held wireless device. Either way, he
should have explained better what he's doing and why.
It's interesting in a way ... back in the days I used to shut down
my Commodore-Amiga by just turning power off, because there was no
disk write cache to speak of. With TCP, it's antisocial to do so
because it may leave state on other hosts across the world.
I wonder if the "Host Requirements" RFC, 1123 or whatever it is,
mentions this. That an Internet host should RST before going down,
in decent shutdown scenarios.
Pascal Hambourg
Rick Jones a ï¿œcrit :
>
> Now, for completeness, there is in the TCP standard the concept of a
> "keepalive probe" that TCP can be asked to emit after the connection
> has been idle for some length of time.>
IIRC, the minimum recommended delay for TCP keepalive is 2 hours. I'm
afraid this would not be very helpful in the OP's situation.
Marco Peng
I use tcpsvd to limit the concurrent dropbear handled connection.
It's I mentioned early "tcpsvd -vv -c 1 -C 1 0 22 /usr/sbin/dropbear -
r /etc/rsa_key.priv -i -
E -x &"
in this mode, dropbear will not create a real socket, how can I
setsockopt()??
I can only change the dropbear code. is there a way to achieve my
goal?
Marco. Peng
Jorgen Grahn
[top-posting fixed]
> On Jun 24, 5:28�pm, Marco Peng <marco.p...@gmail.com> wrote:
>> Hi All
>>
>> Thanks for your reading. :-)
>> I meet a problem, I use dropbear as a ssh server.
>> I limit the concurrent session max = 1.
>> If I login after a logout, all work good.
>> But if I shutdown my client without logout, I cannot login again.
>> Can some one give my some hints to handle this case ?
>> How can I change the system TCP session time out for my next login
>> without the last logout?
>>
>> The server OS is linux 2.6
>> I limit the concurrent session max =1 with the instruction:
>> "tcpsvd -vv -c 1 -C 1 0 22 /usr/sbin/dropbear -r /etc/rsa_key.priv -i -
>> E -x &"
>>
>> any response will be appreciated!
> thanks everyone. I noticed the TCP timeout mechanism, but specially,
> I use tcpsvd to limit the concurrent dropbear handled connection.
> It's I mentioned early "tcpsvd -vv -c 1 -C 1 0 22 /usr/sbin/dropbear -
> r /etc/rsa_key.priv -i -
> E -x &"
> So is there any other concern on this service form?
> in this mode, dropbear will not create a real socket, how can I setsockopt()??
Are you sure its fd 0/1 isn't a real socket?
> I can only change the dropbear code. is there a way to achieve my
> goal?
First do what Barry Magol suggested and explain why you need to do
this. You are asking for trouble when you forbid more than one
connection, and make sure clients get hung a lot.