Hi Josh, On 27 June 2015 at 17:59, Josh Grosse <[email protected]> wrote: > On Sat, Jun 27, 2015 at 05:10:54PM -0700, jungle Boogie wrote: >> Hello All, >> >> I know fewer defaults the better for all, but if there a reason >> TCPKeepAlive in openssh is disabled along with the clientalive option? >> Is it just too risky and/or unneeded? > > Well, Mr. Boogie, TCPKeepAlive is enabled and ClientAliveInterval is 0, > which is disabled, in both 5.7 and -current, if I'm reading the source > file correctly.
I'm sure you're reading it correctly. Maybe in the portable its disabled, I'll have to check closely. > > And, according to sshd_config(5), "It is important to note that the > use of client alive messages is very different from TCPKeepAlive....The > client alive messages are sent through the encrypted channel and > therefore will not be spoofable. The TCP keepalive option enabled by > TCPKeepAlive is spoofable." quite interesting, thanks! > >> How do you folks manage ssh sessions not dying? Do you enable these >> options every time you install openssh on a new machine? Is there a >> better option? > > The man page continues with, "The client alive mechanism > is valuable when the client or server depend on knowing when a > connection has become inactive." > > I don't adjust the defaults for these. I use some terrible > WiFi connections and occaisionally have to reconnect. If I need > to keep a shell running in the event of an unintentional > disconnect --- or an intentional one -- I use tmux(1). > I can reconnect and continue operating one or more shells > without any operational impact. Yes, tmux is wonderful and I'm thankful for Nicholas' work on it! The problem is if you're doing reverse tunnelling, the tmux connection doesn't really solve that problem, though. -- ------- inum: 883510009027723 sip: [email protected] xmpp: [email protected]
