Thus spake Sheldon Hearn ([EMAIL PROTECTED]) [28/08/03 04:21]: > On (2003/08/28 09:40), Guido van Rooij wrote: > > > > man sshd_config(5)? > > > > > > > > KeepAlive > > > > Specifies whether the system should send TCP keepalive messages > > > > > > This doesn't help with a stateful firewall, because KeepAlives happen > > > out-of-band. Read the manpage yourself. :-) > > > > What do you mean with out-of-band? It uses the same tcp connection > > and thus, w.r.t the ipf package, happens inbound.
(FYI, it's bad practice to quote someone on a public list when they mailed you privately. I don't see Guido's message posted to the public list.) I think the 'out-of-band' spoken about is out-of-band to the SSH connection (application layer), but still in-band for the TCP connection (transport layer). So the keep-alive packets are contained within that TCP session, but have some special header-type information in them that the SSH daemon/client know to ignore them. That means that from ipf's point of view, it's all in-band. But from SSH's point of view, it's OOB. I /believe/ -- correct me if I'm wrong. > What, KeepAlive? Are you sure? Positive. > I have all my ipf-protected hosts use this configuration: > > KeepAlive no > ClientAliveInterval 30 > ClientAliveCountMax 120 > > I've been doing this since about 2 years ago, because "KeepAlive yes" on > its own was guaranteed to hang my sessions. And I have been experiencing roughly the exact opposite. With ipf doing keep-state, if I set 'KeepAlive no', then when I'm gone for the night, all my sessions die. If I set 'KeepAlive yes', then all my sessions stay alive. > ClientAliveInterval > Sets a timeout interval in seconds after which if no data has been > received from the client, sshd will send a message through the > encrypted channel to request a response from the client. > ... > > ClientAliveCountMax > ... > It is important to note that the use of client alive messages is > very different from KeepAlive (below). The client alive messages > are sent through the encrypted channel and therefore will not > be spoofable. The TCP keepalive option enabled by KeepAlive is > spoofable. The client alive mechanism is valuable when the client or > server depend on knowing when a connection has become inac-tive. I don't know about you, but I don't want my client/server to know when the session has become inactive -- I don't like restarting 25 SSH sessions every morning. I'd prefer it if they just believed that the session was active all night long. This also seems to somewhat jive with my previous impression of what KeepAlive was doing. As for the inherent security risks of allowing portions of my SSH session to be spoofed... It's a keepalive packet. It's out-of-band, and it's not a control packet. It just says, 'Hey! This connection is still up!'. That's it.
