You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is nothing I hate more than doing a procedure without problems for years, then not doing that for a couple of weeks, and then when doing it "now", it fails. So, in this case, what I've been doing for years is:
on my desktop PC, open a MINGW64 terminal, and run sshd:
$(which sshd) -o LogLevel=DEBUG1 -De -p 222
open another MINGW64 terminal, and run the tunnel command:
and finally, on a remote computer, use ssh -p 2222 DESKTOPUSER@remoteserver.com to access desktop PC.
Well, this time, when I tried this, I got:
$ ssh -p 2222 DESKTOPUSER@remoteserver.com
DESKTOPUSER@remoteserver.com's password:
Connection to remoteserver.com closed by remote host.
Connection to remoteserver.com closed.
Great, just the best, when things shut down, and there is no error message. Well, the sshd then writes this in its log:
...
debug1: rekey in after 134217728 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user DESKTOPUSER service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: userauth-request for user DESKTOPUSER service ssh-connection method keyboard-interactive [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: keyboard-interactive devs [preauth]
debug1: auth2_challenge: user=DESKTOPUSER devs= [preauth]
debug1: kbdint_alloc: devices '' [preauth]
debug1: userauth-request for user DESKTOPUSER service ssh-connection method password [preauth]
debug1: attempt 2 failures 1 [preauth]
Accepted password for DESKTOPUSER from 127.0.0.1 port 48400 ssh2
debug1: monitor_child_preauth: user DESKTOPUSER authenticated by privileged process
debug1: monitor_read_log: child log fd closed
privsep_preauth: preauth child terminated by signal 11
debug1: do_cleanup
...
So, password got accepted, and then for apparently no reason at all, the "preauth child" got "terminated by signal 11". So something in there, a child process of sshd crashed with signal 11 - but what? gdb did not give me an answer (it did not even stop when this message is printed), but then I guessed, maybe this "child" is actually the shell we'd try to start upon successful auth, which in this case would be the MINGW64 bash, as I'm running the above in a MINGW64 terminal.
However, I had forgotten that openssh is actually a MSYS2 packaage:
So, I simply stopped the previous sshd server, and opened a MSYS2 terminal, and ran $(which sshd) -o LogLevel=DEBUG1 -De -p 222 there; and lo and behold - the ssh -p 2222 DESKTOPUSER@remoteserver.com on the remote computer now works!
Since I had previously used MSYS2 in a MINGW64 shell without problems, I'd say a regression happened somewhere, though not sure exactly where. Still, I'd like this functionality back, if possible ...
Expected behavior
Well, if I ran $(which sshd) -o LogLevel=DEBUG1 -De -p 222 in a MINGW64 terminal on desktop PC and tunnelled it, and then executed ssh -p 2222 DESKTOPUSER@remoteserver.com on a remote PC, I'd expect the ssh command on the remote server to succeed and a connection to be established, whereby sshd typically prints something like this:
...
debug1: userauth-request for user DESKTOPUSER service ssh-connection method password [preauth]
debug1: attempt 2 failures 1 [preauth]
Accepted password for DESKTOPUSER from 127.0.0.1 port 48305 ssh2
debug1: monitor_child_preauth: user DESKTOPUSER authenticated by privileged process
debug1: monitor_read_log: child log fd closed
debug1: rekey in after 134217728 blocks
debug1: rekey out after 134217728 blocks
debug1: ssh_packet_set_postauth: called
debug1: active: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384
debug1: input_session_request
debug1: channel 0: new session [server-session] (inactive timeout: 0)
debug1: session_new: session 0
...
Actual behavior
As described above, the ssh on remote PC fails, whereby sshd on local PC outputs privsep_preauth: preauth child terminated by signal 11
Description / Steps to reproduce the issue
There is nothing I hate more than doing a procedure without problems for years, then not doing that for a couple of weeks, and then when doing it "now", it fails. So, in this case, what I've been doing for years is:
on my desktop PC, open a MINGW64 terminal, and run
sshd
:open another MINGW64 terminal, and run the tunnel command:
and finally, on a remote computer, use
ssh -p 2222 DESKTOPUSER@remoteserver.com
to access desktop PC.Well, this time, when I tried this, I got:
Great, just the best, when things shut down, and there is no error message. Well, the
sshd
then writes this in its log:So, password got accepted, and then for apparently no reason at all, the "preauth child" got "terminated by signal 11". So something in there, a child process of
sshd
crashed withsignal 11
- but what?gdb
did not give me an answer (it did not even stop when this message is printed), but then I guessed, maybe this "child" is actually the shell we'd try to start upon successful auth, which in this case would be the MINGW64 bash, as I'm running the above in a MINGW64 terminal.However, I had forgotten that
openssh
is actually a MSYS2 packaage:So, I simply stopped the previous
sshd
server, and opened a MSYS2 terminal, and ran$(which sshd) -o LogLevel=DEBUG1 -De -p 222
there; and lo and behold - thessh -p 2222 DESKTOPUSER@remoteserver.com
on the remote computer now works!Since I had previously used MSYS2 in a MINGW64 shell without problems, I'd say a regression happened somewhere, though not sure exactly where. Still, I'd like this functionality back, if possible ...
Expected behavior
Well, if I ran
$(which sshd) -o LogLevel=DEBUG1 -De -p 222
in a MINGW64 terminal on desktop PC and tunnelled it, and then executedssh -p 2222 DESKTOPUSER@remoteserver.com
on a remote PC, I'd expect thessh
command on the remote server to succeed and a connection to be established, whereby sshd typically prints something like this:Actual behavior
As described above, the
ssh
on remote PC fails, wherebysshd
on local PC outputsprivsep_preauth: preauth child terminated by signal 11
Verification
Windows Version
MINGW64_NT-10.0-19045
Are you willing to submit a PR?
No response
The text was updated successfully, but these errors were encountered: