Windows 7 x64 - sshd Unknown Error #414
Comments
|
As per https://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx, this should be Can you attach DEBUG3 logs from sshd? See https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting%20Steps |
|
workaround: change the sshd windows login user to local user may fix this. |
|
Getting this same error on Windows 10 Enterprise x64 with OpenSSH-Win64 DEBUG3 output: Before starting the service I emptied the log, this is from the start to the first repetitive |
|
Can you dump output of ipconfig /all ? |
|
I had the same issue with v 0.0.7.0, and this workaround: #244 (comment) works for me. |
|
dup #606 |
itnic
added a commit
to itnic/Win32-OpenSSH
that referenced
this issue
Dec 2, 2017
Issue 787 There is a bug in the Microsoft POSIX compatibility layer used to translate POSIX socket API to Windows socket API. The bug concerns the emulated function accept() (socketio_accept() in the file socketio.c), which may return an invalid socket and may lock the program in an infinite loop. A race is happening between the Windows kernel signaling a socket issue to the POSIX compatibility layer. If a connection to the ssh service is dropped before being fully handled by the POSIX compatibility layer, that layer may reach a state where the Windows kernel is aware of the dropped connection and update all the socket states of the Windows socket API. However, the POSIX compatibility layer is in the middle of the accept() function task and fails without updating the local state of the emulated POSIX socket. When the emulated accept() exits, the current socket state is not updated and the emulated select() call would carry on detecting activity (previously already detected) on the socket, triggering the same exact error in the accept() call, running then in an infinite loop. This may not happen all the time: if the Windows kernel signals the error before the compatibility POSIX layer has setup its accept() state and returned successfully, other calls such as send() and recv() will update the state of the socket and will handle the issue. However, on a loaded machine where the synchronization between the Windows socket API and the compatibility POSIX layer may be slower, the emulated accept() call may finish before being notified by the Windows kernel of a client disconnection. This may be triggered with nmap, which makes two TCP connections in a row quickly: one to detect an opened port, and a second to retrieve the ssh banner. The fix proposed is to update the emulated accept() function to modify the internal state of the compatibility POSIX layer as a regular POSIX kernel would do. I personally had this issue and this patch fixed it. Please note that we have identified other situations where it could potentially happen (in particular the socketio_setsockopt() call). But we haven't investigated this issue more deeply. Other issues such as PowerShell#414 or PowerShell#606 may be related.
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I just tried to install version 0.0.3.0 on a Windows 7 x64 system, and when I start the sshd service I can't connect and the log simply fills with lines like the following (as in hundreds of thousands of them, very quickly):
If I stop the sshd service, and execute sshd.exe on the command line like
sshd.exe -dthen I get a repeated error in the Command Prompt that says the following:There is nothing else listening to this port, and I have tried adding
AddressFamily inetto sshd_config with no luck. There is no software firewall installed, security software is shut down while testing this, port 22 is forwarded in the router, and I'm at a loss for anything else I could try.The text was updated successfully, but these errors were encountered: