I have Windows 7 (x64) and I was planning to use CIS for firewall and antivirus and WinSSHD as an ssh server. Unfortunately, installing CIS makes it impossible to connect from a remote workstation and open an ssh session.
I have configured winsshd.exe as a trusted application, granted all kind of permissions and tried to leave it as “authorized” as possible. Not working.
Then I tried disabling Antivirus, D+, and firewall. Not working.
Then I uninstalled Comodo and it worked.
How can Comodo break WinSSHD even when disabled? After discussion with WinSSHD developers, they mentioned that apparently Comodo was preventing them from executing cmd.exe to support the ssh session.
Thank you for any help you may be able to provide.
If yourPC was going to act as the SSH host and receive unsolicited request for the internet, then you would have to have Global Rules in place to allow the unsolicited packets past the firewall filter.
This is how CIS is designed. The first thing an unsolicited inbound request strikes is the firewall filter. If there aren’t any rules that will allow the unsolicited request in, then it will be blocked.
The problem does not seem to be related to actual inbound network traffic. I can establish the connection from the remote machine, enter my password and get it accepted/rejected. The problem comes when WinSSHD tries to open a cmd.exe session to give me a terminal. It fails to initialize cmd.exe properly and THEN closes the connection.
This behavior happens with the firewall, AV and D+ disabled or enabled (it wouldn’t be a rule problem then, right?).
About the logs, I’ve been looking and cannot find anything related to this. Any hints about where I should be looking?
This is definitely Defense+ related then, as D+ is the component that controls executables on the local host.
The quickest way to fix this is to 1) delete whatever policy has been assigend to WinSSHD and then 2) make WinSSHD a “safe file” (providing, of course, that you are certain this executable is actually safe).
STEP 1
Open CIS and click DEFENSE+ → ADVANCED → COMPUTER SECURITY POLICY. This will display the listings of all current executable policies. Locate the entry for WinSSHD, click once to select it, click REMOVE and then click APPLY.
STEP 2
Open CIS and click DEFENSE+ → COMMON TASKS → MY OWN SAFE FILES. Click ADD → BROWSE FILES and navigate to the folder containing the WinSSHD executable. Select it and click the “->” button to add the executable to the right hand “Selected Items” panel. Click APPLY. This will add the WinSSHD executable to your personal safe list.
I have tried those steps, unfortunately the behavior has not changed, it still dies when trying to launch cmd.exe. The problem is really weird, why does it lock any behavior even if disabled?
Not really. I believe you refer to the window from “View Defense+ Events”, which is the closest thing to a log I have seen. In that case, there are no events related to WinSSHd (or cmd.exe).
I was wondering if there are any updates on this topic.
This is not the only case we are aware of in which COMODO interferes with application launching even when disabled: We also filed a support ticket a few months ago because the presence of COMODO aborts the execution of the “Installer version” of our opensource game-development platform (our README includes a warning stating that the installer cannot work in the presence of COMODO, and we prompt users to download the generic multiplatform version instead).
Both cases seem to be related with applications that launch other applications as a support: WinSSHD is trying to launch cmd.exe and our platform is trying to launch the java virtual machine. In both cases, the malfunction occurs even with comodo disabled (!) and the only solution is to uninstall.
I really like the COMODO platform, more than anything else in the market, but this side-effect is problematic. Are these behaviors and limitations already known? Can they be solved or are they a trade-off from the hooks required to provide good security? (there is at least another firewall solution that presents the same problem)
Just to be on the same page, when you disable comodo, you mean you right click the CIS tray icon and click disable under Firewall and/or Defence + and not clicking Exit? If yes I will test this out later today after classes. Also make sure you have “Block all the unknown requests when the application is closed” is UN-Checked, which can be found by opening the cis window click Defense+, Advanced, Defense+ Settings.
Okay good, I will test this out the best that I can. Btw, is this were the offical website to get this software or do I get it somewhere else? Bitvise SSH Server | Bitvise
I can confirm this, with av/fw/d+ disabled I can not open a terminal, I am using windows 7 x64 too. However, I tested winsshd on my windows xp sp3 32-bit machine and I can open a terminal when I connect from windows 7. The xp also has comodo installed but I kept it enabled, it has defense+ set to safe mode and firewall set to custom policy. When I go to open a terminal using the tunnelier client, comodo on the xp machine alerts that winsshd is trying to execute toterms.exe, I click allow and then get another alert that toterms is trying to execute cmd.exe which in turn I select allow and I am dropped into a cmd prompt. With that being said, I think there is an issue with WinSSHD and windows 7 x64, but you said it worked fine when comodo was uninstalled witch is weird. So I dont know whats going on here, but maybe you can try to use a different ssh server implantation for windows, that is if you are using the lite free version and you didnt pay for the full version already.
Unfortunately, the new version doesn’t seem to fix this problem either. It is not only WinSSHD, our own e-Adventure platform cannot work with COMODO installed (not even when it is disabled).
It’s too bad because I really like the new version and I can feel the huge amount of work that went into it, but unfortunately I am giving up on COMODO. It breaks too many programs even while disabled. I will check back in version 5 because I do think it is a great product.
Thank you both for the time you invested helping me troubleshoot the issue, there is a great community going on here…
I’m a developer at Bitvise; I’ve also responded to WinSSHD - Comodo compatibility problem reported on our technical support forum (the link has already been published in one of the earlier posts here).
I’m joining this forum to explain what exactly goes on between WinSSHD.exe, toterms.exe, and cmd.exe. Hopefully, Comodo developers will find this helpful.
First of all, WinSSHD.exe <-> toterms.exe work the same way on all Windows. There is a slight difference between x86 and x64 Windows though.
This is how things go on x86 Windows:
WinSSHD.exe executes toterms.exe in the context of authenticated user, WinSSHD.exe and toterms.exe then communicate via named pipes.
toterms.exe then executes terminal shell (cmd.exe by default settings) in suspended mode.
toterms.exe injects totermh32.dll to the suspended cmd.exe
toterms.exe resumes cmd.exe; totermh32.dll in cmd.exe will hook Windows Console API.
There are some differences on Windows x64:
toterms.exe is 64-bit process.
When toterms.exe executes a 64-bit terminal shell (64-bit cmd.exe by default), totermh64.dll will be injected instead.
But if toterms.exe is set to execute a 32-bit terminal shell, then toterms.exe will launch totermi32.exe, which in turn will inject totermh32.dll to the suspended terminal shell process.
We can prepare debug builds of toterms.exe, totermh*.dll, and totermi32.dll. Debug builds of these programs feature detailed and direct debug file logging. With this logs we should be able to better diagnose the breaking point.
I have to add that we received only a few reports of WinSSHD terminal failing to start. In all times the problem went away by uninstalling the problematic anti-virus or firewall. WinSSHD doesn’t know about, doesn’t care about, and doesn’t (directly) affect anti-virus or firewall suites running on the same computer. Of course, that can’t be said the other way around.
Just noting that I have the very same problem, and awaiting positive development in this matter with great anticipation.
As far as I can recall CIS has had similar issues in the past: blocking some application even when all modules are disabled, without any trace of the event in the logs. I think it was blocking (some) console applications which is why I delayed switching to Comodo in the first place. I like CIS so this time I’m sticking with it. Until it’s fixed, I’m going to use copssh (openssh on windows).
