Re: Masqueraded SSH connection timeouts?

2002-06-29 Thread Kenneth E. Lussier

On Sat, 2002-06-29 at 16:27, Michael O'Donnell wrote:
> 
> 
> I haven't gathered all the evidence in this
> matter as carefully as I might, but here's a
> problem I think I'm seeing: once I've established
> SSH sessions from machines behind my firewall to
> certain remote machines, they die (pretty much to
> the second) after two hours if I just leave them
> idle.  If I establish identical client sessions on
> (instead of through) my firewall machine those
> idle sessions seem to stay up indefinitely.

This would probably be caused by the masq timeout set in your firewall
script. You should have a line like:

ipchains -M -S 7200 0 0

which translates to:

ipchains --masquerade --set-session-timeout-in-seconds tcp tcpfin udp

So, if a session is idle, it will time out after two hours. If the
session is active, it will time out two hours after it becomes idle.

FYI,
Kenny 



*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*



Re: Masqueraded SSH connection timeouts?

2002-06-29 Thread bscott

On Sat, 29 Jun 2002, at 4:27pm, Michael O'Donnell wrote:
> ... once I've established SSH sessions from machines behind my firewall to
> certain remote machines, they die (pretty much to the second) after two
> hours if I just leave them idle.

  In order to make masquerading happen, the firewall has to keep track of
the state of each connection being masqueraded.  There are timeouts built-in
to the firewall to keep abnormally terminated connections (e.g., host lost
power) from exhausting resources.

  When SSH is idle, no packets are being exchanged for that TCP session.  
Eventually, the firewall decides the session is dead, and stops keeping
track of it.  The next time activity actually occurs in SSH, the firewall
rejects the packets ("Connection reset by peer"), since the firewall has
"forgotten" about the session.

  The default timeout period for an open TCP session in Linux 2.2 is ten
minutes.  I suspect your connections are actually dieing a lot sooner than
two hours; it is simply not noticed right away, since SSH is idle.

> If I establish identical client sessions on (instead of through) my
> firewall machine those idle sessions seem to stay up indefinitely.

  Right, because when you initiate from the firewall, no masquerading needs
to be done -- the packets already are from that host.

> The SSH configs on all my client machines are pretty much out-of-the-box
> defaults; I haven't messed with any of the keepalives or other options and
> I'd prefer not to until I understand what's going on here.

  Assuming you are running a reasonably recent version of OpenSSH, add the
following line to your  file.  It causes  to
send a sort of "ping" via the SSH encrypted channel every sixty seconds.  
That will keep any firewall or other connection monitor happy.

ClientAliveInterval 60

  The above option only applies to SSH protocol version 2, and thus will not
help for SSH protocol version 1 clients.  It is also not supported properly
by all SSH protocol 2 client implementations, so it may cause premature
disconnects in some cases.  It may therefore require some testing in your
environment.

  OpenSSH's  also has a "KeepAlive" option, which is supposed to 
accomplish the same thing.  However, in our experience, it does not always 
work, while the above does.

  If adding the above is not possible, you can look at the "-S -M" command
in ipchains(8).  Increasing the open TCP session timeout may help.  
However, increasing it too far may lead to problems with resource
exhaustion on the firewall.

  Hope this helps,

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |




*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*



Masqueraded SSH connection timeouts?

2002-06-29 Thread Michael O'Donnell



I haven't gathered all the evidence in this
matter as carefully as I might, but here's a
problem I think I'm seeing: once I've established
SSH sessions from machines behind my firewall to
certain remote machines, they die (pretty much to
the second) after two hours if I just leave them
idle.  If I establish identical client sessions on
(instead of through) my firewall machine those
idle sessions seem to stay up indefinitely.

The message seen when the sessions die is:

 Read from remote host xxx.yyy.com: Connection reset by peer
 Connection to xxx.yyy.com closed.

The sshd I'm connecting to is elsewhere on
the Internet and the same one in all cases.
My firewall machine is an unremarkable Linux box
running the current "testing" flavor of Debian
and using ipchains for masquerading and such.
I'm not really knowledgable about such matters
so I don't know how (or even "if" - this is all
still just suspicion) something in my firewall box
could be imposing such timeouts on the masqueraded
connection.  Any ideas?  Is the remote sshd maybe
trying to open some connection back to the client
and being prevented by the firewall?

The SSH configs on all my client machines are pretty
much out-of-the-box defaults; I haven't messed with
any of the keepalives or other options and I'd prefer
not to until I understand what's going on here.


*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*