[Bug 2619] infinite loop, 100% cpu use in ssh if ^Z is pressed at password prompt
bugzilla-daemon at bugzilla.mindrot.org
bugzilla-daemon at bugzilla.mindrot.org
Tue Oct 18 05:13:01 AEDT 2016
https://bugzilla.mindrot.org/show_bug.cgi?id=2619
Darren Tucker <dtucker at zip.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #2879|0 |1
is obsolete| |
--- Comment #8 from Darren Tucker <dtucker at zip.com.au> ---
Created attachment 2881
--> https://bugzilla.mindrot.org/attachment.cgi?id=2881&action=edit
Do not attempt to re-send SIGTTOU if we got it while restoring terminal
modes.
Todd Miller of OpenBSD came up with the following analysis:
"""
It's not really useful to generate SIGTTOU when restoring terminal
the mode in readpassphrase(). If we get SIGTTOU it means the process
is not in the foreground process group which, in most cases, means
that the shell has taken possession of the tty.
Basically what happens is this:
1) sftp forks ssh
2) user suspends sftp (really ssh) at the password prompt
3) sftp receives SIGTSTP and suspends
4) shell takes the controlling terminal
5) ssh receives SIGTSTP, tries to restore terminal mode, receives
SIGTTOU
6) ssh sends itself SIGTSTP and suspends
7) user resumes sftp (and the ssh child)
8) ssh sends itself SIGTTOU and suspends
9) sftp appears to be hung (though you can bg and fg it to get back)
sftp should probably install signal handlers for SIGTSTP, SIGTTOU
and SIGTTIN and wait for its child to suspend like scp does but
I'll save that for another diff.
"""
and the attached patch, which also seems to work for me.
--
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
More information about the openssh-bugs
mailing list