PowerShell / PowerShell/Win32-OpenSSH
OpenSSH hangs open sent if using no tty (`-T` or with a command.)
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 8.3k
- Forks
- 819
- PR merge metrics
- No merged PRs in 30d
Description
"OpenSSH for Windows" version
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
Server Operating System
Raspbian GNU/Linux 10 (buster) armv7l
Server SSHD: OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1, OpenSSL 1.1.1d 10 Sep 2019
Client Operating System
Windows 10 Pro Build 21354_co_release.210402-1630
What is failing
When attempting to issue a command or otherwise connect to my server (7.9p1), my session hangs open when it should have disconnected and finished, not providing any output it should have. This behavior does not occur on my other client machine (Windows 10 Pro for Workstations 20H2 Build 19042.870, OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5)
Example commands:
ssh -T user@server "echo test"
ssh -T user@server true
ssh -T user@server "bash -i --noprofile --norc"
Expected output
test, returning to local prompt, and an "invisible" bash prompt in the case of the third command.
Actual output
``
Additional information
Monitoring processes on the server, I can see that if the command given should have done something and exited (like true or echo test in my examples,) then they have exited on the server. Their parent executable remains alive with no children until I manually end the connection on the client side. In the case of echo test no output, and the interactive bash, no input nor output occurs.
The problem occurs through PowerShell, Command Prompt, and the terminal emulator inside VS Code.
Verbose Log
Here is the tail (-vvvvv) of where the session hangs.
ssh -T -vvvv host-alias "echo test"
...
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.1.3 ([192.168.1.3]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 4
debug1: Remote: /home/cmd/.ssh/authorized_keys:2: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 4
debug1: Remote: /home/cmd/.ssh/authorized_keys:2: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug3: unable to connect to pipe \\\\.\\pipe\\openssh-ssh-agent, error: 2
debug1: ssh_get_authentication_socket: No such file or directory
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug1: Sending command: echo test
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
My ~\.ssh\config looks like this, and I'm using PK auth.
Host host-alias
HostName 192.168.1.3
User cmd
ForwardAgent yes
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the hang on Windows 10 with OpenSSH_for_Windows_8.1p1 using the shown host-alias configuration, ForwardAgent setting, and commands such as ssh -T user@server "echo test" and ssh -T user@server true. Start with the provided -vvvvv session log and compare behavior with the reported 7.7p1 client. Done means command output appears and the client returns to the local prompt without manual disconnection.
Written by the indexing model from the issue text.
Assessment
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100