4 ms·

Assuming autossh is going just rerun whatever binary ssh points to, then you likely wont need a separate binary for this. Just run while true; do ...; done

Assuming autossh is going just rerun whatever binary ssh points to, then you likely wont need a separate binary for this. Just run while true; do ...; done and be done with it. The author does say that ... Some scripts use a while loop, others encourage you to run a remote command (such as tail) to make sure you don’t run into timeout and various others. But actually, you don’t want to re-invent the wheel and stick to bullet-proof already existing solutions. but the only case where that makes sense, and where a simple while loop will fail you, is if the ssh command hangs. Only then will this start making sense.

Piskvorrr 11y ago
1. SSH hanging is not altogether uncommon, esp. on repeated reconnect over flaky connections and/or crappy-but-stateful captive portals, experienced both; also, not every SSH server is OpenSSH, esp. various embedded dropbears have been imbued with nasty device-specific quirks. 2. a simple loop might fail you unless you've remembered to use -oBatchMode=true; also it would work iff every SSH connection is terminated cleanly; also also about 20 other minor warts. Very quickly, the "simple loop" starts being decidedly unsimple, and you'll find yourself reinventing a square wheel. Been there, done that. Then I found that someone else has already been through the same issues and made a comprehensive tool for it: autossh.
x0 11y ago
I'd put a `sleep 5s` or so in there as well, in case your wifi is off or something, and it's looping "no route to host" over and over.
- Piskvorrr 11y ago
  ...and a condition for this, and a bit of checking for that, and a SSH option, and a signal handler - and all of a sudden, you have replicated autossh 0.7, except buggier and in bash.
  - x0 11y ago
    Replace bash with zsh and you have my life story.
superuser2 11y ago
No. SSH connections break when I close my laptop. Probably happened several hundred times by now. The ssh executable terminates in this scenario exactly never. I have to close and reopen the terminal window - can't even Ctrl-C. Come to think if it I've never once experienced the ssh executable actually exiting by itself. I don't know what problem this script solves, but it's not the ubiquitous experience of "When I close my Mac my SSH sessions in Terminal become frozen."

Piskvorrr 11y ago

1. SSH hanging is not altogether uncommon, esp. on repeated reconnect over flaky connections and/or crappy-but-stateful captive portals, experienced both; also, not every SSH server is OpenSSH, esp. various embedded dropbears have been imbued with nasty device-specific quirks. 2. a simple loop might fail you unless you've remembered to use -oBatchMode=true; also it would work iff every SSH connection is terminated cleanly; also also about 20 other minor warts. Very quickly, the "simple loop" starts being decidedly unsimple, and you'll find yourself reinventing a square wheel. Been there, done that. Then I found that someone else has already been through the same issues and made a comprehensive tool for it: autossh.

x0 11y ago

I'd put a `sleep 5s` or so in there as well, in case your wifi is off or something, and it's looping "no route to host" over and over.

Piskvorrr 11y ago
...and a condition for this, and a bit of checking for that, and a SSH option, and a signal handler - and all of a sudden, you have replicated autossh 0.7, except buggier and in bash.
- x0 11y ago
  Replace bash with zsh and you have my life story.

superuser2 11y ago

No. SSH connections break when I close my laptop. Probably happened several hundred times by now. The ssh executable terminates in this scenario exactly never. I have to close and reopen the terminal window - can't even Ctrl-C. Come to think if it I've never once experienced the ssh executable actually exiting by itself. I don't know what problem this script solves, but it's not the ubiquitous experience of "When I close my Mac my SSH sessions in Terminal become frozen."