openssh bugs - Apr 2009 - [Bug 1590] New: ^C is not supported in sftp

https://bugzilla.mindrot.org/show_bug.cgi?id=1590

           Summary: ^C is not supported in sftp
           Product: Portable OpenSSH
           Version: 5.2p1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: sftp
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: jg at jguk.org


I sftp'd into the wrong machine, and noticed ^C (Ctrl+C) does not exit
the program like it does with SSH.


Example:

d at -laptop:~/Documents/$ sftp mydomains.com
Connecting to mydomains.com...
d at mydomains.com's password:
^CPermission denied, please try again.


Can SFTP support ^C like SSH does please?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1590


Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
             Blocks|                            |1626




-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1590

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> 2010-01-13
14:20:34 EST ---
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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1590

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Darren Tucker <dtucker at zip.com.au> 2010-01-13
21:37:44 EST ---
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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1590

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> 2010-03-26
10:52:02 EST ---
With the release of 5.4p1, this bug is now considered closed.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.