2.' If autossh itself receives a SIGTERM, SIGINT, or a SIGKILL signal, it assumes that it was deliberately signalled, and exits after killing the child ssh process;
3.' If autossh itself receives a SIGUSR1 signal, it kills the child ssh process and starts a new one;
4.' Periodically (by default every 10 minutes), autossh attempts to pass traffic on the monitor forwarded port. If this fails, autossh will kill the child ssh process (if it is still running) and start a new one;
5.' If the child ssh process dies for any other reason, autossh will attempt to start a new one.
If the ssh session fails with an exit status of 1 on the very first try, autossh
1.' will assume that there is some problem with syntax or the connection setup, and will exit rather than retrying;
2.' There is a "starting gate" time. If the first ssh process fails within the first few seconds of being started, autossh assumes that it never made it "out of the starting gate", and exits. This is to handle initial failed authentication, connection, etc. This time is 30 seconds by default, and can be adjusted (see the AUTOSSH_GATETIME environment variable below). If AUTOSSH_GATETIME is set to 0, then both behaviours are disabled: there is no "starting gate", and autossh will restart even if ssh fails on the first run with an exit status of 1. The "starting gate" time is also set to 0 when the -f flag to autossh is used.
If the ssh connection fails and attempts to restart it fail in quick succession, autossh will start delaying its attempts to restart, gradually backing farther and farther off up to a maximum interval of the autossh poll time (usually 10 minutes). autossh can be "prodded" to retry by signalling it, perhaps with SIGHUP ("kill -HUP").
As connections must be established unattended, the use of autossh requires that some form of automatic authentication be set up. The use of RSAAuthentication with ssh-agent is the recommended method. The example wrapper script attempts to check if there is an agent running for the current environment, and to start one if there isn't.
It cannot be stressed enough that you must make sure ssh works on its own, that you can set up the session you want before you try to run it under autossh
If you are tunnelling and using an older version of ssh that does not support the -N flag, you should upgrade (your version has security flaws). If you can't upgrade, you may wish to do as rstunnel does, and give ssh a command to run, such as "sleep 99999999999".