I've been using SSH to establish some remote port forwards.

ssh -NT -o ServerAliveInterval=20 -o ExitOnForwardFailure=yes -o ConnectTimeout=10  -R 22001:localhost:22 -R 59001:localhost:5900 user001@server_host

This seems to work well and I can access the ssh and vnc on the client machine via the opened server_hosts ports.

But I've found that occasionally that one of the port forwards can eventually fail after being established and this does not cause ExitOnForwardFailure to be exercised. eg A netstat on the server shows that 22001 is open, but 59001 is closed, and on the client the ssh command is still running happily.

Am I misunderstanding the operation of ExitOnForwardFailure for this usage? when I am expecting it to exit in this situation.

How can I ensure that SSH exits if either of the two port forwards in a command fails, and even if this failure didn't happen while establishing them?

  • By "failing" do you mean that sshd stops listening? or some actual (established) connection to 59001 gets terminated? At the moment I can't imagine the former, but the latter is normal and tells nothing about the condition of port forwarding itself. Auxiliary question: do you use netstat -l or just netstat? My point is sshd should listen on the port and it's not its job to monitor how many actual connections are being forwarded. Please edit the question and clarify. If sshd really stops listening, some log(s) may be useful. Jun 20, 2019 at 10:23
  • sshd is still listening to port 22001 and forwarding data to that port. I have not monitored if an already established connection through 59001 gets terminated. I know that I can not establish new connections through 59001. I use netstat -tulpn and 59001 is not listed. I think this suggests that sshd is no longer listening to port 59001 and forwarding the data received at that port. Jul 18, 2019 at 6:51
  • Any suggestions on where to look for more logging would be appreciated. Jul 18, 2019 at 6:52
  • I think you cannot forcefully free the port without killing the listening process, so if the port is no longer listened at, it's either because sshd died or it stopped listening by itself. In my tests the same sshd process listens on both ports. If it was killed, you would lose the entire SSH connection. It appears in your case it "chose" not to listen anymore. Jul 18, 2019 at 16:03
  • If you are in charge of the server, run a separate sshd -d on another port, use it for port forwarding and monitor the output. Or increase the LogLevel in /etc/ssh/sshd_config, reload the regular sshd service and monitor its logs (sudo journalctl _SYSTEMD_UNIT=ssh.service? – I'm not sure, please do your own research). Jul 18, 2019 at 16:07

1 Answer 1


Commenting in SSH source indicates that the ExitOnForwardFailure option is only intended to cause an exit if the bind(2) fails.


int exit_on_forward_failure; /* Exit if bind(2) fails for -L/-R */

According to the question, the initial binding of the ports succeeded. So the ExitOnForwardFailure will not cause an exit.

Unsure on how to produce the desired behavior requested in the question.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .