Public bug reported:
I have three machines, called REMOTE, INTERNET, and LOCAL. REMOTE and
LOCAL are both behind firewalls (in completely separate places).
INTERNET is on the internet. I need to be able to SSH into REMOTE _from_
LOCAL. To do this I have done the following:
1. used autossh on LOCAL to set up a ssh tunnel from LOCAL to INTERNET, which
forwards INTERNET port 22222 back down the ssh tunnel to LOCAL port 22
2. used autossh on REMOTE to set up an ssh tunnel from REMOTE to INTERNET port
22222 (i.e., to LOCAL port 22) which forwards LOCAL port 10022 back down the
ssh tunnel to REMOTE port 22
This means that I can now, on LOCAL, do "ssh -p 10022 localhost" and be
connected to REMOTE.
The first tunnel, point 1, is fine. However, the second tunnel keeps
"freezing". A symptom of this is that port 10022 on LOCAL is "open" (I
can ssh to it and don't get a "Connection refused") but the connection
never connects. Looking at ps on LOCAL, I can see that there are many
sshd [priv] processes from the remote machine (I have 44 right now). If
I kill all these processes, then autossh on REMOTE seems to "notice"
that this has happened and start a new connection, which works fine.
So there are perhaps two issues here.
a. For some reason the ssh connection goes "stale" and can't be used to
connect. I do not know why this is; in particular, I don't know whether it's
caused by network dropouts or by configuration or what.
b. at some points, autossh seems to be realising that the connection doesn't
work and starting a new one (good, this is what it's for!) but it does not seem
to be killing the old one (which is why I've got 44 processes rather than one)
I do not know whether these are related; I do not know whether autossh
is starting a new process because the old one is stale, or for some
other reason. I do not know how to replicate the "connection goes stale"
issue; it happens over time, so if I come back to the tunnel after a day
then it will likely be stale, but connecting and reconnecting to it five
minutes later normally means it has not died in the interim. Testing
this is very slow because it can't be replicated (so I have to wait a
day for a problem to exhibit), and because I am administering REMOTE
over the very ssh tunnel that this system creates (so I am very wary of
doing anything that breaks the tunnel, because I can't recover from that
without a site visit).
The tunnel from REMOTE to LOCAL is created thus:
AUTOSSH_GATETIME=0
/usr/bin/autossh -M 0 -N -T -q -o ServerAliveInterval=30 -o
ServerAliveCountMax=3 -R 10022:localhost:22 -p 22222 remoteuser@INTERNET
The tunnel from LOCAL to INTERNET is created thus:
AUTOSSH_GATETIME=0
ExecStart=/usr/bin/autossh -q -N -o "ServerAliveInterval 60" -o
"ServerAliveCountMax 3" internetuser@INTERNET -R 0.0.0.0:22222:localhost:22
I am happy to do some diagnostics, but not at the expense of cutting me
off from the remote endpoint. I can provide tcpdumps, log files, etc to
support this bug if I'm given commands to run to produce them.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: autossh 1.4e-2
ProcVersionSignature: Ubuntu 4.4.0-79.100-generic 4.4.67
Uname: Linux 4.4.0-79-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.6
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Jun 26 11:16:19 2017
InstallationDate: Installed on 2014-04-07 (1176 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
SourcePackage: autossh
UpgradeStatus: Upgraded to xenial on 2016-08-04 (326 days ago)
** Affects: autossh (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug xenial
** Description changed:
- I have three machines, called REMOTE, DEST, and LOCAL. REMOTE and LOCAL
- are both behind firewalls (in completely separate places). INTERNET is
- on the internet. I need to be able to SSH into REMOTE _from_ LOCAL. To
- do this I have done the following:
+ I have three machines, called REMOTE, INTERNET, and LOCAL. REMOTE and
+ LOCAL are both behind firewalls (in completely separate places).
+ INTERNET is on the internet. I need to be able to SSH into REMOTE _from_
+ LOCAL. To do this I have done the following:
1. used autossh on LOCAL to set up a ssh tunnel from LOCAL to INTERNET, which
forwards INTERNET port 22222 back down the ssh tunnel to LOCAL port 22
2. used autossh on REMOTE to set up an ssh tunnel from REMOTE to INTERNET
port 22222 (i.e., to LOCAL port 22) which forwards LOCAL port 10022 back down
the ssh tunnel to REMOTE port 22
This means that I can now, on LOCAL, do "ssh -p 10022 localhost" and be
connected to REMOTE.
The first tunnel, point 1, is fine. However, the second tunnel keeps
"freezing". A symptom of this is that port 10022 on LOCAL is "open" (I
can ssh to it and don't get a "Connection refused") but the connection
never connects. Looking at ps on LOCAL, I can see that there are many
sshd [priv] processes from the remote machine (I have 44 right now). If
I kill all these processes, then autossh on REMOTE seems to "notice"
that this has happened and start a new connection, which works fine.
So there are perhaps two issues here.
a. For some reason the ssh connection goes "stale" and can't be used to
connect. I do not know why this is; in particular, I don't know whether it's
caused by network dropouts or by configuration or what.
b. at some points, autossh seems to be realising that the connection doesn't
work and starting a new one (good, this is what it's for!) but it does not seem
to be killing the old one (which is why I've got 44 processes rather than one)
I do not know whether these are related; I do not know whether autossh
is starting a new process because the old one is stale, or for some
other reason. I do not know how to replicate the "connection goes stale"
issue; it happens over time, so if I come back to the tunnel after a day
then it will likely be stale, but connecting and reconnecting to it five
minutes later normally means it has not died in the interim. Testing
this is very slow because it can't be replicated (so I have to wait a
day for a problem to exhibit), and because I am administering REMOTE
over the very ssh tunnel that this system creates (so I am very wary of
doing anything that breaks the tunnel, because I can't recover from that
without a site visit).
The tunnel from REMOTE to LOCAL is created thus:
AUTOSSH_GATETIME=0
/usr/bin/autossh -M 0 -N -T -q -o ServerAliveInterval=30 -o
ServerAliveCountMax=3 -R 10022:localhost:22 -p 22222 remoteuser@INTERNET
The tunnel from LOCAL to INTERNET is created thus:
AUTOSSH_GATETIME=0
ExecStart=/usr/bin/autossh -q -N -o "ServerAliveInterval 60" -o
"ServerAliveCountMax 3" internetuser@INTERNET -R 0.0.0.0:22222:localhost:22
I am happy to do some diagnostics, but not at the expense of cutting me
off from the remote endpoint. I can provide tcpdumps, log files, etc to
support this bug if I'm given commands to run to produce them.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: autossh 1.4e-2
ProcVersionSignature: Ubuntu 4.4.0-79.100-generic 4.4.67
Uname: Linux 4.4.0-79-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.6
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Jun 26 11:16:19 2017
InstallationDate: Installed on 2014-04-07 (1176 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64
(20131016.1)
SourcePackage: autossh
UpgradeStatus: Upgraded to xenial on 2016-08-04 (326 days ago)
** Summary changed:
- Autossh does not notice when connection "freezes", starts new connection
without removing the old one
+ Autossh does not notice when connection "freezes", starts new connection
without removing the old process
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1700498
Title:
Autossh does not notice when connection "freezes", starts new
connection without removing the old process
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autossh/+bug/1700498/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
