Hi all,
i've recently reinstalled my previous distro with fc20-beta and observing strange ssh tunels disconnection. i'm establishing tunels in this way:
ssh -2fCN -p ${non-default port} -L ${local_port}:${endpoint}:{$endpoint_port} ${login}@${gatE}.
after some time (mostly few minutes) all unused ssh tunels die. any ideas?
BR, Paweł.
On 5 December 2013 11:59, Paweł Sikora pawel.sikora@agmk.net wrote:
Hi all,
i've recently reinstalled my previous distro with fc20-beta and observing strange ssh tunels disconnection. i'm establishing tunels in this way:
ssh -2fCN -p ${non-default port} -L ${local_port}:${endpoint}:{$endpoint_port} ${login}@${gatE}.
after some time (mostly few minutes) all unused ssh tunels die. any ideas?
Hi: What about launching the ssh with -vvv or similar? It looks like the ConnectTimeout parameter wasn't working properly.
Kind regards
On 05.12.2013 16:04, Carlos "casep" Sepulveda wrote:
On 5 December 2013 11:59, Paweł Sikora pawel.sikora@agmk.net wrote:
Hi all,
i've recently reinstalled my previous distro with fc20-beta and observing strange ssh tunels disconnection. i'm establishing tunels in this way:
ssh -2fCN -p ${non-default port} -L ${local_port}:${endpoint}:{$endpoint_port} ${login}@${gatE}.
after some time (mostly few minutes) all unused ssh tunels die. any ideas?
Hi: What about launching the ssh with -vvv or similar? It looks like the ConnectTimeout parameter wasn't working properly.
Kind regards
Are you able to direct people to the proper lists!? F20 ain't an official, so https://admin.fedoraproject.org/mailman/listinfo/test
poma
On 5 December 2013 12:22, poma pomidorabelisima@gmail.com wrote:
Are you able to direct people to the proper lists!?
Well, the ConnectTimeout parameter in ssh_config is by default 1, (and he need to set it ot 0), in any Fedora, so it isn't a "Fedora 20" issue. Unless he already has it on 0 and it's not working, then could be a "Fedora 20 only issue".
I don't see the real harm of this thread.
On 05.12.2013 16:33, Carlos "casep" Sepulveda wrote:
On 5 December 2013 12:22, poma pomidorabelisima@gmail.com wrote:
Are you able to direct people to the proper lists!?
Well, the ConnectTimeout parameter in ssh_config is by default 1, (and he need to set it ot 0), in any Fedora, so it isn't a "Fedora 20" issue. Unless he already has it on 0 and it's not working, then could be a "Fedora 20 only issue".
I don't see the real harm of this thread.
Aahh, Smartass! Uhmm can I be your friend?
poma
Quoting "Carlos "casep" Sepulveda" casep@fedoraproject.org:
On 5 December 2013 11:59, Paweł Sikora pawel.sikora@agmk.net wrote:
Hi all,
i've recently reinstalled my previous distro with fc20-beta and observing strange ssh tunels disconnection. i'm establishing tunels in this way:
ssh -2fCN -p ${non-default port} -L ${local_port}:${endpoint}:{$endpoint_port} ${login}@${gatE}.
after some time (mostly few minutes) all unused ssh tunels die. any ideas?
Hi: What about launching the ssh with -vvv or similar? It looks like the ConnectTimeout parameter wasn't working properly.
Kind regards
Or, maybe you need a "keep-alive" signal to keep the tunnel open? It's basically just a matter of sending a ping or two every couple minutes.
On Thursday 05 of December 2013 10:34:02 John Aldrich wrote:
Quoting "Carlos "casep" Sepulveda" casep@fedoraproject.org:
On 5 December 2013 11:59, Paweł Sikora pawel.sikora@agmk.net wrote:
Hi all,
i've recently reinstalled my previous distro with fc20-beta and observing strange ssh tunels disconnection. i'm establishing tunels in this way:
ssh -2fCN -p ${non-default port} -L ${local_port}:${endpoint}:{$endpoint_port} ${login}@${gatE}.
after some time (mostly few minutes) all unused ssh tunels die. any ideas?
Hi: What about launching the ssh with -vvv or similar? It looks like the ConnectTimeout parameter wasn't working properly.
Kind regards
Or, maybe you need a "keep-alive" signal to keep the tunnel open? It's basically just a matter of sending a ping or two every couple minutes.
ok, i've found a difference between default fc20 installation and my previous distro. the /etc/ssh/ssh_config in fc20 doesn't contain following options:
ServerAliveInterval 60 ServerAliveCountMax 10 TCPKeepAlive no
On Thursday 05 of December 2013 12:04:07 Carlos casep Sepulveda wrote:
On 5 December 2013 11:59, Paweł Sikora pawel.sikora@agmk.net wrote:
Hi all,
i've recently reinstalled my previous distro with fc20-beta and observing strange ssh tunels disconnection. i'm establishing tunels in this way:
ssh -2fCN -p ${non-default port} -L ${local_port}:${endpoint}:{$endpoint_port} ${login}@${gatE}.
after some time (mostly few minutes) all unused ssh tunels die. any ideas?
Hi: What about launching the ssh with -vvv or similar?
here's example debug log from short web session (firefox+ 2x page reload +quit) via tunnel.
(... authorization cut ...)
debug1: Local connections to LOCALHOST:1235 forwarded to remote address gnats:8888 debug3: channel_setup_fwd_listener: type 2 wildcard 0 addr NULL debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY debug1: Local forwarding listening on ::1 port 1235. debug2: fd 4 setting O_NONBLOCK debug3: fd 4 is O_NONBLOCK debug1: channel 0: new [port listener] debug1: Local forwarding listening on 127.0.0.1 port 1235. debug2: fd 5 setting O_NONBLOCK debug3: fd 5 is O_NONBLOCK debug1: channel 1: new [port listener] debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: Connection to port 1235 forwarding to gnats port 8888 requested. debug2: fd 6 setting TCP_NODELAY debug2: fd 6 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 2: new [direct-tcpip] debug2: channel 2: open confirm rwindow 2097152 rmax 32768 debug2: channel 2: window 1997193 sent adjust 99959 debug2: channel 2: window 1993720 sent adjust 103432 debug2: channel 2: window 1994781 sent adjust 102371 debug2: channel 2: window 1997613 sent adjust 99539 debug2: channel 2: rcvd eof debug2: channel 2: output open -> drain debug1: channel 2: forcing write debug2: channel 2: obuf empty debug2: channel 2: close_write debug2: channel 2: output drain -> closed debug2: channel 2: read<=0 rfd 6 len 0 debug2: channel 2: read failed debug2: channel 2: close_read debug2: channel 2: input open -> drain debug2: channel 2: ibuf empty debug2: channel 2: send eof debug2: channel 2: input drain -> closed debug2: channel 2: send close debug3: channel 2: will not send data after close debug2: channel 2: rcvd close debug3: channel 2: will not send data after close debug2: channel 2: is dead debug2: channel 2: garbage collecting debug1: channel 2: free: direct-tcpip: listening port 1235 for gnats port 8888, connect from ::1 port 50175, nchannels 3 debug3: channel 2: status: The following connections are open: #2 direct-tcpip: listening port 1235 for gnats port 8888, connect from ::1 port 50175 (t4 r0 i3/0 o3/0 fd 6/6 cc -1)
debug1: Connection to port 1235 forwarding to gnats port 8888 requested. debug2: fd 6 setting TCP_NODELAY debug2: fd 6 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 2: new [direct-tcpip] debug2: channel 2: open confirm rwindow 2097152 rmax 32768 debug2: channel 2: read<=0 rfd 6 len 0 debug2: channel 2: read failed debug2: channel 2: close_read debug2: channel 2: input open -> drain debug2: channel 2: ibuf empty debug2: channel 2: send eof debug2: channel 2: input drain -> closed debug2: channel 2: rcvd eof debug2: channel 2: output open -> drain debug2: channel 2: obuf empty debug2: channel 2: close_write debug2: channel 2: output drain -> closed debug2: channel 2: rcvd close debug3: channel 2: will not send data after close debug2: channel 2: send close debug2: channel 2: is dead debug2: channel 2: garbage collecting debug1: channel 2: free: direct-tcpip: listening port 1235 for gnats port 8888, connect from ::1 port 50176, nchannels 3 debug3: channel 2: status: The following connections are open: #2 direct-tcpip: listening port 1235 for gnats port 8888, connect from ::1 port 50176 (t4 r0 i3/0 o3/0 fd 6/6 cc -1)
debug1: Connection to port 1235 forwarding to gnats port 8888 requested. debug2: fd 6 setting TCP_NODELAY debug2: fd 6 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 2: new [direct-tcpip] debug2: channel 2: open confirm rwindow 2097152 rmax 32768 debug2: channel 2: read<=0 rfd 6 len 0 debug2: channel 2: read failed debug2: channel 2: close_read debug2: channel 2: input open -> drain debug2: channel 2: ibuf empty debug2: channel 2: send eof debug2: channel 2: input drain -> closed debug2: channel 2: write failed debug2: channel 2: close_write debug2: channel 2: chan_shutdown_write: shutdown() failed for fd 6: Transport endpoint is not connected debug2: channel 2: output open -> closed debug2: channel 2: send close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug3: channel 2: will not send data after close debug2: channel 2: rcvd eof debug2: channel 2: rcvd close debug3: channel 2: will not send data after close debug2: channel 2: is dead debug2: channel 2: garbage collecting debug1: channel 2: free: direct-tcpip: listening port 1235 for gnats port 8888, connect from ::1 port 50479, nchannels 3 debug3: channel 2: status: The following connections are open: #2 direct-tcpip: listening port 1235 for gnats port 8888, connect from ::1 port 50479 (t4 r0 i3/0 o3/0 fd 6/6 cc -1)
Write failed: Broken pipe
On 05.12.2013 19:13, Paweł Sikora wrote:
here's example debug log from short web session (firefox+ 2x page reload +quit) via tunnel.
(... authorization cut ...)
https://fpaste.org & F20 ain't an official, so https://admin.fedoraproject.org/mailman/listinfo/test
poma
-
Carlos "casep" Sepulveda -
John Aldrich -
Paweł Sikora -
poma