title: cannot establish a robust ssh reverse tunnel with autossh: takes long time for a new tunnel to be established after failure
body: <p>I am trying to establish a robust ssh tunnel with autossh. I have a home server (home), that is reachable from the internet, and a backup server (backup), that is behind a firewall and not reachable from the internet. To be able to ssh into backup from home, I want to set up a reverse ssh tunnel.</p>
  <p>I am able to do so, set up keys etc, and this works fine. I now want to &quot;robustify&quot; my ssh tunnel to changes of IPs (my ISPs provide dynamic IPs), network failures etc. I am trying to use autossh for this purpose, but with no success.</p>
  <p>What I do:</p>
  <p>on backup, I start the following (I forward another port than the port 22 to the port 22 of my main server, to avoid clugging of port 22 logs by people trying to break on port 22):</p>
  <p>(note: I obfuscate a bit the logs to not provide my IP :) ):</p>
  <pre><code>$ /usr/bin/autossh -o ServerAliveInterval=1 -o ExitOnForwardFailure=yes -NR 8085:localhost:22 ssh_forwarding_user_on_main@address_of_main -v -p SOME_PORT_OTHER_THAN_22
  </code></pre>
  <p>Once this is done, I can do on main:</p>
  <pre><code>$ ssh pi@localhost -p 8085 -o PreferredAuthentications=publickey
  </code></pre>
  <p>and this works just fine, as expected :) .</p>
  <p>However, if I change the public IP address of the backup server (by jumping from my home network to my mobile phone as an access point for example), the reverse tunnel and ssh connection die, and it seems like autossh is not able to restore the ssh reverse tunnel :( .</p>
  <p>Looking at the logs (thanks to the <code>-v</code>) of the autossh reverse tunnel, I see first that:</p>
  <pre><code>Timeout, server MYSERVER not responding.
  OpenSSH_8.4p1 Raspbian-5+b1, OpenSSL 1.1.1k  25 Mar 2021
  </code></pre>
  <p>I.e., autossh has well detected that the ssh reverse tunnel was lost, but then:</p>
  <pre><code>debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
  debug1: /etc/ssh/ssh_config line 21: Applying options for *
  debug1: Connecting to MY_MAIN_SERVER [MY_MAIN__IP] port SOME_PORT_OTHER_THAN_22.
  debug1: Connection established.
  debug1: identity file /home/pi/.ssh/id_rsa type -1
  debug1: identity file /home/pi/.ssh/id_rsa-cert type -1
  debug1: identity file /home/pi/.ssh/id_dsa type -1
  debug1: identity file /home/pi/.ssh/id_dsa-cert type -1
  debug1: identity file /home/pi/.ssh/id_ecdsa type -1
  debug1: identity file /home/pi/.ssh/id_ecdsa-cert type -1
  debug1: identity file /home/pi/.ssh/id_ecdsa_sk type -1
  debug1: identity file /home/pi/.ssh/id_ecdsa_sk-cert type -1
  debug1: identity file /home/pi/.ssh/id_ed25519 type -1
  debug1: identity file /home/pi/.ssh/id_ed25519-cert type -1
  debug1: identity file /home/pi/.ssh/id_ed25519_sk type -1
  debug1: identity file /home/pi/.ssh/id_ed25519_sk-cert type -1
  debug1: identity file /home/pi/.ssh/id_xmss type -1
  debug1: identity file /home/pi/.ssh/id_xmss-cert type -1
  debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Raspbian-5+b1
  debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u2+rpt1
  debug1: match: OpenSSH_7.9p1 Debian-10+deb10u2+rpt1 pat OpenSSH* compat 0x04000000
  debug1: Authenticating to MAIN:OTHER_THAN_22 as 'SOME_USER'
  debug1: SSH2_MSG_KEXINIT sent
  debug1: SSH2_MSG_KEXINIT received
  debug1: kex: algorithm: curve25519-sha256
  debug1: kex: host key algorithm: ecdsa-sha2-nistp256
  debug1: kex: server-&gt;client cipher: chacha20-poly1305@openssh.com MAC: &lt;implicit&gt; compression: none
  debug1: kex: client-&gt;server cipher: chacha20-poly1305@openssh.com MAC: &lt;implicit&gt; compression: none
  debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
  debug1: Server host key: ecdsa-sha2-nistp256 SHA256:OTC3Mln4Z99L2HGvnClKbT3pyKdTaEdW5fOGWXo5t3A
  debug1: Host '[MAIN]:NOT_22' is known and matches the ECDSA host key.
  debug1: Found key in /home/pi/.ssh/known_hosts:2
  debug1: rekey out after 134217728 blocks
  debug1: SSH2_MSG_NEWKEYS sent
  debug1: expecting SSH2_MSG_NEWKEYS
  debug1: SSH2_MSG_NEWKEYS received
  debug1: rekey in after 134217728 blocks
  debug1: Will attempt key: pi@raspberrypi RSA SHA256:A29ooC6kJ8xwStSziTKZJlkJ5nzabqDR12cMhcgFR+E agent
  debug1: Will attempt key: /home/pi/.ssh/id_rsa 
  debug1: Will attempt key: /home/pi/.ssh/id_dsa 
  debug1: Will attempt key: /home/pi/.ssh/id_ecdsa 
  debug1: Will attempt key: /home/pi/.ssh/id_ecdsa_sk 
  debug1: Will attempt key: /home/pi/.ssh/id_ed25519 
  debug1: Will attempt key: /home/pi/.ssh/id_ed25519_sk 
  debug1: Will attempt key: /home/pi/.ssh/id_xmss 
  debug1: SSH2_MSG_EXT_INFO received
  debug1: kex_input_ext_info: server-sig-algs=&lt;ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521&gt;
  debug1: SSH2_MSG_SERVICE_ACCEPT received
  debug1: Authentications that can continue: publickey,password
  debug1: Next authentication method: publickey
  debug1: Offering public key: pi@raspberrypi RSA SHA256:A29ooC6kJ8xwStSziTKZJlkJ5nzabqDR12cMhcgFR+E agent
  debug1: Server accepts key: pi@raspberrypi RSA SHA256:A29ooC6kJ8xwStSziTKZJlkJ5nzabqDR12cMhcgFR+E agent
  debug1: Authentication succeeded (publickey).
  Authenticated to MAIN ([MAIN_IP]:NOT_22).
  debug1: Local connections to LOCALHOST:51547 forwarded to remote address 127.0.0.1:51547
  debug1: Local forwarding listening on ::1 port 51547.
  debug1: channel 0: new [port listener]
  debug1: Local forwarding listening on 127.0.0.1 port 51547.
  debug1: channel 1: new [port listener]
  debug1: Remote connections from LOCALHOST:51547 forwarded to local address 127.0.0.1:51548
  debug1: Remote connections from LOCALHOST:8090 forwarded to local address localhost:22
  debug1: ssh_init_forwarding: expecting replies for 1 forwards
  debug1: Requesting no-more-sessions@openssh.com
  debug1: Entering interactive session.
  debug1: pledge: network
  debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
  debug1: Remote: /home/SOME_USER/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
  debug1: Remote: /home/SOME_USER/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
  debug1: remote forward failure for: listen 51547, connect 127.0.0.1:51548
  Warning: remote port forwarding failed for listen port 51547
  debug1: forwarding_success: all expected forwarding replies received
  debug1: remote forward failure for: listen 8090, connect localhost:22
  Warning: remote port forwarding failed for listen port 8090
  </code></pre>
  <p>So it seems that autossh correctly detects that the tunnel went down, and correctly re-connects to the main server. However, for some reason I do not understand, the ssh tunnel is not restored.</p>
  <p><strong>Edit</strong></p>
  <p>I went off from my computer to have a cup of coffee, and when I came back, magics, the following had been added to the output:</p>
  <pre><code>debug1: Connection to port 51547 forwarding to 127.0.0.1 port 51547 requested.
  debug1: channel 2: new [direct-tcpip]
  channel 2: open failed: administratively prohibited: open failed
  debug1: channel 2: free: direct-tcpip: listening port 51547 for 127.0.0.1 port 51547, connect from 127.0.0.1 port 45238 to 127.0.0.1 port 51547, nchannels 3
  debug1: channel 0: free: port listener, nchannels 2
  debug1: channel 1: free: port listener, nchannels 1
  Transferred: sent 24480, received 9928 bytes, in 614.4 seconds
  Bytes per second: sent 39.8, received 16.2
  debug1: Exit status 0
  OpenSSH_8.4p1 Raspbian-5+b1, OpenSSL 1.1.1k  25 Mar 2021
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
  debug1: /etc/ssh/ssh_config line 21: Applying options for *
  [following is similar to the initial successful connection]
  </code></pre>
  <p>and now the reverse tunnel seems to be active again :) . But it took a good 5 or 10 minutes before the tunnel came back. Any idea how to make sure the tunnel comes back faster? ...</p>