Ctrl-C no longer works to break out of ping -t after pressing Ctrl-C in an ssh password prompt

[zaaj]

Troubleshooting steps https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps

Those troubleshooting steps don't seem to be too relevant - it's not the ssh session itself, but the PowerShell window used to launch an SSH session that exhibits the problem. Found a github issue for Windows Terminal for this problem - that one suggested opening an issue with OpenSSH, so here we are.

Terminal issue? please go through wiki https://github.com/PowerShell/Win32-OpenSSH/wiki/TTY-PTY-support-in-Windows-OpenSSH

Not really this type of terminal problem either - it's after the ssh session ends that the problem shows up.

Please answer the following

"OpenSSH for Windows" version ((Get-Item (Get-Command ssh).Source).VersionInfo.FileVersion) 7.7.2.1 (client, didn't install sshd on windows 10)

Server OperatingSystem ((Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows nt\CurrentVersion\" -Name ProductName).ProductName) various, it's not while connected to the ssh server that the problem occurrs.

Client OperatingSystem Microsoft Windows [Version 10.0.18363.1139] Powershell version found with get-host | select Version: 5.1.18362.1110

What is failing From a Powershell window, if I SSH and happen to press Ctrl-C during the password prompt, Ctrl-C no longer works to break out of some programs, such as PING -T I can use a separate powershell window and type "get-process ping | kill" to stop the process, after which all the Ctrl-C (red ^C's) I pressed show up on the screen. Running this from CMD.exe does NOT show the same problem

Expected output I expect Ctrl-C to interrupt the running PING command

Actual output PING continues to run.

[eraustud]

Confirmed this problem on Windows 10 Pro [Version 10.0.19041] [PSVersion 5.1.19041.546] [SSH version 7.7.2.1]

Steps taken to reproduce Attempt to connect to an ssh session with a failure. e.g., enter incorrect credentials or have a connection refused.

Current workaround After ssh exits, enter the command [Console]::TreatControlCAsInput = $False

Potential Solution Have ssh return Ctrl-C functionality to default on exit, even if ssh exits on an error.

[jeffrey-irwin]

+1 - I ran into this issue as well. Confirmed the above workaround from eraustud is working but you have to remember to run it after each SSH failure as once you start something like ping -t it is too late and you must kill the process manually or start new shell session. I also confirmed this occurs in PS7 as well as PS5.1 so not PS specific.

[Zerowalker]

I run into this all the time, is there some fix that doesn't require you to manually type that? Can't believe ppl aren't complaining more on this, i basically just close the window and open a new cause it takes so long and i realize it when it's too late xd.

[gurnec]

You can paste this into your profile (run notepad $PROFILE.CurrentUserAllHosts), and then restart PowerShell (or run . $PROFILE.CurrentUserAllHosts).

$SSHBinary = (Get-Command ssh.exe).Path
function ssh() {
    if ($args_str = $args.ForEach({ '"' + ($_ -replace '(\\*)"','$1$1\"' -replace '(\\+)$','$1$1') + '"' }) -join ' ') {
        $env:commandlineargumentstring = $args_str
        & $SSHBinary --% %commandlineargumentstring%
        $env:commandlineargumentstring = $null
        [Console]::TreatControlCAsInput = $False
    } else {
        & $SSHBinary
    }
}

[Zerowalker]

I try to wrap my head around this but i can't make it out. But it seems to work O.o. If possible please explain it a bit, and also Thanks!

Aside from working around the issue, what's actually causing it though? Think i read that OpenSSH actually does what it's supposed to, it's just that powershell isn't honoring the requests being made? If so why is that, like what does the application/powershell do in this case that's different from all other cases?

Feels so weird as powershell is the main terminal being pushed for in windows basically, and ssh is well, huge. So having such a common (yet for some reason not many seems to be disturbed by it?) issue seems odd. But i might just be missing something obvious here.

[AkikoOrenji]

I've also noticed this issue when using the built in SSH client in windows 10 with powershell and Windows Terminal. Its a bit of a pain. Is there going to be a fix ?

[yehorb]

I somehow experience a more extreme version of the issue. When the ssh.exe process terminates with an error, my keycodes become mangled. enter does not work, pressing enter produces m in the terminal. ctrl-enter produces j. F1-F12 keys that usually do nothing produce seemingly unrelated symbols (F1 produces Q) with line breaks. The only way to resolve the issue is to close the tab. I use the PSReadline, and it used to have a keycode mangling issue when using cyrillic keyboard layout enabled (e.g. ctrl-c produced cyrillic с in some circumstances). Maybe it is related somehow.

[alyandon]

@yehorb Mangling input (vs resetting the windows terminal ctrl-c handling mode) sounds like a different issue to be honest. You may want to file a separate issue.

[jacobrastad]

I can confirm this issue also occurs when running PowerShell on Windows 11 and Windows Terminal. See full thread here https://github.com/microsoft/terminal/issues/13503

[AkikoOrenji]

just noticed that this also seems to happen without the SSH usage. I'm noticing it with Powershell that CTRL-C wont kill a long running powershell select-string. I suspect there is more to this problem.

[zaaj]

AkikoOrenji,

I've noticed there are several commands that won't seem to respond to a Ctrl-C interrupt request, but I don't think that's the same type of problem as with the ssh client. In the ssh client situation, the Powershell console application is explicitly ignoring Ctrl-C keyboard input so that it can send the Ctrl-C character over the SSH connection to the remote computer (where it will likely interrupt a process running on that remote computer). The problem reported in this bug report is that interrupting the login process terminates the ssh client in a way that does not restore local interpretation of Ctrl-C as an interrupt request at all.

Processes ignoring an interrupt request (vs. failing to interpret a particular keyboard input of Ctrl-C as an interrupt request) is a different type of problem.

On Tue, Sep 13, 2022 at 7:08 AM AkikoOrenji @.***> wrote:

just noticed that this also seems to happen without the SSH usage. I'm noticing it with Powershell that CTRL-C wont kill a long running powershell select-string. I suspect there is more to this problem.

— Reply to this email directly, view it on GitHub https://github.com/PowerShell/Win32-OpenSSH/issues/1699#issuecomment-1245255094, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANIQO5KRM4AISADH2GZR6ALV6BODZANCNFSM4TIAWPEQ . You are receiving this because you authored the thread.Message ID: @.***>

[alyandon]

Upgrading to PowerShell 7.3.0 seems to have broken the work-around PowerShell profile script that was posted above by @gurnec.

I replaced: & $SSHBinary --% %commandlineargumentstring%

With: & $SSHBinary @args

Tested with various incarnations of command line parameters and it seems to work fine. However, I am not a PowerShell expert in this or any other theoretical universe so use at your own risk.

[cyungmann]

Additionally, when I run git add -i or git add -p after one of the repro steps (e.g. pressing Ctrl+C at an SSH password prompt or entering an invalid password or having connection refused), I am unable to enter any of the TUI commands and unable to Ctrl+C to break out. Running [Console]::TreatControlCAsInput = $False before running the Git commands does not really fix the issue, but does make it so that entering Ctrl+C and then some other keys in the Git TUI breaks out of it.

git --version outputs git version 2.39.1.windows.1

Also, I am using PSReadLine 2.2.6 and oh-my-posh 6.43.0 in case that makes any difference.

[alyandon]

@cyungmann Do you still see the issue with a profile that doesn't have PSReadLine loaded?

[cyungmann]

@alyandon without PSReadLine loaded I do not see any of the problems mentioned in this thread.

[alyandon]

Yeah, as much as I miss the readline experience - I had to give up on running PSReadLine because of weird things like what you describe happening. I don't know that it is actually related to the TreatControlCAsInput not getting reset to an appropriate value problem though.

[zaaj]

Since it's been almost 3 years with no developer activity, I've just taken to using Win+R and runnning SSH in it's own window each time. I only revert to running SSH in Powershell when I need to see ssh's output about why I couldn't connect

[alyandon]

Yeah, seems like they need to catch all exit paths in the openssh client and guarantee they reset ctrl-c handling mode on the terminal or create a first class wrapper script like the one above that does it.