BigSSH, odd behavior with Win10 OpenSSH Server?

I have OpenSSH installed on multiple Win10 workstations. I use BigSSH to issue remote WOL commands on a Samba PDC with no problem. But as soon as I attempt to issue remote SSH commands to the Windows workstations, I get a read ECCONRESET on the BigSSH node and the same error from the Node itself. Now, the weird part is the command actually executes. I can shutdown or reboot the windows machines in this way, but the error ECCONRESET persists. But only when interacting with the windows machines not linux servers or workstations. I'm going to see how the Macs in this environment behave with the client later. I am at preset using username/password for authentication but will switch to a key pair once I have this sorted out. So, what is causing the error? Should I ignore it since the remote command is executing? Or What???

Thanks for any input.

I'm a little confused by this. You say that you execute a shutdown command and are then able to issue any other commands to the Windows workstations? Well, if they are shut down, how would you continue to have an SSH connection to them? If the command you are executing begins the shutdown immediately, then the error is most likely because the shutdown routine is terminating the SSH connection before it is acknowledged to NR so that the connection is closed.. Instead of issuing the command directly, issue the shutdown with a 3 second delay and see if you get the same error. I might be completely wrong but even if I am, it will at least give more data.

1 Like

It happens with all commands, not just shutdown or reboot. I can issue a 'dir' and get the same error. But also receive the output of the 'dir' command in the return string(s). Good thought though. Sorry I didn't make that clear. Any other ideas?

Just for clarification, I don't issue further commands after a reboot or shutdown. At that point after a shutdown command I ping the machine to verify it goes offline then ping again to verify bootup if it was a reboot command.

No, unfortunately I don't. I will say this though...I was trying to get this figured out for the longest time. I was trying to get my a linux container on my server to be able to issue commands to my Windows server. After months of searching online and trying many, MANY different paths, I finally gave up and figured out a way to move the program I was trying to run over to my Linux server instead. I was never able to get the Open SSH server to execute the commands correctly on my Windows server (but I am only running windows 10 home and not Pro or Windows Server, so i suspect that had something to do with it). So, the fact that you got the command to execute is a lot further than I got! I suspect it's just the OpenSSH server on Windows not playing well with the SSH node in NR.

You could do this...if you just open an SSH connection from the bash command line on your linux machine and try and issue a command to your Windows machine manually, you might get more info on the error that is occurring that isn't being displayed by the node in NR.

Can you connect properly without Node-RED?

Reply to both Ryan780 and TotallyInformation:

This should answer both of your questions. I am automating what I do manually from SSH everyday. So, to Ryan780, I don't have any problem executing commands on the remote Win10 Pro machines, either via the native SSH client on OSX or from Node-Red, with the addition of the 'read ECONNRESET' error on Node-Red. That should also answer TotallyInformations question. I connect with no problems or error from a native SSH client on OSX. I can transfer scripts, batch files and PowerShell scripts via SCP and execute them remotely via SSH from OSX. The Win10 machines are all Pro and are joined to a primary domain controller in the form of a Linux Samba server. Everything works great. I was just trying to automate some of the more mundane tasks that I perform manually via SSH with Node-Red flows. For instance, on Fridays, I remotely execute a command via SSH that pops up a window on all the workstations reminding everyone to save their work before a scheduled reboot over the weekend. Then sometime that night or Saturday I execute reboot commands via SSH. I was doing a lot of this with PsTools but windows is moving away from supporting some of that toolset. Now that OpenSSH is part of Windows as a "Feature" and can be installed via 4 lines of PowerShell, I have adopted this method of remote administration.

But I think Ryan780 is correct, OpenSSH on windows isn't playing well with the rest of the world, especially Node-Red.

OK, sorry then, without looking through the bigssh source code, I couldn't say what might be wrong. Maybe try raising an issue against the node so that the author takes a look?


So this is what I decided to do, bear with me as I step through this for the benefit of someone else wanting to do something similar. Hint, we are going to use the 'exec' node to do the same thing the BigSSH node does. Well, kinda. Also you are going to need the key pair for the server you are going to be logging into and running remote commands on via ssh available.

First drop this on an empty flow. It's just to make testing easier.


deploy and press the inject button. All this does is run a 'whoami' command on the system you have node red installed on. This way I know exactly what user I'm working as. You could then modify the exec command to issue a 'pwd' just for grins to verify what working directory you will be working from when running commands from the exec node.

login to the host that is running node red via the console or ssh if its enabled as the user we got from the above 'whoami' command. Copy id_rsa and using what ever means you have to that users .ssh folder. I do it remotely via the scp command.

While still logged in, try to ssh to the Win10 machine running OpenSSH. If you got the right key pair on this client and the remote server, you should connect without being prompted for a password. If not, you need to visit your OpenSSH config and/or verify you have the key pairs generated and installed correctly on client and server. Once you can complete this step, type exit to end the ssh session.

Now go back to your exec node. You could now do something like this in the command box.
ssh username@workstation_running_openssh_ip msg * Test Message From The Beyond

On the Windows 10 Pro workstation I now have a popup message and the return code from the exec node is a big fat 0. Meaning command exited normally.

So, there it is. I know i left out many details, especially concerning the configuration of the OpenSSH server on Windows 10. There are some gotcha's to that one. I can tell you how I did it, if needed. Also generating the key pair can be confusing. But again, I've done it more than once now. It was definitely a convoluted mess. But now that it is done, it is easy to exec remote commands on windows machines using the exec node.

Comments, questions?

There are, of course also other ways to run commands remotely on Windows depending on the license type you are using.

WINRM is the officially supported remote administration interface for Windows. There is even a node.js library for it: nodejs-winrm - npm (

Ughhh, please, don't ever make me use WinRM again. But, yes, it is, among many many other ways that M$ has to administer their... stuff. As cantankerous as it is, 90% of my administration of workstations is done through GPO's. All of my servers, PDC's and otherwise, run in ESXi VM's. I have access to the management VLAN that vSphere sits on, so thats how I manage them. Getting too old for this stuff, ready to retire in South America soon. Cheers.


That's exactly the problem I ran into. I have a Home license. And I'm not about to pay for a pro license for what I needed to do. Was easier just to move the function to my Linux server.

@westek , I know that it SHOULD work, I was just saying that I was never able to get it to work. Maybe I got screwed up between my bash commands and my command line commands (i am always typing dir in my linux machine and ls in my windows machine. :crazy_face: ) but I could never get it to work correctly. I was able to get a connection fine, it was just getting the commands to execute.

Don't blame you and I fully agree :grin:

I would always choose Linux over Windows as a server given the choice. But never as a desktop though I've tried many times. Might have to change that when I eventually retire and run out of Windows license options though!

A quick BASH alias fixes that problem of course :wink: