Request for testers: New ssh handling in sftp backend

I’ve merged PR #1564 today which changes the way the ssh program is run for the sftp backend. The problem was that when users press CTRL+C, the terminal sends a SIGINT signal to both the restic process and the ssh process, causing the ssh process to exit immediately. restic was then unable to remove the lock file and an error was returned.

The first try to mitigate that was starting the ssh process in its own “Process Group”, but then ssh is unable to use the TTY and ask the user for a password.

With the new code, ssh is still run in its own process group, but this time it is set to be the “foreground process group” until the sftp connection is established.

So, it’d be awesome if some of you could test the new code with the sftp backend and report back if:

  • SSH correctly queries for a password (if necessary)
  • Cancelling e.g. a check operation correctly removes the lock file from the repo

You can find a precompiled binary of today’s master branch here:



I’ve did some tests with restic-v0.8.1-55-g663e8284, and I did not see any error.

I’ve tested using the ssh password, and also using the ssh keys. Restic prompted for the password when needed.

After I interrupted restic with CTRL-C there was no problem with a following run. Neither using keys nor password.

I noticed however that after interrupting it took some seconds (3 à 5) before the commandline prompt reappeared.

Kind regards.

Thanks for testing it! When you cancel it, it may happen that there’s still some data to be transferred, and restic will try to finish that, before it removes the lock file.

I will do some tests with restic-v0.8.1-55-g663e8284 and report back.

All good so far for me. Tested the windows build against an SFTP repo on Unbuntu 16.04.3

I have interrupted the “restic check” by CTRL - C and found no locks on my repo