Re: slogin & telnet 60-minute timeout---SOLVED
I was logging in from my office Debian computer
through an office firewall, through my home Debian computer's firewall
into my home Debian computer.
Then a timeout occured at 60 minutes.
When a friend slogin from his Debian home computer
to my Debian home computer, no timeout occured.
THE TIMEOUT PROBLEM RESIDED IN MY OFFICE'S CISCO ROUTERS OR ITS FIREWALL
The solution to this timeout can be found within comments
of the following perl script,
http://www.humbug.org.au/ssh-https-tunnel
Specifically, he says,
Many proxies will timeout connections very quickly
when there is no activity.
If your ssh client supports it, ADD THE FOLLOWING TO THE
~/.ssh/config file. #Debian-email: or to /etc/ssh/ssh_config?
ProtocolKeepAlives 5
Another popular method is to X-Forward something
like "xclock -update 5" to keep the connection "active."
After some reading, I see that this ProtocolKeepAlives
is set for the ssh client, not for the sshd daemon.
It sends ssh IGNORE (SSH_MSG_IGNORE) packets.
Tangential: I must upgrade my office computer from potato to woody
to get a newer ssh using ProtocolKeepAlives.
---Jim Burt
On Fri, May 24, 2002 at 04:31:18PM -0400, Jameson C. Burt wrote:
> Ever since upgrading to woody 8 months ago,
> both my slogin and telnet sessions lock after idling 60 minutes.
> These sessions still work after 50 minutes idling,
> but lock after 1 hour 10 minutes idling.
> After 2 hours, the remote host ends
> both the original "ssh" [telnet] and spawned "bash" processes.
> Both the remote and local computers run Debian Linux,
> and the remote Debian computer seems to cause the locking.
> I would like my slogin working as before my upgrade to woody,
> without idle timeouts every 60 minutes.
> I welcome any suggestions.
>
> Following are some of my many attempts and 35 hours of effort
> to solve this problem.
> These attempts almost [but nothing is absolute]
> rule out timeouts arising from any of,
> slogin and the spawned ssh daemon [or telnet]
> bash shell
> iptables and its conntrack
>
> 1. SLOGIN and TELNET
> After my slogin [telnet] connection locks (at 1 hour)
> and before it disappears (2 hours),
> both "ssh" [in.telnetd] and its spawned "bash" shell
> remain running processes on the remote Debian computer.
> And "slogin" [telnet] remains a running process
> on the local Debian computer.
> From this, I conclude that ssh [telnet] has not timed-out,
> and ssh [telnet] has not caused my local xterm to lock.
>
> Additionally, this timeout problem occurs
> with both slogin and telnet,
> adding support that the problem does not lie in either.
>
> 2. BASH
> If on the target computer I set "TMOUT=5",
> 5 seconds later I get the message,
> timed out waiting for input: auto-logout
> Because this message differs from the message I get
> with a slogin or telnet timeout
> after 120 minutes (60 minutes while locked),
> Read from remote host bbmo.com: Connection timed out
> then I conclude that my problem does not come
> from the bash shell TMOUT variable.
>
> 3. IPTABLES/NETFILTER
> The ultimate test with iptables would flush the firewall and check
> for any timeout.
> Unfortunately, the logs on my remote computer show numerous
> nefarious connections attempts,
> so I won't bring down iptables without disconnecting my DSL cable.
> However, I have observed the following.
>
> Iptable's/netfilter's connection tracking (conntrack)
> for "-m state" base rules appears to work correctly,
> since the third column of,
> /proc/net/ip_conntrack
> counts down by seconds from 5 days (hardcoded into the netfilter
> file .../net/ipv4/netfilter/linux-2.5.17.tar.bz2),
> 432,000 #seconds
> After the 428,400 second countdown mark (1 hour or 3600 seconds),
> I still see netfilte's conntrack working;
> indeed, after some time, I saw a count as low as
> (just before 2 hours or 7200 seconds when this remote computer
> removed the connection),
> 424,842 #seconds
> Soon after this, the remote computer removed
> both the "ssh" and "bash" processes, at which time this conntrack
> count was reset to 5 hours,
> 432,000
> then a few minutes later, this conntrack line was removed.
> At that time, neither computer had any ghosts
> of slogin [telnet] session, except in log files.
>
> Here are two example conntrack lines I observed,
> the first for ssh (sport=22), and the second for telnet (sport=223).
> Remember, the third column represents the number of seconds
> until netfilter times-out.
>
> tcp 6 431811 ESTABLISHED \
> src=199.129.208.230 dst=66.92.166.19 sport=724 dport=22 \
> src=66.92.166.19 dst=199.129.208.230 sport=22 dport=724 \
> [ASSURED] use=1
> #
> tcp 6 425116 ESTABLISHED \
> src=199.129.208.230 dst=66.92.166.19 sport=2468 dport=23 \
> src=66.92.166.19 dst=199.129.208.230 sport=23 dport=2468 \
> [ASSURED] use=1
>
>
>
> WORKAROUND: a process that displays on the local screen
> from the remote screen can keep the connection open.
> For example, the following process sends a message
> from the remote computer to the local computer every 10 minutes,
> keeping the connection open past even 2 hours.
> while : ; do date; sleep 600; done
>
>
> Both my remote computer and my local computer run Debian Linux.
> The remote computer to which I slogin runs Debian's woody.
> The local computer still runs Debian's potato.
> The local potato computer can slogin to an AIX computer
> and remain logged in for weeks.
> I would like to do that same eternal slogin to my remote Debian woody computer.
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: