sshd broken by seemingly trivial network change

Erik Soderquist ErikSoderquist@gmail.com
Thu Dec 17 21:24:54 GMT 2020


On Thu, Dec 17, 2020 at 3:51 PM Charles Russell <redacted> wrote:
>
> On 12/17/2020 11:49 AM, Bill Stewart wrote:
>
>  > Make sure to look carefully through all of the firewall rules and
>  > check whether there is a rule blocking that executable or port.
>  >
>
> Selecting "Advanced Settings" and then "incoming rules", I see one rule
> for sshd private: enabled, allowed and one rule for sshd public:
> enabled, allowed. There is a third rule for sshd domain: (disabled,
> allowed). I believe that one is irrelevant but I enabled it anyway,
> which did not help.

I've had weird instances where the Windows Firewall tools lied; I
confirmed this by temporarily shutting down the Windows Firewall
entirely, then restarting the service having problems and retesting.
On retest, it worked fine, confirming it was the firewall causing the
problem.

What exactly the problem was varied (this has happened many many times
to me)...  In some cases it was the rule definition for the scope not
matching the actual network, in some cases I could not find any real
issue, but deleting and recreating the rules fixed the issue, in a few
cases, I also found a deny rule that somehow matched the service
having problems, and deny rules take precedence over allow rules.  One
example of the conflict could be "sshd allowed" vs "port 22 denied";
the deny would take precedence.

I suggest doing the firewall down/restart sshd test to confirm or
refute the Windows Firewall being involved, then going from there.

-- Erik




--
"I do not think any of us are truly sane, Caleb. Not even you. Courage
is not sanity. Being willing to die for someone else is not sanity."
... "Love is not sane, nor is faith." ... "If sanity lacks those
things, Caleb, I want no part of it."

-- Alexandria Terri in "Weaving the Wyvern" by Alexis Desiree Thorne


More information about the Cygwin mailing list