New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sshd crashes when accessing forwarded ports #288

Closed
adverst opened this Issue Aug 9, 2016 · 15 comments

Comments

Projects
None yet
7 participants
@adverst

adverst commented Aug 9, 2016

I'm attempting to run openssh in a windows 10 machine. I think everything is set up correctly, I'm able to connect fine with passwords/keys etc.

I'm attempting to forward a port over the connection (via putty), as soon as something at the client end attempts to access the forwarded port the connection is aborted. If I run with sshd.exe -d, then launch something accessing the remote port, the windows crash dialog displays with "sshd.exe has stopped working" and the following output displayed:

debug1: server_input_channel_open: ctype direct-tcpip rchan 257 win 16384 max 16384
debug1: server_request_direct_tcpip: originator 0.0.0.0 port 0, target localhost port 65
debug1: socket:464, io:000002333D0DDFA0, fd:7
debug1: socketio_getsockopt - ERROR:22
debug1: getsockopt TCP_NODELAY: Invalid argument
debug1: connect_next: host localhost ([::1]:65) in progress, fd=7
debug1: channel 1: new [direct-tcpip]
debug1: server_input_channel_open: confirm direct-tcpip
debug1: finish_connect - ERROR: async io completed with error: 107, io:000002333D0DDFA0
debug1: channel 1: connected to localhost port 65
debug1: recv - from CB ERROR:107, io:000002333D0DDFA0
debug1: socketio_shutdown - ERROR:126
debug1: socketio_shutdown - ERROR:126
debug1: channel 1: free: direct-tcpip, nchannels 2
debug1: socketio_shutdown - ERROR:126
debug1: close - io:000002333D0DDFA0, type:1, fd:7, table_index:7

Not really sure what I'm doing here, if there is additional info I can supply to help identify the problem please let me know.

@manojampalam

This comment has been minimized.

Show comment
Hide comment
@manojampalam

manojampalam Sep 12, 2016

Collaborator

I've validated both local and remote forwarding before the release. Can you confirm if you see this problem with ssh.exe too ?

Collaborator

manojampalam commented Sep 12, 2016

I've validated both local and remote forwarding before the release. Can you confirm if you see this problem with ssh.exe too ?

@bdr2

This comment has been minimized.

Show comment
Hide comment
@bdr2

bdr2 Dec 30, 2016

I am also experiencing this same problem, although I don't believe sshd is actually crashing (as in the bug title)... just that the client is abruptly disconnected.

I am attempting to connect to a VNC server over an SSH tunnel. Standard procedure is to establish SSH client connection to server with port forwarding, then connect VNC client to localhost:port. Just as adverst noted above, SSH connects fine and shell commands work as expected. As soon as I attempt to connect VNC, the SSH connection is disconnected.

Running Win32-OpenSSH v0.0.5.0 on Windows 10 Pro with TightVNC Server v.2.8.5. (FYI: IPv6 is disabled.)

I have reproduced this on Ubuntu 16.04.1 LTS with OpenSSH_7.2p2 client and Remmina v1.1.2 (VNC client), and also on Android 7.1.1 (Nexus 6P phone) with ConnectBot v1.8.6 and Real VNC Viewer v3.0.0.024226.

From Android:
debug1: server_input_channel_open: ctype direct-tcpip rchan 101 win 30000 max 33976
debug1: server_request_direct_tcpip: originator 127.0.0.1 port 47483, target localhost port 5900
debug1: socket:640, io:0095C228, fd:7
debug1: socketio_getsockopt - ERROR:22
debug1: getsockopt TCP_NODELAY: Invalid argument
debug1: connect_next: host localhost ([::1]:5900) in progress, fd=7
debug1: channel 1: new [direct-tcpip]
debug1: server_input_channel_open: confirm direct-tcpip
debug1: finish_connect - ERROR: async io completed with error: 107, io:0095C228
debug1: channel 1: connected to localhost port 5900
debug1: recv - from CB ERROR:107, io:0095C228
debug1: socketio_shutdown - ERROR:126
debug1: socketio_shutdown - ERROR:126
debug1: channel 1: free: direct-tcpip, nchannels 2
debug1: socketio_shutdown - ERROR:126
debug1: close - io:0095C228, type:1, fd:7, table_index:7
debug1: zombie'ing child at index 0, 0 zombies of 1
debug1: raise sig:3
debug1: Unregister child at index 0, 1 zombies of 1
debug1: process_queued_signals: WARNING - A signal has interrupted and was processed

From Ubuntu (same error):
debug1: server_input_channel_open: ctype direct-tcpip rchan 3 win 2097152 max 32768
debug1: server_request_direct_tcpip: originator 127.0.0.1 port 34904, target localhost port 5900
debug1: socket:708, io:0090CCF0, fd:7
debug1: socketio_getsockopt - ERROR:22
debug1: getsockopt TCP_NODELAY: Invalid argument
debug1: connect_next: host localhost ([::1]:5900) in progress, fd=7
debug1: channel 1: new [direct-tcpip]
debug1: server_input_channel_open: confirm direct-tcpip
debug1: finish_connect - ERROR: async io completed with error: 107, io:0090CCF0
debug1: channel 1: connected to localhost port 5900
debug1: recv - from CB ERROR:107, io:0090CCF0
debug1: socketio_shutdown - ERROR:126
debug1: socketio_shutdown - ERROR:126
debug1: channel 1: free: direct-tcpip, nchannels 2
debug1: socketio_shutdown - ERROR:126
debug1: close - io:0090CCF0, type:1, fd:7, table_index:7
debug1: zombie'ing child at index 0, 0 zombies of 1
debug1: raise sig:3
debug1: Unregister child at index 0, 1 zombies of 1
debug1: process_queued_signals: WARNING - A signal has interrupted and was processed

bdr2 commented Dec 30, 2016

I am also experiencing this same problem, although I don't believe sshd is actually crashing (as in the bug title)... just that the client is abruptly disconnected.

I am attempting to connect to a VNC server over an SSH tunnel. Standard procedure is to establish SSH client connection to server with port forwarding, then connect VNC client to localhost:port. Just as adverst noted above, SSH connects fine and shell commands work as expected. As soon as I attempt to connect VNC, the SSH connection is disconnected.

Running Win32-OpenSSH v0.0.5.0 on Windows 10 Pro with TightVNC Server v.2.8.5. (FYI: IPv6 is disabled.)

I have reproduced this on Ubuntu 16.04.1 LTS with OpenSSH_7.2p2 client and Remmina v1.1.2 (VNC client), and also on Android 7.1.1 (Nexus 6P phone) with ConnectBot v1.8.6 and Real VNC Viewer v3.0.0.024226.

From Android:
debug1: server_input_channel_open: ctype direct-tcpip rchan 101 win 30000 max 33976
debug1: server_request_direct_tcpip: originator 127.0.0.1 port 47483, target localhost port 5900
debug1: socket:640, io:0095C228, fd:7
debug1: socketio_getsockopt - ERROR:22
debug1: getsockopt TCP_NODELAY: Invalid argument
debug1: connect_next: host localhost ([::1]:5900) in progress, fd=7
debug1: channel 1: new [direct-tcpip]
debug1: server_input_channel_open: confirm direct-tcpip
debug1: finish_connect - ERROR: async io completed with error: 107, io:0095C228
debug1: channel 1: connected to localhost port 5900
debug1: recv - from CB ERROR:107, io:0095C228
debug1: socketio_shutdown - ERROR:126
debug1: socketio_shutdown - ERROR:126
debug1: channel 1: free: direct-tcpip, nchannels 2
debug1: socketio_shutdown - ERROR:126
debug1: close - io:0095C228, type:1, fd:7, table_index:7
debug1: zombie'ing child at index 0, 0 zombies of 1
debug1: raise sig:3
debug1: Unregister child at index 0, 1 zombies of 1
debug1: process_queued_signals: WARNING - A signal has interrupted and was processed

From Ubuntu (same error):
debug1: server_input_channel_open: ctype direct-tcpip rchan 3 win 2097152 max 32768
debug1: server_request_direct_tcpip: originator 127.0.0.1 port 34904, target localhost port 5900
debug1: socket:708, io:0090CCF0, fd:7
debug1: socketio_getsockopt - ERROR:22
debug1: getsockopt TCP_NODELAY: Invalid argument
debug1: connect_next: host localhost ([::1]:5900) in progress, fd=7
debug1: channel 1: new [direct-tcpip]
debug1: server_input_channel_open: confirm direct-tcpip
debug1: finish_connect - ERROR: async io completed with error: 107, io:0090CCF0
debug1: channel 1: connected to localhost port 5900
debug1: recv - from CB ERROR:107, io:0090CCF0
debug1: socketio_shutdown - ERROR:126
debug1: socketio_shutdown - ERROR:126
debug1: channel 1: free: direct-tcpip, nchannels 2
debug1: socketio_shutdown - ERROR:126
debug1: close - io:0090CCF0, type:1, fd:7, table_index:7
debug1: zombie'ing child at index 0, 0 zombies of 1
debug1: raise sig:3
debug1: Unregister child at index 0, 1 zombies of 1
debug1: process_queued_signals: WARNING - A signal has interrupted and was processed

@bingbing8

This comment has been minimized.

Show comment
Hide comment
@bingbing8

bingbing8 Jan 19, 2017

Collaborator

Try with the latest build (0.0.7.0). Reopen if needed.

Collaborator

bingbing8 commented Jan 19, 2017

Try with the latest build (0.0.7.0). Reopen if needed.

@bingbing8 bingbing8 closed this Jan 19, 2017

@bdr2

This comment has been minimized.

Show comment
Hide comment
@bdr2

bdr2 Jan 21, 2017

I'm not the original submitter, so I can't re-open..... but I've duplicated this issue on a clean install of 0.0.7.0. Log shows exactly the same as my post above.

Additionally, since I didn't put this in my previous post, here is the output to ssh-agent.log:

6780 00:04:31 671 client pid 10236 connected
6780 00:04:31 687 debug1: spawned worker 7136 for agent client pid 10236
7136 00:04:31 687 agent_start pid:7136, dbg:0, child:1, pipe:556
7136 00:04:34 196 debug1: process agent request type 100
7136 00:05:13 458 debug1: iocp error: 109 on 013E4FF0 \n
7136 00:05:13 458 debug1: connection 013E4FF0 clean up
7136 00:05:13 458 debug1: iocp error: 6 on 00000000 \n

bdr2 commented Jan 21, 2017

I'm not the original submitter, so I can't re-open..... but I've duplicated this issue on a clean install of 0.0.7.0. Log shows exactly the same as my post above.

Additionally, since I didn't put this in my previous post, here is the output to ssh-agent.log:

6780 00:04:31 671 client pid 10236 connected
6780 00:04:31 687 debug1: spawned worker 7136 for agent client pid 10236
7136 00:04:31 687 agent_start pid:7136, dbg:0, child:1, pipe:556
7136 00:04:34 196 debug1: process agent request type 100
7136 00:05:13 458 debug1: iocp error: 109 on 013E4FF0 \n
7136 00:05:13 458 debug1: connection 013E4FF0 clean up
7136 00:05:13 458 debug1: iocp error: 6 on 00000000 \n

@bdr2

This comment has been minimized.

Show comment
Hide comment
@bdr2

bdr2 Jan 24, 2017

After some more testing, it appears the issue may be related to ipv6.

As I noted in my post from December 30, 2016, ipv6 is disabled on all interfaces on all systems and devices in my environment.

Looking at the SSHD logs, I noticed problems arise as soon as local port forwarding is initiated for the ipv6 localhost ("[::1]:5900") with getsockopt errors. In sshd_config, the default argument for keyword AddressFamily is any (use both ipv4 and ipv6). If I edit sshd_config and add AddressFamily inet to explicitly force only ipv4 (and then restart sshd), local port forwarding works perfectly, as sshd forces the ipv4 localhost ("[127.0.0.1]:5900").

What I don't know, however, is if sshd is exhibiting this problem on interfaces and/or environments with active ipv6 configurations (or, at the very least, not completely disabled ipv6). Unfortunately I am not able to personally test that setup, so perhaps someone else can create and test that environment.

Here are the pertinent parts of the logs to compare:

.

  • Using default (AddressFamily any -- both ipv4 and ipv6):

560 18:07:06 206 Starting session: shell on console for bdr2 from 192.168.1.10 port 43562 id 0
560 18:07:06 206 debug1: pipe - r-h:604,io:00FEA5F0,fd:7 w-h:608,io:00FE97F0,fd:8
560 18:07:06 206 debug1: pipe - r-h:620,io:00FE9BF0,fd:9 w-h:628,io:00FEA4F0,fd:10
560 18:07:06 206 debug1: pipe - r-h:632,io:00FEA170,fd:11 w-h:636,io:00FE9C70,fd:12
560 18:07:06 206 debug1: Executing command: C:\OpenSSH\ssh-shellhost.exe
560 18:07:06 368 debug1: Register child 00000294 pid 1132, 0 zombies of 0
560 18:07:06 368 debug1: close - io:00FEA5F0, type:2, fd:7, table_index:7
560 18:07:06 368 debug1: close - io:00FEA4F0, type:2, fd:10, table_index:10
560 18:07:06 368 debug1: close - io:00FE9C70, type:2, fd:12, table_index:12
560 18:07:11 620 debug1: server_input_channel_open: ctype direct-tcpip rchan 3 win 2097152 max 32768
560 18:07:11 620 debug1: server_request_direct_tcpip: originator 127.0.0.1 port 43064, target localhost port 5900
560 18:07:11 620 debug1: socket:700, io:00FE98F0, fd:7
560 18:07:11 620 debug1: socketio_getsockopt - ERROR:22
560 18:07:11 620 debug1: getsockopt TCP_NODELAY: Invalid argument
560 18:07:11 620 debug1: connect_next: host localhost ([::1]:5900) in progress, fd=7
560 18:07:11 620 debug1: channel 1: new [direct-tcpip]
560 18:07:11 620 debug1: server_input_channel_open: confirm direct-tcpip
560 18:07:12 651 debug1: finish_connect - ERROR: async io completed with error: 107, io:00FE98F0
560 18:07:12 651 debug1: channel 1: connected to localhost port 5900
560 18:07:12 651 debug1: recv - from CB ERROR:107, io:00FE98F0
560 18:07:12 651 debug1: socketio_shutdown - ERROR:126
560 18:07:12 651 debug1: socketio_shutdown - ERROR:126
560 18:07:12 651 debug1: channel 1: free: direct-tcpip, nchannels 2
560 18:07:12 651 debug1: socketio_shutdown - ERROR:126
560 18:07:12 651 debug1: close - io:00FE98F0, type:1, fd:7, table_index:7
6392 18:07:12 820 debug1: zombie'ing child at index 0, 0 zombies of 1
6392 18:07:12 820 debug1: raise sig:3
6392 18:07:12 820 debug1: Unregister child at index 0, 1 zombies of 1
6392 18:07:12 820 debug1: process_queued_signals: WARNING - A signal has interrupted and was processed

.

  • Edit sshd_config (AddressFamily inet -- explicitly use only ipv4):

7208 21:06:18 366 Starting session: shell on console for bdr2 from 192.168.1.10 port 43976 id 0
7208 21:06:18 366 debug1: pipe - r-h:604,io:00C4E110,fd:7 w-h:608,io:00C4E310,fd:8
7208 21:06:18 366 debug1: pipe - r-h:616,io:00C4E610,fd:9 w-h:624,io:00C4E190,fd:10
7208 21:06:18 366 debug1: pipe - r-h:628,io:00C4E490,fd:11 w-h:632,io:00C4E390,fd:12
7208 21:06:18 366 debug1: Executing command: C:\OpenSSH\ssh-shellhost.exe
7208 21:06:18 519 debug1: Register child 00000290 pid 8468, 0 zombies of 0
7208 21:06:18 519 debug1: close - io:00C4E110, type:2, fd:7, table_index:7
7208 21:06:18 519 debug1: close - io:00C4E190, type:2, fd:10, table_index:10
7208 21:06:18 519 debug1: close - io:00C4E390, type:2, fd:12, table_index:12
7208 21:06:23 087 debug1: server_input_channel_open: ctype direct-tcpip rchan 3 win 2097152 max 32768
7208 21:06:23 087 debug1: server_request_direct_tcpip: originator 127.0.0.1 port 43478, target localhost port 5900
7208 21:06:23 103 debug1: socket:696, io:00C4DF90, fd:7
7208 21:06:23 103 debug1: connect_next: host localhost ([127.0.0.1]:5900) in progress, fd=7
7208 21:06:23 103 debug1: channel 1: new [direct-tcpip]
7208 21:06:23 103 debug1: server_input_channel_open: confirm direct-tcpip
7208 21:06:23 103 debug1: channel 1: connected to localhost port 5900
7208 21:06:32 065 debug1: channel 1: free: direct-tcpip, nchannels 2
7208 21:06:32 065 debug1: close - io:00C4DF90, type:1, fd:7, table_index:7
7208 21:06:47 447 debug1: close - io:00C4E610, type:2, fd:9, table_index:9
7208 21:06:47 447 debug1: close - io:00C4E490, type:2, fd:11, table_index:11
7208 21:06:47 447 debug1: zombie'ing child at index 0, 0 zombies of 1
7208 21:06:47 447 debug1: raise sig:3
7208 21:06:47 447 debug1: process_queued_signals: WARNING - A signal has interrupted and was processed
7208 21:06:47 447 debug1: Received SIGCHLD.
7208 21:06:47 447 debug1: Unregister child at index 0, 1 zombies of 1
7208 21:06:47 447 debug1: session_by_pid: pid 8468
7208 21:06:47 447 debug1: session_exit_message: session 0 channel 0 pid 8468
7208 21:06:47 447 debug1: session_exit_message: release channel 0
7208 21:06:47 447 debug1: close - io:00C4E310, type:2, fd:8, table_index:8
7208 21:06:47 447 debug1: session_pty_cleanup: session 0 release console
7208 21:06:47 462 debug1: session_by_channel: session 0 channel 0
7208 21:06:47 462 debug1: session_close_by_channel: channel 0 child 0
7208 21:06:47 462 Close session: user bdr2 from 192.168.1.10 port 43976 id 0
7208 21:06:47 462 debug1: channel 0: free: server-session, nchannels 1
7208 21:06:47 462 Received disconnect from 192.168.1.10 port 43976:11: disconnected by user
7208 21:06:47 462 Disconnected from 192.168.1.10 port 43976
7208 21:06:47 462 debug1: do_cleanup
4232 21:06:47 462 debug1: zombie'ing child at index 0, 0 zombies of 1
4232 21:06:47 462 debug1: raise sig:3
4232 21:06:47 462 debug1: Unregister child at index 0, 1 zombies of 1
4232 21:06:47 462 debug1: process_queued_signals: WARNING - A signal has interrupted and was processed

.
(When explicitly specifying ipv4, note the nice, clean close when I manually end the session, as opposed to the abrupt and dirty disconnection with the default ipv4+ipv6.)

.
Tagging @adverst here, hoping they see this bug's update and perhaps re-test and re-open the bug.

bdr2 commented Jan 24, 2017

After some more testing, it appears the issue may be related to ipv6.

As I noted in my post from December 30, 2016, ipv6 is disabled on all interfaces on all systems and devices in my environment.

Looking at the SSHD logs, I noticed problems arise as soon as local port forwarding is initiated for the ipv6 localhost ("[::1]:5900") with getsockopt errors. In sshd_config, the default argument for keyword AddressFamily is any (use both ipv4 and ipv6). If I edit sshd_config and add AddressFamily inet to explicitly force only ipv4 (and then restart sshd), local port forwarding works perfectly, as sshd forces the ipv4 localhost ("[127.0.0.1]:5900").

What I don't know, however, is if sshd is exhibiting this problem on interfaces and/or environments with active ipv6 configurations (or, at the very least, not completely disabled ipv6). Unfortunately I am not able to personally test that setup, so perhaps someone else can create and test that environment.

Here are the pertinent parts of the logs to compare:

.

  • Using default (AddressFamily any -- both ipv4 and ipv6):

560 18:07:06 206 Starting session: shell on console for bdr2 from 192.168.1.10 port 43562 id 0
560 18:07:06 206 debug1: pipe - r-h:604,io:00FEA5F0,fd:7 w-h:608,io:00FE97F0,fd:8
560 18:07:06 206 debug1: pipe - r-h:620,io:00FE9BF0,fd:9 w-h:628,io:00FEA4F0,fd:10
560 18:07:06 206 debug1: pipe - r-h:632,io:00FEA170,fd:11 w-h:636,io:00FE9C70,fd:12
560 18:07:06 206 debug1: Executing command: C:\OpenSSH\ssh-shellhost.exe
560 18:07:06 368 debug1: Register child 00000294 pid 1132, 0 zombies of 0
560 18:07:06 368 debug1: close - io:00FEA5F0, type:2, fd:7, table_index:7
560 18:07:06 368 debug1: close - io:00FEA4F0, type:2, fd:10, table_index:10
560 18:07:06 368 debug1: close - io:00FE9C70, type:2, fd:12, table_index:12
560 18:07:11 620 debug1: server_input_channel_open: ctype direct-tcpip rchan 3 win 2097152 max 32768
560 18:07:11 620 debug1: server_request_direct_tcpip: originator 127.0.0.1 port 43064, target localhost port 5900
560 18:07:11 620 debug1: socket:700, io:00FE98F0, fd:7
560 18:07:11 620 debug1: socketio_getsockopt - ERROR:22
560 18:07:11 620 debug1: getsockopt TCP_NODELAY: Invalid argument
560 18:07:11 620 debug1: connect_next: host localhost ([::1]:5900) in progress, fd=7
560 18:07:11 620 debug1: channel 1: new [direct-tcpip]
560 18:07:11 620 debug1: server_input_channel_open: confirm direct-tcpip
560 18:07:12 651 debug1: finish_connect - ERROR: async io completed with error: 107, io:00FE98F0
560 18:07:12 651 debug1: channel 1: connected to localhost port 5900
560 18:07:12 651 debug1: recv - from CB ERROR:107, io:00FE98F0
560 18:07:12 651 debug1: socketio_shutdown - ERROR:126
560 18:07:12 651 debug1: socketio_shutdown - ERROR:126
560 18:07:12 651 debug1: channel 1: free: direct-tcpip, nchannels 2
560 18:07:12 651 debug1: socketio_shutdown - ERROR:126
560 18:07:12 651 debug1: close - io:00FE98F0, type:1, fd:7, table_index:7
6392 18:07:12 820 debug1: zombie'ing child at index 0, 0 zombies of 1
6392 18:07:12 820 debug1: raise sig:3
6392 18:07:12 820 debug1: Unregister child at index 0, 1 zombies of 1
6392 18:07:12 820 debug1: process_queued_signals: WARNING - A signal has interrupted and was processed

.

  • Edit sshd_config (AddressFamily inet -- explicitly use only ipv4):

7208 21:06:18 366 Starting session: shell on console for bdr2 from 192.168.1.10 port 43976 id 0
7208 21:06:18 366 debug1: pipe - r-h:604,io:00C4E110,fd:7 w-h:608,io:00C4E310,fd:8
7208 21:06:18 366 debug1: pipe - r-h:616,io:00C4E610,fd:9 w-h:624,io:00C4E190,fd:10
7208 21:06:18 366 debug1: pipe - r-h:628,io:00C4E490,fd:11 w-h:632,io:00C4E390,fd:12
7208 21:06:18 366 debug1: Executing command: C:\OpenSSH\ssh-shellhost.exe
7208 21:06:18 519 debug1: Register child 00000290 pid 8468, 0 zombies of 0
7208 21:06:18 519 debug1: close - io:00C4E110, type:2, fd:7, table_index:7
7208 21:06:18 519 debug1: close - io:00C4E190, type:2, fd:10, table_index:10
7208 21:06:18 519 debug1: close - io:00C4E390, type:2, fd:12, table_index:12
7208 21:06:23 087 debug1: server_input_channel_open: ctype direct-tcpip rchan 3 win 2097152 max 32768
7208 21:06:23 087 debug1: server_request_direct_tcpip: originator 127.0.0.1 port 43478, target localhost port 5900
7208 21:06:23 103 debug1: socket:696, io:00C4DF90, fd:7
7208 21:06:23 103 debug1: connect_next: host localhost ([127.0.0.1]:5900) in progress, fd=7
7208 21:06:23 103 debug1: channel 1: new [direct-tcpip]
7208 21:06:23 103 debug1: server_input_channel_open: confirm direct-tcpip
7208 21:06:23 103 debug1: channel 1: connected to localhost port 5900
7208 21:06:32 065 debug1: channel 1: free: direct-tcpip, nchannels 2
7208 21:06:32 065 debug1: close - io:00C4DF90, type:1, fd:7, table_index:7
7208 21:06:47 447 debug1: close - io:00C4E610, type:2, fd:9, table_index:9
7208 21:06:47 447 debug1: close - io:00C4E490, type:2, fd:11, table_index:11
7208 21:06:47 447 debug1: zombie'ing child at index 0, 0 zombies of 1
7208 21:06:47 447 debug1: raise sig:3
7208 21:06:47 447 debug1: process_queued_signals: WARNING - A signal has interrupted and was processed
7208 21:06:47 447 debug1: Received SIGCHLD.
7208 21:06:47 447 debug1: Unregister child at index 0, 1 zombies of 1
7208 21:06:47 447 debug1: session_by_pid: pid 8468
7208 21:06:47 447 debug1: session_exit_message: session 0 channel 0 pid 8468
7208 21:06:47 447 debug1: session_exit_message: release channel 0
7208 21:06:47 447 debug1: close - io:00C4E310, type:2, fd:8, table_index:8
7208 21:06:47 447 debug1: session_pty_cleanup: session 0 release console
7208 21:06:47 462 debug1: session_by_channel: session 0 channel 0
7208 21:06:47 462 debug1: session_close_by_channel: channel 0 child 0
7208 21:06:47 462 Close session: user bdr2 from 192.168.1.10 port 43976 id 0
7208 21:06:47 462 debug1: channel 0: free: server-session, nchannels 1
7208 21:06:47 462 Received disconnect from 192.168.1.10 port 43976:11: disconnected by user
7208 21:06:47 462 Disconnected from 192.168.1.10 port 43976
7208 21:06:47 462 debug1: do_cleanup
4232 21:06:47 462 debug1: zombie'ing child at index 0, 0 zombies of 1
4232 21:06:47 462 debug1: raise sig:3
4232 21:06:47 462 debug1: Unregister child at index 0, 1 zombies of 1
4232 21:06:47 462 debug1: process_queued_signals: WARNING - A signal has interrupted and was processed

.
(When explicitly specifying ipv4, note the nice, clean close when I manually end the session, as opposed to the abrupt and dirty disconnection with the default ipv4+ipv6.)

.
Tagging @adverst here, hoping they see this bug's update and perhaps re-test and re-open the bug.

@bdr2

This comment has been minimized.

Show comment
Hide comment
@bdr2

bdr2 Jan 30, 2017

Confirmed the same issues above with a clean install of 0.0.8.0.

@bingbing8 - Since it appears the original submitter ( @adverst ) has not been active since submitting this bug almost 6 months ago, are you able to re-open this, or should I open a new bug and reference this one?

bdr2 commented Jan 30, 2017

Confirmed the same issues above with a clean install of 0.0.8.0.

@bingbing8 - Since it appears the original submitter ( @adverst ) has not been active since submitting this bug almost 6 months ago, are you able to re-open this, or should I open a new bug and reference this one?

@adverst

This comment has been minimized.

Show comment
Hide comment
@adverst

adverst Jan 30, 2017

Hi sorry - I no longer have the original setup to test this. Wasn't sure if protocol was for me to reopen but will do so now

adverst commented Jan 30, 2017

Hi sorry - I no longer have the original setup to test this. Wasn't sure if protocol was for me to reopen but will do so now

@adverst

This comment has been minimized.

Show comment
Hide comment
@adverst

adverst Jan 30, 2017

Actually - sorry, looks like I can't reopen as it was @bingbing8 that closed it

adverst commented Jan 30, 2017

Actually - sorry, looks like I can't reopen as it was @bingbing8 that closed it

@theJT

This comment has been minimized.

Show comment
Hide comment
@theJT

theJT May 30, 2017

I can confirm that this bug still exists as of version 0.0.14.0 - hoping that a new comment might cause this to be re-opened.

theJT commented May 30, 2017

I can confirm that this bug still exists as of version 0.0.14.0 - hoping that a new comment might cause this to be re-opened.

@bagajjal

This comment has been minimized.

Show comment
Hide comment
@bagajjal

bagajjal May 30, 2017

Collaborator

@theJT - @bdr2 is seeing this only with ipv6..
Is your setup using ipv6? Does it work fine with ipv4?

Collaborator

bagajjal commented May 30, 2017

@theJT - @bdr2 is seeing this only with ipv6..
Is your setup using ipv6? Does it work fine with ipv4?

@bagajjal bagajjal reopened this May 30, 2017

@bagajjal bagajjal self-assigned this May 30, 2017

@bdr2

This comment has been minimized.

Show comment
Hide comment
@bdr2

bdr2 May 30, 2017

@bagajjal -- Correction: It's not that I'm seeing this bug with ipv6... It's that I'm seeing this only when I don't explicitly enable ipv4-only in the sshd config (AddressFamily inet), even when only specifying ipv4 addresses.

bdr2 commented May 30, 2017

@bagajjal -- Correction: It's not that I'm seeing this bug with ipv6... It's that I'm seeing this only when I don't explicitly enable ipv4-only in the sshd config (AddressFamily inet), even when only specifying ipv4 addresses.

@theJT

This comment has been minimized.

Show comment
Hide comment
@theJT

theJT May 31, 2017

I'm sorry for the massive wall of text there, but I'm a bit out of my depth and have no idea what may or may not be relevant so I'm just attaching everything I can see.

I'm seeing this problem even with IPv4 set explicitly in the config file. IPv6 is explicitly disabled on the network adaptors of both the client and the server in this case - although the exact same thing happens if I re-enable it.

Here's the content of sshd_config

#    $OpenBSD: sshd_config,v 1.84 2011/05/23 03:30:07 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
AddressFamily inet
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_key
# If you use a relative path here it will read from c:\users\$env:UserName\
# which is proabably not what we want. Not least because we'd have to populat
# C:\users with all our home directories.
AuthorizedKeysFile      /mi/etc/sshd/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
# We should be using keyfiles only.
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
PidFile c:\mi\run\sshd.pid
#MaxStartups 10
PermitTunnel yes
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem       sftp    sftp-server.exe

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server
# PubkeyAcceptedKeyTypes ssh-ed25519*

If I start sshd -ddd for debugging and connect as normal, everything initially seems fine:
This from the client

tipler@MATHS@BARON-GREENBACK C:\Users\tipler>debug3: Register child 000000000000
027C pid 3156, 0 zombies of 0
debug2: fd 4 setting TCP_NODELAY
debug3: close - io:0000021D9C5EA5D0, type:2, fd:7, table_index:7
debug3: close - io:0000021D9C5EAD60, type:2, fd:10, table_index:10
debug3: close - io:0000021D9C5EA680, type:2, fd:12, table_index:12
debug2: channel 0: rfd 9 isatty
debug3: fd 9 is O_NONBLOCK
debug3: fd 8 is O_NONBLOCK
debug3: fd 11 is O_NONBLOCK
debug3: send packet: type 99

and this from the server:

debug2: load_server_config: filename ./sshd_config
debug2: load_server_config: done config len = 289
debug2: parse_server_config: config ./sshd_config len 289
debug3: ./sshd_config:14 setting AddressFamily inet
debug3: ./sshd_config:53 setting AuthorizedKeysFile /mi/etc/sshd/authorized_keys
debug3: ./sshd_config:67 setting PasswordAuthentication no
debug3: ./sshd_config:110 setting PidFile c:\\mi\\run\\sshd.pid
debug3: ./sshd_config:112 setting PermitTunnel yes
debug3: ./sshd_config:119 setting Subsystem sftp        sftp-server.exe
debug3: socket:496, socktype:1, io:0000021D9C5EAE10, fd:3
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug3: socket:540, io:0000021D9C5EA730, fd:4
debug3: fd 4 is not O_NONBLOCK
debug3: pipe - r-h:548,io:0000021D9C5EA1B0,fd:5  w-h:544,io:0000021D9C5EA310,fd:6
debug1: Server will not fork when running in debugging mode.
debug3: close - io:0000021D9C5EAE10, type:1, fd:3, table_index:3
debug3: close - io:0000021D9C5EA1B0, type:2, fd:5, table_index:5
debug3: close - io:0000021D9C5EA310, type:2, fd:6, table_index:6
Connection from 129.67.186.181 port 58978 on 129.67.186.96 port 22
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.67
debug1: no match: PuTTY_Release_0.67
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Enabling compatibility mode for protocol 2.0
debug2: fd 4 setting O_NONBLOCK
debug3: socket:0, socktype:1, io:0000021D9C5EAF70, fd:3
debug3: list_hostkey_types: ssh-dss key not permitted by HostkeyAlgorithms
debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-
group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-1
28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-1
28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer client KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256,rsa1024-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss
debug2: ciphers ctos: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour12
8
debug2: ciphers stoc: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour12
8
debug2: MACs ctos: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5
debug2: MACs stoc: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5
debug2: compression ctos: none,zlib
debug2: compression stoc: none,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none
debug1: expecting SSH2_MSG_KEX_DH_GEX_REQUEST
debug3: receive packet: type 34
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
WARNING: could not open ./moduli (No such file or directory), using fixed modulus
debug3: dh_new_group_fallback: requested max size 8192
debug3: using 8k bit group 18
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug3: send packet: type 31
debug2: bits set: 4073/8192
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug3: receive packet: type 32
debug2: bits set: 4037/8192
debug3: send packet: type 33
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug1: KEX done
debug3: receive packet: type 5
debug3: send packet: type 6
debug3: receive packet: type 50
debug1: userauth-request for user MATHS\\tipler service ssh-connection method none
debug1: attempt 0 failures 0
debug2: parse_server_config: config reprocess config len 289
debug3: NetUserGetInfo() failed with error: 1722 for user: tipler and domain: MATHS

debug2: input_userauth_request: setting up authctxt for MATHS\\tipler
debug2: input_userauth_request: try method none
Failed none for MATHS\\tipler from 129.67.186.181 port 58978 ssh2
debug3: userauth_finish: failure partial=0 next methods="publickey,keyboard-interactive"
debug3: send packet: type 51
debug3: receive packet: type 50
debug1: userauth-request for user MATHS\\tipler service ssh-connection method publickey
debug1: attempt 1 failures 0
debug2: input_userauth_request: try method publickey
debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:rF3YwCEoknzMNegnENWZMp98NY0CeDPcOZuDuP/6C/U
debug1: trying public key file /mi/etc/sshd/authorized_keys
debug1: matching key found: file /mi/etc/sshd/authorized_keys, line 5 RSA SHA256:rF3YwCEoknzMNegnENWZMp98NY0CeDPcOZuDuP/6C/U
debug3: send packet: type 60
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for MATHS\\tipler from 129.67.186.181 port 58978 ssh2
debug3: receive packet: type 50
debug1: userauth-request for user MATHS\\tipler service ssh-connection method publickey
debug1: attempt 2 failures 0
debug2: input_userauth_request: try method publickey
debug3: userauth_pubkey: have signature for RSA SHA256:rF3YwCEoknzMNegnENWZMp98NY0CeDPcOZuDuP/6C/U
debug3: auth agent authenticated MATHS\\tipler
debug2: userauth_pubkey: authenticated 1 pkalg ssh-rsa
Accepted publickey for MATHS\\tipler from 129.67.186.181 port 58978 ssh2: RSA SHA256:rF3YwCEoknzMNegnENWZMp98NY0CeDPcOZuDuP/6C/U
debug3: send packet: type 52
debug3: notify_hostkeys: key 0: ssh-rsa SHA256:Y7ZO+v4DtmK47JIWmj4oDyFHaC3gJSiGJ4iU3K4loMU
debug3: notify_hostkeys: key 1: ssh-dss SHA256:UUaU5t0ybmPj++NzEOEUUdsCyPBwELslDg82dv4orco
debug3: notify_hostkeys: key 2: ecdsa-sha2-nistp256 SHA256:/OWW4HGwRNsfNWYOZHdArhMhzYPCH/CeHGTzEM1IqG4
debug3: notify_hostkeys: key 3: ssh-ed25519 SHA256:WRsWODA1HZIanfrnWQ1qglEkU9Cv33CQRWxLNHO9dv4
debug3: notify_hostkeys: sent 4 hostkeys
debug3: send packet: type 80
debug1: Entering interactive session for SSH2.
debug3: pipe - r-h:496,io:0000021D9C5EAEC0,fd:5  w-h:576,io:0000021D9C5EA940,fd:6
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: server_init_dispatch
debug3: receive packet: type 90
debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug2: session_new: allocate (allocated 0 max 10)
debug3: session_unused: session id 0 unused
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug3: send packet: type 91
debug3: receive packet: type 98
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc console
debug1: Ignoring unsupported tty mode opcode 3 (0x3)
debug3: send packet: type 99
debug3: receive packet: type 98
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
Starting session: shell on console for tipler@MATHS from 129.67.186.181 port 58978 id 0
debug3: pipe - r-h:568,io:0000021D9C5EA5D0,fd:7  w-h:536,io:0000021D9C5EAC00,fd:8
debug3: pipe - r-h:572,io:0000021D9C5EA520,fd:9  w-h:564,io:0000021D9C5EAD60,fd:10
debug3: pipe - r-h:584,io:0000021D9C5EA310,fd:11  w-h:580,io:0000021D9C5EA680,fd:12
debug2: fd 7 setting O_NONBLOCK
debug2: fd 8 setting O_NONBLOCK
debug2: fd 9 setting O_NONBLOCK
debug2: fd 10 setting O_NONBLOCK
debug2: fd 11 setting O_NONBLOCK
debug2: fd 12 setting O_NONBLOCK
debug1: Executing command: C:\\mi\\etc\\sshd\\ssh-shellhost.exe

However as soon as I attempt to connect to the tunneled port (in this case TightVNC Server on 5899, tunnel established from 15899 on the remote host) It spams

debug3: channel 1: waiting for connection

approximately 1800 times into the client console before suddenly disconnecting with:

debug3: finish_connect - ERROR: async io completed with error: 107, io:0000021D9
C5EAB50
debug1: channel 1: connected to baron-greenback port 5899
debug3: send packet: type 91
debug3: recv - from CB ERROR:107, io:0000021D9C5EAB50
debug2: channel 1: read<=0 rfd 7 len -1
debug2: channel 1: read failed
debug2: channel 1: close_read
debug3: socketio_shutdown - ERROR:126
debug2: channel 1: input open -> drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug3: send packet: type 96
debug2: channel 1: input drain -> closed

It then repeats

debug3: receive packet: type 98
debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartar
us.org reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.
org
debug3: send packet: type 100
debug2: channel 0: rcvd adjust 8205

with various rcvd adjust values around the 8200 mark.

At the server end the sshd.exe process dies hard, throwing a standard "OpenSSH for Windows has stopped working" popup, along with this corresponding message in the Application log (via event viewer)

Faulting application name: sshd.exe, version: 0.0.14.0, time stamp: 0x591a3830
Faulting module name: KERNELBASE.dll, version: 10.0.14393.1198, time stamp: 0x5902808f
Exception code: 0x80000003
Fault offset: 0x00000000000c6062
Faulting process ID: 0x1570
Faulting application start time: 0x01d2d9eca5a9a190
Faulting application path: C:\mi\etc\sshd\sshd.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report ID: cada76a9-2069-4dfa-90bb-209a5e205926
Faulting package full name: 
Faulting package-relative application ID: 

There is no corresponding line in sshd\logs\sshd.log

theJT commented May 31, 2017

I'm sorry for the massive wall of text there, but I'm a bit out of my depth and have no idea what may or may not be relevant so I'm just attaching everything I can see.

I'm seeing this problem even with IPv4 set explicitly in the config file. IPv6 is explicitly disabled on the network adaptors of both the client and the server in this case - although the exact same thing happens if I re-enable it.

Here's the content of sshd_config

#    $OpenBSD: sshd_config,v 1.84 2011/05/23 03:30:07 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
AddressFamily inet
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_key
# If you use a relative path here it will read from c:\users\$env:UserName\
# which is proabably not what we want. Not least because we'd have to populat
# C:\users with all our home directories.
AuthorizedKeysFile      /mi/etc/sshd/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
# We should be using keyfiles only.
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
PidFile c:\mi\run\sshd.pid
#MaxStartups 10
PermitTunnel yes
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem       sftp    sftp-server.exe

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server
# PubkeyAcceptedKeyTypes ssh-ed25519*

If I start sshd -ddd for debugging and connect as normal, everything initially seems fine:
This from the client

tipler@MATHS@BARON-GREENBACK C:\Users\tipler>debug3: Register child 000000000000
027C pid 3156, 0 zombies of 0
debug2: fd 4 setting TCP_NODELAY
debug3: close - io:0000021D9C5EA5D0, type:2, fd:7, table_index:7
debug3: close - io:0000021D9C5EAD60, type:2, fd:10, table_index:10
debug3: close - io:0000021D9C5EA680, type:2, fd:12, table_index:12
debug2: channel 0: rfd 9 isatty
debug3: fd 9 is O_NONBLOCK
debug3: fd 8 is O_NONBLOCK
debug3: fd 11 is O_NONBLOCK
debug3: send packet: type 99

and this from the server:

debug2: load_server_config: filename ./sshd_config
debug2: load_server_config: done config len = 289
debug2: parse_server_config: config ./sshd_config len 289
debug3: ./sshd_config:14 setting AddressFamily inet
debug3: ./sshd_config:53 setting AuthorizedKeysFile /mi/etc/sshd/authorized_keys
debug3: ./sshd_config:67 setting PasswordAuthentication no
debug3: ./sshd_config:110 setting PidFile c:\\mi\\run\\sshd.pid
debug3: ./sshd_config:112 setting PermitTunnel yes
debug3: ./sshd_config:119 setting Subsystem sftp        sftp-server.exe
debug3: socket:496, socktype:1, io:0000021D9C5EAE10, fd:3
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug3: socket:540, io:0000021D9C5EA730, fd:4
debug3: fd 4 is not O_NONBLOCK
debug3: pipe - r-h:548,io:0000021D9C5EA1B0,fd:5  w-h:544,io:0000021D9C5EA310,fd:6
debug1: Server will not fork when running in debugging mode.
debug3: close - io:0000021D9C5EAE10, type:1, fd:3, table_index:3
debug3: close - io:0000021D9C5EA1B0, type:2, fd:5, table_index:5
debug3: close - io:0000021D9C5EA310, type:2, fd:6, table_index:6
Connection from 129.67.186.181 port 58978 on 129.67.186.96 port 22
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.67
debug1: no match: PuTTY_Release_0.67
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Enabling compatibility mode for protocol 2.0
debug2: fd 4 setting O_NONBLOCK
debug3: socket:0, socktype:1, io:0000021D9C5EAF70, fd:3
debug3: list_hostkey_types: ssh-dss key not permitted by HostkeyAlgorithms
debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-
group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-1
28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-1
28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer client KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256,rsa1024-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss
debug2: ciphers ctos: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour12
8
debug2: ciphers stoc: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour12
8
debug2: MACs ctos: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5
debug2: MACs stoc: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5
debug2: compression ctos: none,zlib
debug2: compression stoc: none,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none
debug1: expecting SSH2_MSG_KEX_DH_GEX_REQUEST
debug3: receive packet: type 34
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
WARNING: could not open ./moduli (No such file or directory), using fixed modulus
debug3: dh_new_group_fallback: requested max size 8192
debug3: using 8k bit group 18
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug3: send packet: type 31
debug2: bits set: 4073/8192
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug3: receive packet: type 32
debug2: bits set: 4037/8192
debug3: send packet: type 33
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug1: KEX done
debug3: receive packet: type 5
debug3: send packet: type 6
debug3: receive packet: type 50
debug1: userauth-request for user MATHS\\tipler service ssh-connection method none
debug1: attempt 0 failures 0
debug2: parse_server_config: config reprocess config len 289
debug3: NetUserGetInfo() failed with error: 1722 for user: tipler and domain: MATHS

debug2: input_userauth_request: setting up authctxt for MATHS\\tipler
debug2: input_userauth_request: try method none
Failed none for MATHS\\tipler from 129.67.186.181 port 58978 ssh2
debug3: userauth_finish: failure partial=0 next methods="publickey,keyboard-interactive"
debug3: send packet: type 51
debug3: receive packet: type 50
debug1: userauth-request for user MATHS\\tipler service ssh-connection method publickey
debug1: attempt 1 failures 0
debug2: input_userauth_request: try method publickey
debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:rF3YwCEoknzMNegnENWZMp98NY0CeDPcOZuDuP/6C/U
debug1: trying public key file /mi/etc/sshd/authorized_keys
debug1: matching key found: file /mi/etc/sshd/authorized_keys, line 5 RSA SHA256:rF3YwCEoknzMNegnENWZMp98NY0CeDPcOZuDuP/6C/U
debug3: send packet: type 60
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for MATHS\\tipler from 129.67.186.181 port 58978 ssh2
debug3: receive packet: type 50
debug1: userauth-request for user MATHS\\tipler service ssh-connection method publickey
debug1: attempt 2 failures 0
debug2: input_userauth_request: try method publickey
debug3: userauth_pubkey: have signature for RSA SHA256:rF3YwCEoknzMNegnENWZMp98NY0CeDPcOZuDuP/6C/U
debug3: auth agent authenticated MATHS\\tipler
debug2: userauth_pubkey: authenticated 1 pkalg ssh-rsa
Accepted publickey for MATHS\\tipler from 129.67.186.181 port 58978 ssh2: RSA SHA256:rF3YwCEoknzMNegnENWZMp98NY0CeDPcOZuDuP/6C/U
debug3: send packet: type 52
debug3: notify_hostkeys: key 0: ssh-rsa SHA256:Y7ZO+v4DtmK47JIWmj4oDyFHaC3gJSiGJ4iU3K4loMU
debug3: notify_hostkeys: key 1: ssh-dss SHA256:UUaU5t0ybmPj++NzEOEUUdsCyPBwELslDg82dv4orco
debug3: notify_hostkeys: key 2: ecdsa-sha2-nistp256 SHA256:/OWW4HGwRNsfNWYOZHdArhMhzYPCH/CeHGTzEM1IqG4
debug3: notify_hostkeys: key 3: ssh-ed25519 SHA256:WRsWODA1HZIanfrnWQ1qglEkU9Cv33CQRWxLNHO9dv4
debug3: notify_hostkeys: sent 4 hostkeys
debug3: send packet: type 80
debug1: Entering interactive session for SSH2.
debug3: pipe - r-h:496,io:0000021D9C5EAEC0,fd:5  w-h:576,io:0000021D9C5EA940,fd:6
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: server_init_dispatch
debug3: receive packet: type 90
debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug2: session_new: allocate (allocated 0 max 10)
debug3: session_unused: session id 0 unused
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug3: send packet: type 91
debug3: receive packet: type 98
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc console
debug1: Ignoring unsupported tty mode opcode 3 (0x3)
debug3: send packet: type 99
debug3: receive packet: type 98
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
Starting session: shell on console for tipler@MATHS from 129.67.186.181 port 58978 id 0
debug3: pipe - r-h:568,io:0000021D9C5EA5D0,fd:7  w-h:536,io:0000021D9C5EAC00,fd:8
debug3: pipe - r-h:572,io:0000021D9C5EA520,fd:9  w-h:564,io:0000021D9C5EAD60,fd:10
debug3: pipe - r-h:584,io:0000021D9C5EA310,fd:11  w-h:580,io:0000021D9C5EA680,fd:12
debug2: fd 7 setting O_NONBLOCK
debug2: fd 8 setting O_NONBLOCK
debug2: fd 9 setting O_NONBLOCK
debug2: fd 10 setting O_NONBLOCK
debug2: fd 11 setting O_NONBLOCK
debug2: fd 12 setting O_NONBLOCK
debug1: Executing command: C:\\mi\\etc\\sshd\\ssh-shellhost.exe

However as soon as I attempt to connect to the tunneled port (in this case TightVNC Server on 5899, tunnel established from 15899 on the remote host) It spams

debug3: channel 1: waiting for connection

approximately 1800 times into the client console before suddenly disconnecting with:

debug3: finish_connect - ERROR: async io completed with error: 107, io:0000021D9
C5EAB50
debug1: channel 1: connected to baron-greenback port 5899
debug3: send packet: type 91
debug3: recv - from CB ERROR:107, io:0000021D9C5EAB50
debug2: channel 1: read<=0 rfd 7 len -1
debug2: channel 1: read failed
debug2: channel 1: close_read
debug3: socketio_shutdown - ERROR:126
debug2: channel 1: input open -> drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug3: send packet: type 96
debug2: channel 1: input drain -> closed

It then repeats

debug3: receive packet: type 98
debug1: server_input_channel_req: channel 0 request winadj@putty.projects.tartar
us.org reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req winadj@putty.projects.tartarus.
org
debug3: send packet: type 100
debug2: channel 0: rcvd adjust 8205

with various rcvd adjust values around the 8200 mark.

At the server end the sshd.exe process dies hard, throwing a standard "OpenSSH for Windows has stopped working" popup, along with this corresponding message in the Application log (via event viewer)

Faulting application name: sshd.exe, version: 0.0.14.0, time stamp: 0x591a3830
Faulting module name: KERNELBASE.dll, version: 10.0.14393.1198, time stamp: 0x5902808f
Exception code: 0x80000003
Fault offset: 0x00000000000c6062
Faulting process ID: 0x1570
Faulting application start time: 0x01d2d9eca5a9a190
Faulting application path: C:\mi\etc\sshd\sshd.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report ID: cada76a9-2069-4dfa-90bb-209a5e205926
Faulting package full name: 
Faulting package-relative application ID: 

There is no corresponding line in sshd\logs\sshd.log

@bagajjal

This comment has been minimized.

Show comment
Hide comment
@bagajjal

bagajjal Jun 1, 2017

Collaborator

@bdr2 - Can you try with the latest version (0.0.14.0).. It works for me with (AddressFamily inet and AddressFamily any)..

@theJT - I tried on my local machine with the tightvnc... both the local port forwarding, remote port forwarding works well and I can do the vnc as well...

To debug further I need more information,

  1. I think you are using the remote port forwarding?

  2. Please provide the sshd.log (whole log), ssh log file (ssh.exe -E log_file) for the failure scenario..

  3. Can you try the remote port forwarding scenario by running sshd in the SYSTEM context and let us know if it works.. If it works then you can use it as workaround option..
    C:\WINDOWS\system32>net stop sshd
    C:\WINDOWS\system32>sc.exe config sshd obj=localsystem
    [SC] ChangeServiceConfig SUCCESS
    C:\WINDOWS\system32>net start sshd

You can revert this back using
C:\WINDOWS\system32>net stop sshd
C:\WINDOWS\system32>sc.exe config sshd obj="nt service\sshd"
[SC] ChangeServiceConfig SUCCESS
C:\WINDOWS\system32>net start sshd

  1. can you try remote port forwarding on the same machine to see if it works or not..
Collaborator

bagajjal commented Jun 1, 2017

@bdr2 - Can you try with the latest version (0.0.14.0).. It works for me with (AddressFamily inet and AddressFamily any)..

@theJT - I tried on my local machine with the tightvnc... both the local port forwarding, remote port forwarding works well and I can do the vnc as well...

To debug further I need more information,

  1. I think you are using the remote port forwarding?

  2. Please provide the sshd.log (whole log), ssh log file (ssh.exe -E log_file) for the failure scenario..

  3. Can you try the remote port forwarding scenario by running sshd in the SYSTEM context and let us know if it works.. If it works then you can use it as workaround option..
    C:\WINDOWS\system32>net stop sshd
    C:\WINDOWS\system32>sc.exe config sshd obj=localsystem
    [SC] ChangeServiceConfig SUCCESS
    C:\WINDOWS\system32>net start sshd

You can revert this back using
C:\WINDOWS\system32>net stop sshd
C:\WINDOWS\system32>sc.exe config sshd obj="nt service\sshd"
[SC] ChangeServiceConfig SUCCESS
C:\WINDOWS\system32>net start sshd

  1. can you try remote port forwarding on the same machine to see if it works or not..
@theJT

This comment has been minimized.

Show comment
Hide comment
@theJT

theJT Jun 6, 2017

I've finally traced this to an issue with TightVNC server itself. When set to listen to loopback connections it gets weirdly specific. a tunnel of 15900:$HOSTNAME:5900 (as in my ssh script, where obviously $HOSTNAME is being populated with the target machine's name) will not work, but 15900:127.0.0.1:5900 will.

Thank you all for your help.

theJT commented Jun 6, 2017

I've finally traced this to an issue with TightVNC server itself. When set to listen to loopback connections it gets weirdly specific. a tunnel of 15900:$HOSTNAME:5900 (as in my ssh script, where obviously $HOSTNAME is being populated with the target machine's name) will not work, but 15900:127.0.0.1:5900 will.

Thank you all for your help.

@bagajjal

This comment has been minimized.

Show comment
Hide comment
@bagajjal

bagajjal Jun 7, 2017

Collaborator

Please reopen if required.

Collaborator

bagajjal commented Jun 7, 2017

Please reopen if required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment