Henrik Nordstrom wrote:
On Wed, 8 Jun 2005, Mogens Valentin wrote:
WRT ssh, on the sshd side of things, for protocol 2 at least,
ClientAliveInterval/ClientAliveCountMax can easily keep that ssh
session open over the weekend.
So can enabling TCP keep-alives.
Yes. But, at least for SSH, keep-alive is spoofable; ClientAlive is not.
Works well for me with a 10 min conntrack timeout, no probs with any
other services for weeks now. Saves a lot of entries in the table.
10 mins is a bit too agressive. Which this please make absolutely sure
you RST unknown traffic rather than dropping it regardless of from where
it is seen. If not you risk causing a bit of trouble to various servers
by their client connections suddenly going numb..
Sure, I do RST those..
However, I'd still like to know which other normally occuring TCP
stuff needs such a looong establishment.
Any protocol supporting long idle phases. The obvious ones is the
interactive protocols
Telnet
SSH
rsh/rlogin
ftp
etc
Right, but then again, I don't believe in unsafe connections.
Never had a problem with ftp after reducing my timeout..
But when talking as short timeouts as 10 minutes you also have to worry
about very many other protocols
Various SQL/ODBC protocols
HTTP/HTTPS in combination with certain applicaitons
NFS
SMB
etc. And depending on your situation some of these may well belong to
the first category above requiring very long established timeouts.
I see your point. I should've been more specific, my fault.
The timeout of cause depends upon the intended use.
I my case, doing internal test/integration, and connecting to servers
for systems administration, I have control of what I do, so I can have a
short timeout.
For other uses, one will have to analyse the setup, or stick with
defaults. However, others have commented (directly) they've reduced the
estblished timeout significantly without problems.
I guess maybe I stand partly corrected ;)
--
Kind regards,
Mogens Valentin
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
