I sftp'd into the wrong machine, and noticed ^C (Ctrl+C) does not exit the program like it does with SSH. Example: d@-laptop:~/Documents/$ sftp mydomains.com Connecting to mydomains.com... d@mydomains.com's password: ^CPermission denied, please try again. Can SFTP support ^C like SSH does please?
The reason this happens is this piece of code from sftp.c: /* * The underlying ssh is in the same process group, so we must * ignore SIGINT if we want to gracefully abort commands, * otherwise the signal will make it to the ssh process and * kill it too */ signal(SIGINT, SIG_IGN); execvp(path, args); so the signals are blocked before ssh(1) starts. If we remove that, ^C will kill the ssh any time someone tries to interrupt a command. The only thing I can think of is to tell ssh to allow interrupts until after authentication and then ignore them, which would require another flag or option.
Actually, that's not the reason. The real reason is a bug in readpassphrase, which is imported from OpenBSD. getpassphrase saves the current signal handlers and sets up its own. (It does this so that it can, eg, restore the terminal modes if it's interrupted while in raw mode). In order to get the same behaviour from the application that you would normally get from the signal, readpassphrase stores the signal and when it restores the handlers, it resends the signal to itself. The catch is the storage is only a single variable, which means that only the most recent signal is replayed. When you observed the problem, the most recent signal was the SIGINT which, as described above, is dutifully ignored. sftp also sends a SIGTERM to ssh, however it was usually lost, and when that happened, ssh remained running while sftp was waiting for it to shut down. We've fixed OpenBSD and imported the fixes, so this should be fixed in the next release (5.4p1). Thanks for the report.
With the release of 5.4p1, this bug is now considered closed.